Draft BIP : fixed-schedule block size increase



Summary:

The bitcoin-dev mailing list discusses the possibility of combining BIP 100 and BIP 101 to increase consensus. The proposed combined version would involve a miner vote threshold, a notice period or earliest start time, a block size default target set to 1 MB, a soft limit set to 1MB, and a hard limit set to 8MB with doubling every two years. Miners could leave the 1MB limit in place initially, but the vote is to get the option to increase the block size. Legacy clients would remain in the network until >80% of miners vote to raise the limit and a miner produces a >1MB block. If the growth rate over-estimates hardware improvements, a limit could be added into the core client. One of the concerns raised by mining pools is that they won't run XT because it is "experimental". There has been consideration given to making available a version of XT with only the blocksize changes. The least experimental version would be one that makes the absolute minimum changes to core. The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip changes, saving the creation of a new function. Without the consensus measuring code, the patch would be even easier. Satoshi's proposal was just a block height comparison (a year in advance). The state storing code is also another complication. If the standard "counting" upgrade system was used, then no state would need to be stored in the database.


Updated on: 2023-06-10T00:25:40.172923+00:00