Block Size Increase

Summary:

In an email dated May 6, 2015, Matt Corallo expressed his opposition to any commitment to a block size increase in the near future. Miners have the ability to soft-fork to reduce the maximum block size, with the limit being set by the minimum of the miner's and the merchants'/users' size. The question being debated is what maximum block size merchants and users would accept, which would also serve to put a reasonable limit on the maximum size miners can increase the block size to. Corallo believes that by not increasing the block size, the Bitcoin ecosystem can continue to build systems that rely on transactions moving quickly into blocks while pretending these systems scale. He advocates for working on technologies that bring Bitcoin's trustlessness to systems that scale beyond a blockchain's necessarily slow and expensive settlement. Corallo proposes that miners be allowed to specify the maximum block size in their block headers so they can coordinate to adjust the block size. If 75% of miners vote to lower the size, it will be lowered, and vice versa for raising the size. Every 2016 blocks, the votes are counted, and if the 504th lowest of the 2016 blocks is higher than the previous size, then the maximum block size is set to that size. Similarly, if the 504th highest is lower than the previous size, it becomes the new size. To handle large blocks (>32MB), a change to the p2p protocol message size limits or a way to split blocks over multiple messages would be necessary. Corallo suggests adding an auxiliary header, where the Merkle root in the header could be replaced with hash(merkle_root | hash(aux_header)), as a fairly simple change that could help with commitments. One of the fields in the auxiliary header could be an extra nonce field, which would allow for fast regeneration of the merkle root for ASIC miners.

Updated on: 2023-06-09T19:30:26.301257+00:00