Published on: 2012-02-01T14:14:08+00:00
On January 31, 2012, Andy Parkins proposed changes to the Bitcoin protocol. He suggested replacing the "scriptPubKey" field with a new "hashOfClaimingScript" field and adding an "unsignedParameters" array. However, he later realized that his proposal was essentially BIP16 without backward compatibility work. He suggested renaming the scriptPubKey field to "hashOfClaimingScript" and no longer running it as a script. This format of scriptPubKey would activate "version2" processing of the transaction. The scriptSig would have two fields: unsignedInitialStackBlock and scriptClaim. Parkins concluded that he now supported BIP16 as it moves towards having a literal claimScriptHash field instead of scriptPubKey.On February 1, 2012, Pieter Wuille and Dr. Andy Parkins discussed changes to the Bitcoin protocol. They noted that non-standard transactions are verified in the blockchain but are rejected when entering the memory pool due to the IsStandard() function. They also discussed the importance of upgrading to avoid seeing a fork of the chain from before the first new-style transaction if a breaking change is made to the protocol.On the same day, Andy Parkins had a discussion with Luke-Jr regarding BIP16 and BIP17. Luke-Jr claimed that both proposals were backward compatible enough for users to continue using old clients with each other, but Andy questioned this. It was explained that IsStandard() is used for accepting transactions into the memory pool, and non-standard transactions are verified in the blockchain. BIP16/17 create transactions that, when interpreted as old scripts, are valid. The only change to the protocol is that previously-valid transactions become invalid. As long as a supermajority of miners enforce the new rules, everyone can keep using their old bitcoin client.Gregory Maxwell responded on January 31, 2012, stating that nodes in Bitcoin do not need to trust the network and can validate information themselves. He argued against making breaking changes to the system as it is a zero-trust system and any change would require a client update. However, he considered BIP16/17 not to be breaking changes. The author of the original proposal disagreed but agreed that making such changes would be difficult due to resource requirements. Increasing the version number of the transaction structure was suggested as a reasonable solution.In an email conversation on January 31, 2012, Andy Parkins expressed nervousness about the ongoing debate surrounding BIP16/BIP17. Another participant explained that the differences between the options were technically obscure and generally agreed upon by technically-minded individuals. They referred to Luke's opinion tracker page, which reflects the views of core developers and informed parties. It was noted that BIP16 was the consensus path forward from earlier discussions, while BIP12 was deemed too computationally powerful. Client upgrade would be necessary to make use of new functionality, as Bitcoin is a zero-trust system and breaking changes like those proposed could not be taken lightly.Luke-Jr wrote on January 31, 2012, that there were no remaining tangible objections to BIP17. Both BIP16 and 17 were backward compatible enough for users to continue using old clients with each other. An upgrade was only required to send or receive on the new 3...-form addresses. The practical implications of both proposals could be rewritten in a format suggested by Andy, which would be backward compatible. Only version2 transactions for version2 addresses would need to be made.In another email conversation, Andy Parkins expressed his nervousness about the ongoing debate surrounding BIP17 and BIP16. He suggested that if there were objections to both proposals, then perhaps another solution would be better. He was willing to withdraw BIP17 if a better solution emerged. Both BIP16 and 17 were backward-compatible enough for users to continue using old clients with each other. Upgrades would only be necessary to send or receive new 3...-format addresses. The practical implications of both proposals could be rewritten in the suggested format, which would eliminate one of the major objections to BIP16.The author of an email expressed nervousness about suggesting an idea for a change in transactions. They proposed increasing the version number in transactions and making changes to the transaction structure. The proposal included replacing the "scriptPubKey" field with "hashOfClaimingScript" and adding an "unsignedParameters" array. The hashOfClaimingScript would be the hash of the script allowed to claim the output. The proposal invited feedback from others.
Updated on: 2023-08-01T02:59:30.445170+00:00