Published on: 2017-04-18T12:37:29+00:00
The proposed uaversionbits aims to simplify the activation process of BIP9 by introducing a boolean flag to ensure lock-in of a BIP9 deployment by the timeout. This allows for user-activated soft forks that can be activated early by the hash power. However, one criticism is the lack of a back-out procedure if a critical flaw is found after activation. To address this, the author suggests using a second version bit as an abandonment vote, which would require sufficient hashpower to abandon the protocol change. This changes the dynamic from BIP9's "opt-in" system to an "opt-out" system, still governed by hashpower but less susceptible to minority miner veto.In an email exchange between two individuals, it was challenged whether a misconfiguration could result in a stopped chain. The respondent clarified that this statement is only true for BIP9 soft forks. They explained that if rule changes are made at different times from the chain with the most work, there could be subjective hardfork-ness. This occurs when miners create blocks that the economic majority accepts despite having less restrictive rules than other chains. The segwit soft fork narrows the definition of a nonstandard transaction, and any block with a transaction violating cleanstack on a non-segwit chain would likely be considered malicious. However, they acknowledged that future forks may restrict more common things. In response to the suggestion of notifying users when a newly activated soft fork rule causes a block to be rejected, the respondent suggested that clients could make these decisions themselves.A discussion on the Bitcoin-dev mailing list revolved around the failure mode of a user's misconfiguration of nTimeout, which could result in a stopped chain. Praxeology Guy pointed out that this claim is incorrect since BIP9 only applies to soft forks and not hard forks. To have a stopped chain with a soft fork, a user must adopt more stringent rules while someone maliciously creates an invalid block that is valid to older nodes, and no miner ever mines a different block at the height of the block in question. Praxeology Guy also suggested that users should be notified when a newly activated more stringent soft fork rule causes a block to be rejected, as it could serve as an excellent trigger to enable replay attack prevention.The importance of understanding and properly configuring nTimeout to avoid potential issues with blockchain progress is highlighted. It is suggested that if less-sophisticated users are given these configuration settings, any chaintip progress failures resulting from them should be displayed prominently. Clear and visible notifications when such failures occur are emphasized, particularly for users who may not be as familiar with the technology.A proposal to orphan valid old blocks has been deemed unnecessary. The "lockinontimeout" variable has been extracted so that the same method can be used in future softfork proposals instead of hardcoding a special case hack for SegWit. Users are suggested to have the ability to set this variable in a configuration file, along with the "nTimeout" in "src/chainparams.cpp". This would allow users to expedite when a softfork becomes active on their node when combined with "lockinontimeout". Developers like the Core team could provide more conservative values in the program, while community members such as miners and nodes who feel strongly about SegWit could either compile their own settings or use a popular configuration file if available.The proposed BIP is an extension to BIP9 that introduces an additional activation parameter to guarantee the activation of backward-compatible changes, or soft forks. It aims to simplify the original uaversionbits proposal by introducing a boolean flag to ensure lock-in of a BIP9 deployment by the timeout. This combines optional flag day activation with BIP9, allowing for user-activated soft forks that can be activated early by the hash power. The specification adds a new per-chain deployment parameter to the existing BIP9 specification. A reference implementation of the proposed BIP is available on GitHub, and the document is licensed under BSD 3-clause and Creative Commons CC0 1.0 Universal.
Updated on: 2023-08-01T20:18:52.263031+00:00