Author: Roy Badami 2015-06-24 17:28:47
Published on: 2015-06-24T17:28:47+00:00
The context describes a proposal to increase the maximum block size in the Bitcoin network. Miners can collude to reduce the block size using a BIP-34 style mechanism, but this approach has vulnerabilities that can be exploited. The proposed solution is to replace the fixed one-megabyte maximum block size with a maximum size that grows over time at a predictable rate. The maximum size shall double every 63,072,000 seconds until 2036-01-06 00:00:00 UTC, and the maximum size of blocks after this date shall be 8,192,000,000 bytes. Deployment shall be controlled by hash-power supermajority vote.The proposed block size increase to 8MB is designed to accommodate long-term growth trends in CPU power, storage, and Internet bandwidth. The activation of the increase will require 750 out of 1000 consecutive blocks in the best chain to have a version number with bits 3 and 14 set, with an earliest possible activation time of 2016-01-11 00:00:00 UTC. Once activated, the maximum block size will be determined by the specification section and not the version number.The deployment plan was taken from Jeff Garzik's proposed BIP100 block size increase and includes a grace period of two weeks after the 750th block is reached. The chosen block size of 8MB was based on feedback from miners stuck behind bandwidth-constrained networks, particularly Chinese miners behind the Great Firewall of China. The rationale behind the doubling interval and 20-year limit is that exponential growth cannot continue indefinitely. Calculations for the block size increase are based on timestamps rather than blockchain height, so implementations can know a block's maximum size after downloading its header but before downloading any transactions. Compatibility will require a hard-forking change to the Bitcoin protocol, meaning anyone running code that fully validates blocks must upgrade before the activation time or 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.The proposal is available on Github, and objections/arguments can be found on Gavin Andresen's blog. Other proposals and their advantages/disadvantages over this proposal should also be described.
Updated on: 2023-06-10T00:19:32.101143+00:00