A summary of block size hardfork proposals (and a softforking one)

Summary:

In a recent bitcoin-dev thread, four block size BIPs were discussed by Bitcoin developers, along with a series of questions to summarize the proposals. The four BIPs are: BIP100 by Jeff Garzik, which proposes a 1MB block size with the ability for miners to vote and increase or decrease by 0.5x - 2x every 12000 blocks (~3 months); BIP101 by Gavin Andresen, which proposes an 8MB block size, doubling every 2 years with interpolations in between (41.4% p.a. ); BIP102, also by Jeff Garzik, which proposes a 2MB block size; and BIP103 by Pieter Wuille, which proposes a 1MB block size and a +4.4% increase every 97 days, doubling every 4.3 years, or 17.7% p.a.The discussion also included questions such as whether there should be a BIP34-like voting mechanism to initiate the hardfork, when the hardfork should be initiated, what the block size should be at initiation, whether further increase/decrease should be allowed, and what should be the earliest date for a >=2MB block and the final block size. Additionally, Cameron Garnham contributed to the discussion with remarks from an earlier thread, where he explained his proposal for dynamic block size adjustment, which would introduce a consensus protocol for block sizes rather than just having a hard limit enforced by everyone. This proposal is entirely a soft-fork and may be implemented without changing any client code whatsoever. It could be implemented by only a simple 51% majority of miners, with-or-without gaining the wider community consensus.Overall, this discussion highlights ongoing debates within the Bitcoin community regarding block size and the best method for adjusting it in accordance with the growing demand for transactions on the network.

Updated on: 2023-06-10T17:54:09.495586+00:00