Author: Luke Dashjr 2016-02-04 18:29:11
Published on: 2016-02-04T18:29:11+00:00
On February 4th, 2016, jl2012 via bitcoin-dev proposed a change in the "version" field of Bitcoin block headers to indicate the deployment of a hardfork. The proposal suggests that one and only one flag block should be present for any planned hardfork, which acts as the point of no return. This flag block must be determined by block height or the first block with GetMedianTimePast() greater than a threshold, making it consensus critical and publicly verifiable with only blockchain data. The proposal also suggests employing the version bits mechanism to measure miner support towards a hardfork proposal and determine the time threshold of the flag block. After the flag block is generated, miners can support either the original rules or the new rules but not both and cannot attack or overtake the other fork without giving up the mining reward of their preferred fork. Automatic warning systems are expected to alert full nodes and SPV nodes about flag blocks for unknown hardforks on the network and potentially stop accepting/sending transactions. However, this system is vulnerable to DoS attacks by rejected hardforks. The proposal suggests that wallet programmers decide the optimal strategy, and a human warning system could fill the gap. The proposal suggests using the hardfork version bit as a mechanism to ensure a clean break during an emergency hardfork, even though median-time-past and height are superior methods that ought to be used for hardforks. The proposal recommends avoiding implying that BIP 9 should be used for hardforks or that miners have any voice in the decision.
Updated on: 2023-06-11T03:36:00.931004+00:00