Published on: 2015-08-27T22:11:10+00:00
In August 2015, a discussion took place on the Bitcoin-dev mailing list regarding the implementation of nVersion mask and IsSuperMajority() in the Bitcoin protocol. The proposal aimed to address issues related to different miners and soft-fork warnings. It suggested masking the nVersion bits set by XT/Not-Bitcoin-XT miners before applying the IsSuperMajority() logic. This would allow CLTV/CSV/etc. miners running Bitcoin Core to create blocks with nVersion=8, while XT/Not-Bitcoin-XT miners would advertise blocks that do not trigger the soft-fork. The proposal also mentioned the possibility of using the same masking technique for future soft forks. One developer proposed masking all bits except the 4th bit to enable concurrent voting on other fork proposals.It was clarified during the conversation that the masking would only be applied during the voting stage. Once the soft fork is fully enforced with 95% support, the nVersion will simply be >=8 without any masking. Due to the seriousness of the issues caused by Bitcoin XT, it was suggested that the original proposal should be converted into an informational BIP. As a result, BIPS 112 and 113 were modified to reflect the amended deployment strategy.Another aspect discussed was the use of nVersion bits to signal support for specific upgrade forks in the Bitcoin protocol. One proposal suggested using nVersion & 0x8 as a signal for support while keeping the consensus rule as nVersion >= 4. However, concerns were raised about potential conflicts between upgrades and the need to reject blocks with versions lower than 8 if a new upgrade is accepted by a majority of nodes. A possible solution was proposed, involving setting N (the height at which the rule is active) one year from now or so, and giving a period of time after lock that bit 8 will be kept and another period where it is guaranteed to be zero.The implementation of the proposed CLTV, CSV, etc. soft-forks faced challenges due to the presence of XT and Not-Bitcoin-XT miners. These miners produced blocks with nVersion=0x20000007, which would falsely trigger the previously suggested implementation using the IsSuperMajority() mechanism and nVersion=4 blocks. Furthermore, the XT/Not-Bitcoin-XT software lacked the implementation of fork deadlines, making it difficult to fully support the nVersion soft-fork mechanism.To address these issues, three options for the deployment of CLTV/CSV/etc. were proposed. The first option, using plain IsSuperMajority() with nVersion=4, was deemed high risk and ruled out immediately. The second option, nVersion mask with IsSuperMajority(), was recommended. This option involved masking away the nVersion bits set by XT/Not-Bitcoin-XT miners before applying the standard IsSuperMajority() logic. CLTV/CSV/etc. miners running Bitcoin Core would create blocks with nVersion=8, while XT/Not-Bitcoin-XT miners would advertise blocks that do not trigger the soft-fork. This solution allowed for soft-fork warnings to be triggered for both XT/Not-Bitcoin-XT blocks and future nVersion bits implementations, with the highest known version remaining as nVersion=8.The most complex option for deployment was the full nVersion bits implementation using flag bit #4 to trigger the fork. Compliant miners would advertise 0x20000008 initially, followed by 0x20000000 once the fork had triggered. The lowest three bits would be unusable for forks for some time, but they could eventually be recovered as XT/Not-Bitcoin-XT mining ceased.Overall, the focus should be on the proposed featureset rather than the deployment method. It is believed that versionbits, once implemented, will be essential for rolling out multiple features in parallel without waiting for activation and enforcement each time. In the absence of versionbits, the recommended approach is to use the nVersion mask with IsSuperMajority() to address the complications caused by XT and Not-Bitcoin-XT miners.
Updated on: 2023-08-01T15:32:53.245258+00:00