A summary of block size hardfork proposals

Currently, there are 4 block size BIP by Bitcoin developers:

BIP100 by Jeff: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf BIP101 by Gavin: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files BIP??? by Pieter (called "BIP103" below): https://gist.github.com/sipa/c65665fc360ca7a176a6

To facilitate further discussion, I'd like to summarize these proposals by a series of questions. Please correct me if I'm wrong. Something like sigop limit are less controversial and are not shown.

Should we use a BIP34-like voting mechanism to initiate the hardfork? BIP100, 102, 103: No BIP101: Yes

When should we initiate the hardfork? BIP100: 2016-01-11 BIP101: 2 weeks after 75% miner support, but not before 2016-01-11 BIP102: 2015-11-11 BIP103: 2017-01-01

What should be the block size at initiation? BIP100: 1MB BIP101: 8MB BIP102: 2MB BIP103: 1MB

Should we allow further increase / decrease? BIP100: By miner voting, 0.5x - 2x every 12000 blocks (~3 months) BIP101: Double every 2 years, with interpolations in between (41.4% p.a.) BIP102: No BIP103: +4.4% every 97 days (double every 4.3 years, or 17.7% p.a.)

The earliest date for a >=2MB block? BIP100: 2016-04-03 (assuming 10 minutes block) BIP101: 2016-01-11 BIP102: 2015-11-11 BIP103: 2020-12-27

What should be the final block size? BIP100: 32MB is the max, but it is possible to reduce by miner voting BIP101: 8192MB BIP102: 2MB BIP103: 2048MB

When should we have the final block size? BIP100: Decided by miners BIP101: 30 years after initiation BIP102: 2015-11-11 BIP103: 2063-07-09

Great summary, thanks. Helpful to get general grasp of the main things out there.

On 07/30/2015 11:14 AM, jl2012 via bitcoin-dev wrote:

> Currently, there are 4 block size BIP by Bitcoin developers:
>
> BIP100 by Jeff:
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
> BIP101 by Gavin:
> https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki
> BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files
> BIP??? by Pieter (called "BIP103" below):
> https://gist.github.com/sipa/c65665fc360ca7a176a6
>
> To facilitate further discussion, I'd like to summarize these
> proposals by a series of questions. Please correct me if I'm wrong.
> Something like sigop limit are less controversial and are not
> shown.
>
> Should we use a BIP34-like voting mechanism to initiate the
> hardfork? BIP100, 102, 103: No BIP101: Yes
>
> When should we initiate the hardfork? BIP100: 2016-01-11 BIP101: 2
> weeks after 75% miner support, but not before 2016-01-11 BIP102:
> 2015-11-11 BIP103: 2017-01-01
>
> What should be the block size at initiation? BIP100: 1MB BIP101:
> 8MB BIP102: 2MB BIP103: 1MB
>
> Should we allow further increase / decrease? BIP100: By miner
> voting, 0.5x - 2x every 12000 blocks (~3 months) BIP101: Double
> every 2 years, with interpolations in between (41.4% p.a.) BIP102:
> No BIP103: +4.4% every 97 days (double every 4.3 years, or 17.7%
> p.a.)
>
> The earliest date for a >=2MB block? BIP100: 2016-04-03 (assuming
> 10 minutes block) BIP101: 2016-01-11 BIP102: 2015-11-11 BIP103:
> 2020-12-27
>
> What should be the final block size? BIP100: 32MB is the max, but
> it is possible to reduce by miner voting BIP101: 8192MB BIP102:
> 2MB BIP103: 2048MB
>
> When should we have the final block size? BIP100: Decided by
> miners BIP101: 30 years after initiation BIP102: 2015-11-11 BIP103:
> 2063-07-09
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

I'd like to add to this some remarks that are from an earlier discussion

Cameron Garnham added into a thread, at http://bitcoin-development.narkive.com/iHmMh6bZ/bitcoin-development-prop osed-alternatives-to-the-20mb-step-function#post65 "First off, I am glad that the idea of dynamic block size adjustment is gaining some attention, in particular the model that I proposed.

I wanted to take some time and explain some of the philosophy of how, and why, I proposed this this particular model.

When Bitcoin was first made, there was a 32MB block size limit; this was quickly found to be open to spam (and potentially DOS, as the code was not-at-all optimized to support large blocks), and was reduced to 1MB, this was a quick fix that was never intended to last; at some point the network should come to an understanding, a consensus if you will, of what (and how much) belongs in a block. The core point of this is that miners have always, and will always; hold the power, to decide what goes into blocks; this implicitly, obviously, includes how large blocks are. Miners are able to come any sort of agreement they wish, providing the bitcoin clients accept their blocks as valid." (...) "the proposal introducing a consensus protocol for block sizes; instead of just having a hard limit (enforced by everyone), instead, we have a constant factor above the average block size over a fixed intervals that is soft-forked by only the miners. (The next simplest mathematical construct). This proposal is entirely a soft-fork and may be implemented without changing any client code what so ever. In-fact, it could be implemented by only a simple 51% majority of miners, with-or-without gaining the wider community consensus."

- -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn

I am making some corrections to my previous summary

Currently, there are 4 block size BIP by Bitcoin developers:

BIP100 by Jeff: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf BIP101 by Gavin: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files BIP??? by Pieter (called "BIP103" below): https://gist.github.com/sipa/c65665fc360ca7a176a6

To facilitate further discussion, I'd like to summarize these proposals by a series of questions. Please correct me if I'm wrong. Something like sigop limit are less controversial and are not shown.

Should we use a miner voting mechanism to initiate the hardfork? BIP100: Yes, support with 10800 out of last 12000 blocks (90%) BIP101: Yes, support with 750 out of last 1000 blocks (75%) BIP102: No BIP103: No

When should we initiate the hardfork? BIP100: 2016-01-11# BIP101: 2 weeks after 75% miner support, but not before 2016-01-11 BIP102: 2015-11-11 BIP103: 2017-01-01

# The network does not actually fork until having 90% miner support

What should be the block size at initiation? BIP100: 1MB BIP101: 8MB* BIP102: 2MB BIP103: 1MB

* It depends on the exact time of initiation, e.g. 8MB if initiated on 2016-01-11, 16MB if initiated on 2018-01-10.

Should we allow further increase / decrease? BIP100: By miner voting, 0.5x - 2x every 12000 blocks (~3 months) BIP101: Double every 2 years, with linear interpolations in between (41.4% p.a.) BIP102: No BIP103: +4.4% every 97 days (double every 4.3 years, or 17.7% p.a.)

The earliest date for a >=2MB block? BIP100: 2016-04-03^ BIP101: 2016-01-11 BIP102: 2015-11-11 BIP103: 2020-12-27

^ Assuming 10 minutes blocks and votes cast before 2016-01-11 are not counted

What should be the final block size? BIP100: 32MB is the max, but it is possible to reduce by miner voting BIP101: 8192MB BIP102: 2MB BIP103: 2048MB

When should we have the final block size? BIP100: Decided by miners BIP101: 2036-01-06 BIP102: 2015-11-11 BIP103: 2063-07-09