Friday 2 June 2017

A reminder of just how dangerous the Bitcoin Classic activation methodology was and why the community opposed it


As a reminder, Bitcoin Classic was a contentious hardfork proposal for 2MB blocks, with a particularly dangerous activation methodology, which was why many in the community opposed it.The characteristics of Bitcoin Classics's activation were as follows:75% rolling miner "voting" - In contrast to a "voting" window (like SegWit for example), there was 75% rolling "voting" for the hardfork proposal. This guarantees that at the time of the hardfork activation, exactly 25% of the miners would not have upgraded. This therefore ensures that there are two chains and two coins. The rolling "voting" excludes even the possibility of allowing all the miners to upgrade and prevent a chainsplitTwo week grace period - The grace period before the hardfork and blocks over 1MB being produced was just two weeks, an incredibly short period of time, meaning it was very likely many users would not have upgradedNo checkpoint - There was no checkpoint for the hardfork chain. As an illustrative example, Bitcoin Classic could have had a rule which stated that the first block after activation must be over 1MB, but it didn’t have such a rule. Instead, if speculators decided to invest in the original chain and drive the price up, miners could have then switched to it, then if it became the most work chain, Bitcoin Classic nodes would regard the original rules chain as Bitcoin. The transaction history of Bitcoin Classic would have been discarded.The combination of these factors, combined with a small minority of people who were unhappy with 2MB blocks at the time (mostly due to a lack of fixes for quadratic hashing), made this hardfork proposal extremely dangerous. In my view, a “total wipeout” was extremely likely, or almost certain. This would have resulted in a loss of funds for many users and significant damage to the integrity of the ecosystem.Bitcoin is very lucky that that the Core development team decided not to merge such code and that many users were smart enough not to run Bitcoin Classic.I hope as a community, we are humble enough to acknowledge that future upgrade proposals can be done in a much more robust way than Bitcoin Classic. Then we can hopefully end this contention, and collaborate to develop and test safer, more responsible ways of upgrading the network rules. via /r/Bitcoin http://bit.ly/2slK66m

No comments :

Post a Comment