Published on: 2014-11-05T07:53:03+00:00
Pieter Wuille has addressed some issues with the rules for Bitcoin Improvement Proposal (BIP) 62 in a Github pull request. The changes include better names for the rules, clarification on the interaction of BIP62 with P2SH, and the requirement of known hashtypes despite not being part of DER. He also suggests using v2 transactions instead of v3 transactions and applying optional rules only to strict v2, not higher or lower.In response, Peter Todd expresses skepticism about using nVersion==3, preferring to disconnect TX and block version. He believes there may be circumstances where two different new tx version numbers might need to be introduced in a single soft-fork. Todd also notes that transactions can be verified for correctness outside of a block.In a discussion among developers on Bitcoin Improvement Proposals, Todd expresses skepticism about choosing nVersion==3 for blocks and transactions. Jeff Garzik agrees with this concern and prefers to disconnect block version and transaction version. Pieter Wuille sees consensus rules as one set of rules but has no strong opinion and is fine with using nVersion==2 for transactions. They discuss the possibility of introducing two different new tx version numbers in a single soft-fork in the future and how transactions can be verified outside a block.In an email exchange, Garzik and Todd discuss the choice of nVersion==3 in relation to block version increases. Todd is skeptical about this rule and believes future increases in block.nVersion could be unrelated to transactions. Garzik agrees and cites previous ambiguity from bumping tx version due to changes in block version. While Garzik acknowledges the change, he prefers to disconnect TX and block version. Todd proposes using a single numbering system for consensus rules since they only apply to blocks. Garzik has no strong opinion and is fine with using nVersion==2 for transactions.Peter Todd expresses his skepticism towards the choice of nVersion==3 and argues that future block.nVersion increases may have nothing to do with transactions. He believes creating such a rule would be counterproductive as it would quickly be broken. Jeff Garzik agrees and shares his experience with ambiguity resulting from bumping tx version due to an increase in block version. While Garzik acknowledges the change, he prefers to disconnect TX and block version.Pieter Wuille submits a Pull Request to clarify the "clean stack" requirement in BIP62, which makes passing more inputs to a script than necessary illegal. An exception is needed for P2SH scripts as the test can only be done after the second stage evaluation. However, this rule is incompatible with future P2SH-like constructs, and any such upgrade would require an exception in the clean-stack rule, which is no longer a softfork once deployed. Luke suggests not applying this rule on every transaction with nVersion >= 3, which solves the problem. Peter Todd agrees and suggests making the rules only apply to transactions with strict nVersion==3.On November 4, 2014, Pieter Wuille suggests a solution to applying rules on every transaction with nVersion greater than or equal to 3. Luke's suggestion of not applying this rule on every transaction resolves the issue. Pieter believes this solution can be generalized by making the non-mandatory BIP62 rules only applicable to transactions with strict nVersion==3 and not higher ones. Gavin Andresen agrees, stating that soft-forking is useful for upgrades and should not be prohibited.Mike Hearn and Pieter agree that the desire for soft forks sometimes leads to ugly hacks. They also believe that hard forks should be possible when useful. However, hard forks have a higher risk that may not always be justified. Introducing a new transaction type without a hard fork is possible and avoids the risks. Additionally, hard forks reduce the security model of former full nodes to SPV without their knowledge. They suggest being aware of the effects of changes like this to keep future soft forks open as an option.The problem of using scripts-which-are-not-scripts in Bitcoin can be solved by implementing a hard fork upgrade known as "script 2.0." The current system relies on these hacks due to the desire to avoid a hard fork, but implementing this upgrade would eliminate the need for them. It is important to note that this issue exists solely because of the preference for a soft fork and the subsequent need for workarounds.A discussion has been initiated regarding the "clean stack" requirement in BIP62. An exception is needed for P2SH scripts as the test can only be done after the second stage evaluation, and rejecting all spends from P2SH would complicate matters. A pull request has been submitted to clarify this issue in BIP62. Additionally, the clean-stack rule is incompatible with future P2SH-like constructs that could be useful for deploying "Script 2.0". Any upgrade to such a system would require an exception in the clean-stack rule, which is no longer a softfork once deployed.
Updated on: 2023-08-01T10:36:29.684991+00:00