Published on: 2014-06-20T00:45:29+00:00
In June 2014, Gavin Andresen, Chief Scientist of Bitcoin Foundation, discussed the consensus on soft-forks bumping version numbers. He suggested converting a related Github Gist into an informational BIP and addressed concerns about malleability being unrelated but related to IsStandard. He mentioned that detecting scripts leaving extra items on the stack would be handled in a separate code part from the implemented pull request. In another email conversation, Andresen and Peter Todd debated proposed changes to Bitcoin's code. Andresen suggested that all changes should be separate pull requests to ease review, while Todd argued that the malleability protection change had already undergone extensive review. They also discussed future soft-forks, whether they would require a transaction nVersion bump or if a whitelist was necessary for invalid up-version transactions. Todd noted that restricting opcodes to the softfork-safe subset was simple and could be removed later, along with concerns about "do-nothing" behavior and compatible evalscript() code.Andresen proposed opening up the "IsStandard" transaction rules in 2014 to allow more complicated transaction forms like multi-signature. However, he suggested keeping the limit of 15 ECDSA signature checking operations per transaction output to prevent attackers from creating a single standard transaction requiring significantly more validation. The proposal allowed any combination of enabled Script opcodes, but the reference implementation's wallet only recognized P2SH transactions using standard forms. Specialized wallets or applications were needed for new transaction forms. Wladimir supported the proposal, emphasizing the importance of lifting restrictions while maintaining DoS limits.The discussion focused on opening up the "IsStandard" transaction rules on the main Bitcoin network to enable multi-signature and other complex transaction forms. Two risks were identified: potential chain-forking bugs in seldom-used opcodes and the possibility of a denial-of-service attack through expensive-to-store-or-verify transactions. Despite these risks, Andresen believed the likelihood of bugs was low, and measures were in place to mitigate DoS attacks. The proposal allowed any Script with 15 or fewer signature operations as a P2SH script to be relayed and mined by the reference implementation. A soft-fork-safe patch was also being developed, defining an opcode whitelist and considering scripts leaving extra items on the stack as non-standard due to malleability concerns. The patch included all opcodes except invalid ones and OP_NOPx opcodes that could be redefined in future soft-forks. Rejecting transactions with unknown nVersion ensured that miners with older versions of Bitcoin Core would only mine transactions considered valid by the new version. Andresen offered to add these changes to an existing patch and submit a pull request.In summary, the discussion revolved around the consensus for soft-forks bumping version numbers and the suggestion to convert a Github Gist into an informational BIP. There were debates about separating changes into pull requests, the necessity of a whitelist for future soft-forks, and concerns about malleability and evalscript() code. The proposal aimed to open up "IsStandard" transaction rules to accommodate multi-signature and complex transaction forms, while mitigating risks through limitations and soft-fork-safe patches. Specialized wallets or applications would be required for new transaction forms.
Updated on: 2023-08-01T09:35:50.476716+00:00