Tier Nolan [ARCHIVE] on Nostr: 📅 Original date posted:2016-03-25 📝 Original message:I think you will have a ...
📅 Original date posted:2016-03-25
📝 Original message:I think you will have a hard time getting something related to block size
accepted in the current climate.
Using floating point calculations in consensus code is a bad idea. The
standard practice is to use very large integers to fake it. That has the
advantage that it is exact. You don't even need to do this here.
Your get median function could just as easily use an array of integers.
You are dividing by 2.0 and then getting casting it to int after using a
floor function. The standard integer divide by 2 does that automatically.
The median function is sufficiently defined that I don't think you need the
exact function (especially if you use integers).
Since the block size has to be an integer, even if the size was
1,234,567.5, the limit would still be 1,234,567.
It would likely help to gain acceptance if you added a 2nd limiter to the
growth rate. For example, you could make it so that the size isn't allowed
to more than double every year. This is similar to the 1MB limit on the
lower end. A 45 day doubling time (granted subject to miner veto) is
likely unacceptable. Miners could spam max size blocks by filling them
with transactions created for that purpose.
The graphs likely understate the growth rate, since the 1MB limit
inherently restricts things to 1MB.
On Fri, Mar 25, 2016 at 5:27 PM, Chris Kleeschulte via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The following draft BIP proposes changing the MAX_BLOCK_SIZE consensus
> rule to be a function of the median block size over the last 12,960 blocks
> (about three months) multiplied by 2 and calculated when a block is
> connected to the blockchain.
>
> Motivation:
>
> The purpose of this consensus rule change is to allow the maximum block
> size to increase or decrease based on actual network usage. A block size
> limit, as discussed here, prevents certain types of denial of service
> attacks on the Bitcoin network, however a fixed limit does not allow the
> capacity of the network to increase as advancements in scaling are
> realized. By adjusting the limit based on the sizes of blocks in the
> recent past, the throughput of the network can adjust to changes in user
> demand and scaling related technology advancements while still being
> protected from denial of service attacks.
>
>
> Full proposal here:
>
> https://github.com/bitpay/bips/blob/master/bip-adaptiveblocksize.mediawiki
>
> I look forward to your consideration.
>
> thank you,
> --
> Chris Kleeschulte
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160325/7846decc/attachment.html>;
📝 Original message:I think you will have a hard time getting something related to block size
accepted in the current climate.
Using floating point calculations in consensus code is a bad idea. The
standard practice is to use very large integers to fake it. That has the
advantage that it is exact. You don't even need to do this here.
Your get median function could just as easily use an array of integers.
You are dividing by 2.0 and then getting casting it to int after using a
floor function. The standard integer divide by 2 does that automatically.
The median function is sufficiently defined that I don't think you need the
exact function (especially if you use integers).
Since the block size has to be an integer, even if the size was
1,234,567.5, the limit would still be 1,234,567.
It would likely help to gain acceptance if you added a 2nd limiter to the
growth rate. For example, you could make it so that the size isn't allowed
to more than double every year. This is similar to the 1MB limit on the
lower end. A 45 day doubling time (granted subject to miner veto) is
likely unacceptable. Miners could spam max size blocks by filling them
with transactions created for that purpose.
The graphs likely understate the growth rate, since the 1MB limit
inherently restricts things to 1MB.
On Fri, Mar 25, 2016 at 5:27 PM, Chris Kleeschulte via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The following draft BIP proposes changing the MAX_BLOCK_SIZE consensus
> rule to be a function of the median block size over the last 12,960 blocks
> (about three months) multiplied by 2 and calculated when a block is
> connected to the blockchain.
>
> Motivation:
>
> The purpose of this consensus rule change is to allow the maximum block
> size to increase or decrease based on actual network usage. A block size
> limit, as discussed here, prevents certain types of denial of service
> attacks on the Bitcoin network, however a fixed limit does not allow the
> capacity of the network to increase as advancements in scaling are
> realized. By adjusting the limit based on the sizes of blocks in the
> recent past, the throughput of the network can adjust to changes in user
> demand and scaling related technology advancements while still being
> protected from denial of service attacks.
>
>
> Full proposal here:
>
> https://github.com/bitpay/bips/blob/master/bip-adaptiveblocksize.mediawiki
>
> I look forward to your consideration.
>
> thank you,
> --
> Chris Kleeschulte
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160325/7846decc/attachment.html>;