BIP: 1XX Title: Increase maximum block size to 8MB Author: Eli Dourado <elidourado@gmail.com> Status: Draft Type: Standards Track Created: 2015-08-20
This BIP proposes a one-time increase in the one megabyte maximum block size to eight megabytes.
Transaction volume on the Bitcoin network has been growing, and will soon reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte maximum block size. A one-time increase in the maximum block size will alleviate potential problems caused by this growth without specifying any particular path of future scaling.
After deployment (see the Deployment section for details), the maximum allowed size of a block on the main network shall be calculated based on the timestamp in the block header.
The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400).
Deployment shall be controlled by hash-power supermajority vote (similar to the technique used in BIP34), but the earliest possible activation time is 2016-01-11 00:00:00 UTC.
Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with bits [TBD] set ([TBD] in hex)]. The activation time will be the timestamp of the 750th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC.
Block version numbers are used only for activation; once activation is achieved, the maximum block size shall be as described in the specification section, regardless of the version number of the block.
Test network parameters are the same as the main network, except starting immediately and with easier supermajority conditions and a shorter grace period:
starting time: 1 Aug 2015 (timestamp 1438387200) (i.e., in the past)
activation condition: 75 of 100 blocks
grace period: 24 hours
After listening very closely to all parties in the block size discussion, it is clear that there are conflicting long-term visions for what Bitcoin will become. This proposal is aimed at a compromise that alleviates short-run pressures on Bitcoin’s network without pre-committing any party to a particular long-run approach for scaling the network.
Gavin Andresen has tested the current reference implementation with a block size of 8,000,000 bytes and determined that it is feasible. An 8MB block size also has support from miners on the most bandwidth-constrained networks.
An increase in the maximum block size to 8MB represents three doublings of Bitcoin’s capacity, which may take the network several years to outgrow. In the meantime, developers can observe and gather information about the results of the increased block size on the stability and decentralization of the network before committing to any further scaling strategy.
Three doubling periods is long enough that we will not simply rehash the block size debate as soon as the new block size is adopted. In addition, developers will have time to explore alternatives to increasing the block size such as the Lightning network.
The technical aspects of this plan are taken from Gavin Andresen’s BIP 101. The only technical modifications are the elimination of the future growth trajectory and the addition of a different block version number.
As a compromise proposal, many objections to all previous proposals continue to apply. Larger blocks have the potential to increase network centralization and enable new attacks. Not specifying a future growth trajectory means that the community may have to repeat the current block size debate if Bitcoin continues to grow.
This is a hard-forking change to the Bitcoin protocol; anybody running code that fully validates blocks must upgrade before the activation time or they will risk rejecting a chain containing larger-than-one-megabyte blocks.
Simplified Payment Verification software is not affected, unless it makes assumptions about the maximum depth of a transaction's merkle branch based on the minimum size of a transaction and the maximum block size.
Not yet implemented