Bitcoin is an experiment. Why don't we have an experimental hardfork? [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2015-08-19T18:33:57+00:00


Summary:

The Bitcoin community has been engaged in discussions about increasing the block size limit. One proposal suggests a block size increase to 1.5MB, with a backup plan if no consensus is reached. The backup plan involves increasing the block size to 1.5MB, 30 days after receiving 80% miner approval, but not before June 1, 2016. Developers agree to find a better solution by December 31, 2017. The debate also touched on softforks versus hardforks and the importance of upgrading full nodes. It was argued that softforks are not necessarily safer than hardforks, as demonstrated by the recent BIP66 fork. Non-upgrading full nodes were also deemed not true full nodes. The length of the grace period for a hardfork was discussed, with suggestions ranging from four months to five years. The general consensus was that many people won't update until required, making the length of the grace period important.Overall, the conversation highlighted the ongoing debate within the Bitcoin community regarding the block size limit and the best approach to increasing it. Consensus among major stakeholders, including miners, exchanges, merchants, and investors, is crucial for the success of any proposed changes to the Bitcoin network.To address the challenge of convincing enough people to switch without causing damage to the system, a proposal suggests deploying a block size limit experiment on the public global testnet blockchain. This would allow real-world testing of network lag, bandwidth constraints, and traffic bottlenecks. The objective is to demonstrate that consensus for a Bitcoin hardfork is possible, collect data for future hardforks, and relieve pressure on full blocks without affecting network performance.A backup plan has been proposed if no other consensus is reached before February 1, 2016. This backup plan involves increasing the block size to 1.5MB, 30 days after 80% miner approval, but not before June 1, 2016. A better solution is agreed upon to be found before December 31, 2017, with further debate and data collection.The rationale behind these proposals is the belief that technology has significantly improved since the current 1MB cap was set five years ago. A slight increase in block size is seen as providing valuable data for future hardforks. The proposal suggests an 80% miner approval rate to ensure sufficient mining power secures the new fork.If the community agrees with the experimental hardfork, the plan will be announced on bitcoin.org and coding of the patch will begin immediately. If no further consensus is reached, a new version of Bitcoin Core with the patch will be released on or before February 1, 2016, and everyone will be asked to upgrade immediately. The aim is to demonstrate that consensus for a Bitcoin hardfork is possible and pave the way for future hardforks.


Updated on: 2023-08-01T15:29:59.913844+00:00