Published on: 2015-06-20T20:07:53+00:00
The discussion revolves around the appropriate supermajority threshold for a hard fork in the Bitcoin network, with a focus on block size. Gavin Andresen proposes a 75% threshold, which the writer sees as problematic because it could lead to competing ecosystems claiming to be 'the real Bitcoin'. Therefore, the writer believes it is necessary to design the hardfork mechanism to prevent such an outcome.Pieter Wuille argues against using a 95% threshold for the hard fork, as it can lead to confusion among non-miner nodes and allow the old chain to keep growing. He suggests using a timestamp switchover or adding a block voting threshold with a 100% threshold to keep humans in the loop.The debate also discusses the challenges of ensuring all nodes upgrade during a hard fork. David Vorick believes it is unreasonable to expect every node to upgrade, while Wuille argues that it is important to consider nodes powering miners that produce blocks. They discuss the need for a mechanism to determine when all nodes have upgraded without risking a fork.Wuille expresses his opinion against using a block version vote as a trigger mechanism for hard forks, suggesting it is a bad idea that can confuse non-miner nodes. He recommends a timestamp switch-over or a block voting threshold with a 100% threshold.Overall, the discussion highlights the importance of determining the appropriate level of consensus required for a hard fork and the challenges of ensuring all nodes upgrade to the new code. Pieter Wuille's suggestions for a timestamp switchover or a block voting threshold with a 100% threshold are presented as potential solutions.
Updated on: 2023-08-01T13:27:13.044448+00:00