Published on: 2014-09-29T05:35:26+00:00
In a discussion about adding new opcodes to P2SH, Alan Reiner suggested updating the address format to include a transaction version number. However, Peter Todd argued that this would require new addresses for each new opcode, which goes against the purpose of P2SH. He also pointed out that when a wallet creates a transaction, the scriptPubKeys in the outputs are determined by the receiver(s) and are not executed until they are spent. Therefore, the wallet does not need to be concerned with the contents of those scriptPubKeys. Additionally, determining which version number to use becomes difficult when there are multiple recipients.Peter Todd further criticized Satoshi's implementation of a per-block sigop limit, stating that it computes the limit based on all scriptSigs and scriptPubKeys in the block, even though the latter are not executed. This allows for blocks that pass the sigop limit but execute expensive signature operations by having scriptSigs spending txouts with large numbers of sigops in their scriptPubKeys. While P2SH improves on this situation by counting the sigops in redeemScripts towards the limit, it misses the opportunity to count all sigops in all scriptSigs directly.In an email thread from September 28th, 2014, Peter Todd suggests upgrading the address format to indicate that senders must use a transaction with an increased version number to solve a specific issue. However, he acknowledges that creating new addresses for every new opcode would defeat the purpose of P2SH. Another developer proposes a single update to the address format that includes a transaction version number, prompting sending software to apply that version to the payment transaction. While this may work for soft forks, there are potential subtleties and safety concerns to consider.The discussion revolves around the process of soft forks bumping version numbers in Bitcoin. There is consensus that this is the preferred method, and Gavin Andresen's proposal on Github has been suggested to become an informational BIP. However, one user highlights an issue with the proposal regarding the unclear definition of "use" for a new opcode. If scriptPubKey evaluation is based on the transaction version number of the creating transaction, non-upgraded clients sending funds to a P2SH address with a redeemScript using a new opcode may create scriptPubKeys that can be spent by anyone. Conversely, if scriptPubKey evaluation is based on the version of the spending transaction, outputs using the new opcode can be easily spent.The assertion that "P2SH should have been done by upgrading the tx version #" for future opcode upgrades is incorrect. Additionally, the "Relax IsStandard rules for P2SH transactions" pull request is incomplete as it does not blacklist the usage of upgradable NOPx opcodes. This could lead to non-upgraded nodes accepting and mining transactions that are now invalid, resulting in false confirmations. To address this issue, a pull request has been created to specifically blacklist the NOPx opcodes if they are executed.Furthermore, the "Blockchain Rule Update Process" gist should be rewritten to state that new opcodes will be enabled for all scripts through the block nVersion upgrade mechanism. BIP62 proposes increasing the transaction version number to indicate the sender's desire for anti-malleability rules to be applied. This usage of tx version numbers is appropriate as the creator of the transaction wants the anti-malleability rules applied, while the person creating the scriptPubKey being spent does not care. The new owners of the txouts being created typically do not care how they were created.
Updated on: 2023-08-01T10:21:58.503901+00:00