Author: Roy Badami 2015-06-24 17:24:45
Published on: 2015-06-24T17:24:45+00:00
Gavin Andresen proposed a BIP to increase the maximum block size from one megabyte to a maximum size that grows over time at a predictable rate. The proposal prioritizes implementation simplicity as simpler code is better for consensus-critical code. To deploy the proposal, hash-power supermajority vote will control it, and the earliest possible activation time is 2016-01-11 00:00:00 UTC. Furthermore, miners can collude today to lower the block size limit without building on larger blocks. Jeff Garzik's BIP-100 suggested a hard fork to remove the static 1MB block size limit, add a new floating block size limit set to 1MB, and historical 32MB message limit remains. This proposal makes a static value grow or shrink in an unpredictable manner based on voting mechanics that are untested in this capacity in the bitcoin network. Introducing a highly variable and untested dynamic into an already complex system is unnecessarily risky. The largely arbitrary voting rules listed in BIP-100 can be gamed, which would force an exodus to a sidechain/altcoin or choke out the Bitcoin network. Gavin Andresen's proposal offers a simpler solution with predictable growth, which gets the job done potentially permanently. There are unavoidable tradeoffs to increasing the maximum block size; hence, increasing the maximum size reduces the impact of the one-megabyte-every-ten-minutes limit imposed by the one megabyte maximum block size on Bitcoin adoption and growth. The proposed block size increase, taken from Jeff Garzik's BIP100, is designed to allow 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 one large mining pool does not have effective veto power over a block size increase. The version number scheme is designed to be compatible with Pieter's Wuille's proposed "Version Bits" BIP. 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. The implementation can be found on GitHub. There are objections/arguments (which are not summarized) and other proposals with their advantages/disadvantages over this proposal (which is also not described).
Updated on: 2023-06-10T00:18:45.863936+00:00