Author: Johnson Lau 2016-12-01 17:20:31
Published on: 2016-12-01T17:20:31+00:00
This Bitcoin Improvement Proposal (BIP) suggests implementing a hardfork warning system for both full nodes and light nodes by changing consensus rules related to block nVersion and creating a generalized block header. The reason behind this proposal is that some features cannot be easily introduced with a softfork, such as expanding maximum block resource limits and changing the average block time interval. Existing full node implementations would consider such blocks as invalid and may even ban a peer for relaying them, leaving users to unknowingly transact on a system with potentially different token value.The proposed solution defines a change in consensus rules regarding block nVersion and a generalized block header to implement a hardfork warning system. It also specifies the terms used in the proposal, including valid block, valid blockchain, best valid blockchain, valid blockchain fork, generalized block header, and generalized block header chain. In addition, it outlines specifications for a block nVersion softfork and validation of a generalized block header. The hardfork warning system is designed to detect and warn users of a potential hardfork in the blockchain. Setting one or both hardfork notification bits indicates a planned hardfork. If a valid blockchain fork is emerging with non-trivial total proof-of-work, then a consensus disagreement may be happening among different miners. In such cases, a wallet implementation should issue a warning to its users and stop processing incoming and outgoing transactions until further instructions are given. Similarly, a mining implementation should issue a warning to its operator and may either stop mining or mine on top of the best valid chain by its own standard.As an important part of the hardfork warning system, a light node (usually wallet implementations) should observe the hardfork notification bits in block headers along with any other rules it opts to validate. The hardfork warning system is capable of detecting various types of hardforks, including soft-hardfork, redefining the nTime field, redefining the Merkle root hash field and changing block content validation rules, changing average block interval or difficulty reset, introducing secondary proof-of-work, and accidental hardfork. However, changing the proof-of-work algorithm, changing the encoding of previous block header hash or nBits, and a coercive soft-hardfork without setting any hardfork notification bit cannot be detected with this warning system.The only purpose of this system is to inform users that a hardfork might be happening and prompt for further instructions. It does not guarantee that the hardfork will be successful and not end up with two permanent incompatible forks. This requires broad consensus of the whole community and is not solvable with technical means alone. The BIP9 is disabled when any of the hardfork notification bits is set, which may interrupt any ongoing softfork support signalling process. Legacy nodes would not benefit from this softfork and warning system, but no additional risks are introduced to legacy nodes either. The softfork described in the BIP would only affect miners, and no reference implementation has been provided yet.
Updated on: 2023-05-20T00:11:37.515918+00:00