Author: Allen Piscitello 2015-06-24 17:24:32
Published on: 2015-06-24T17:24:32+00:00
On June 22, 2015, Gavin Andresen proposed a BIP to replace the fixed one megabyte maximum block size in the Bitcoin protocol. The proposal was to have a maximum size that grows over time at a predictable rate. This would give miners, merchants, and full-node-running-end-users sufficient time to upgrade to software that supports bigger blocks. A 75% supermajority was chosen so that no single large mining pool has effective veto power over a blocksize increase. On June 23, 2015, odinn suggested working with Jeff Garzik, as well as other developers, to move forward on BIP-100 and not get caught up in XT. It was also argued that the largely arbitrary voting rules listed in BIP-100 above can be gamed, potentially making it unnecessarily risky. Raystonn responded to Jeff Garzik's comment on June 24, 2015, saying that miners can lower their own block sizes but cannot currently lower the sizes of blocks mined by others. Proper communication can coordinate soft forks easily, and laziness in leaving the default size is common but not collusion, nor an attempt to manipulate the block sizes of other miners.The proposal to increase the maximum block size is a hard-forking change, 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 implementation of the proposal can be found on GitHub. The article also mentions the need to describe other proposals and their advantages/disadvantages over this proposal.
Updated on: 2023-06-10T00:17:55.366820+00:00