Published on: 2016-09-04T12:29:37+00:00
The discussion revolves around the bundling of two independent softforks in one release, raising concerns about increased testing and maintenance burdens. Testing is required for four scenarios: both softforks not activated, only NULLDUMMY activated, only SEGWIT activated, and both activated. A significant percentage of miners are hard-coding the block version number, which poses risks to the softfork transition as miners may not enforce what they signal. Bundling two independent softforks would double the risks, with NULLDUMMY alone deemed not worth the associated risks.On September 2, 2016, at 1:10 PM, Tom Harding via bitcoin-dev questioned the rationale behind bundling the two independent softforks together, suggesting that miners should have the opportunity to vote on them separately. The proposed BIP (Bitcoin Improvement Proposal) by Johnson Lau, introduced on September 1st, 2016 at 9:40 PM, suggests deploying a BIP using "version bits" BIP9 with the name "segwit" and using bit 1, employing the same parameters as BIP141 and BIP143. However, concerns were raised regarding why this fix should be bundled with segwit and whether independent voting should be allowed, as this fix has value beyond segwit.On September 2, 2016, Johnson Lau announced the deployment of BIP9 using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The BIP9 starttime and timeout for Bitcoin mainnet are still to be determined, while for Bitcoin testnet, the starttime is midnight May 1, 2016 UTC, and the timeout is midnight May 1, 2017 UTC. The reference client has been generating compatible signatures since its inception, and the null dummy rule has been enforced as relay policy by the reference client since v0.10.0. No transactions violating this requirement have been added to the chain since at least August 2015. It should be noted that for all scriptPubKey types in actual use, non-compliant signatures can easily be converted into compliant ones, except for cases where conversion is not possible.The proposed changes to the Bitcoin transaction validity rules are outlined in this BIP, aimed at addressing the malleability issue of extra stack elements for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. Signature malleability allows any relay node on the network to alter the signature in transactions without requiring access to relevant private keys, posing a security concern. The "NULLDUMMY" consensus rule is introduced to address this issue, requiring the dummy element to be an empty byte array, resulting in false evaluation if anything else is used. This BIP will be deployed using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The reference client has been generating compatible signatures from the beginning, and the null dummy rule has been enforced as relay policy by the reference client since v0.10.0. An implementation for the reference client can be found at https://github.com/bitcoin/bitcoin/pull/8636.In summary, the discussion highlights concerns about bundling two independent softforks together, increasing testing and maintenance burdens. Questions were raised regarding the need for independent voting and whether the proposed fix has value beyond segwit. Johnson Lau announced the deployment of BIP9 using the same parameters as BIP141 and BIP143, named "segwit," and utilizing bit 1. The proposed changes aim to address the malleability issue of extra stack elements for OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY through the introduction of the "NULLDUMMY" consensus rule. The reference client has been generating compatible signatures and enforcing the null dummy rule since v0.10.0, with no transactions violating the requirement added to the chain since at least August 2015.
Updated on: 2023-08-01T19:00:17.209421+00:00