Published on: 2013-07-29T08:13:55+00:00
The email exchange between John Dillon and Peter Todd discusses the potential uses of non-standard transactions to implement oracles and one-time-password protection of wallet funds. The proposal suggests creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH, while retaining the existing standard whitelist for scriptPubKeys. However, it is important to retain the IsStandard() check, especially the AreInputsStandard() check, if a P2SH serialized script follows a standard form. This is because transaction mutability can affect unconfirmed transaction chains in flight.The proposal recommends considering transactions non-standard or not allowed at all in a future soft-fork if there is more than one stack item left at the end of execution. A opcode whitelist should probably be implemented to achieve this. The proposal also suggests that CHECKMULTISIG should always be zero to avoid mutability issues. The email asks for an example where imposing a one-stack-item-at-the-end-of-execution rule causes problems.In general, the email suggests that Bitcoin should have been designed so that CHECKSIG signed hashes of scriptPubKeys instead of txid:vout outputs to prevent malleability from affecting the validity of a signature. The proposal acknowledges that this would mean that signatures could be reused if scriptPubKeys were reused, but address re-use is considered a bad thing anyway.Jeff Garzik and Luke-Jr discussed creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH. John Dillon suggested dropping pay-to-pubkey and pay-to-multisig due to their potential for dumping data in the UTXO set. However, Luke-Jr stated that some specific standard forms would still be necessary for interoperability between wallets without a much smarter solver.Luke-Jr wrote to Jeff Garzik regarding the whitelist for specific opcodes in scripts serialized using P2SH. Luke-Jr believes that this approach could be reasonable for miners, but a much smarter solver would be required for interoperability between wallets. Without this, specific standard forms would still be necessary. Current designs are based on pattern matching a script template, and Satoshi described lightweight clients as needing no script engine at all, only the ability to match patterns.In another discussion, John Dillon proposed the idea of creating a whitelist for specific opcodes in scripts serialized using P2SH. He suggested dropping pay-to-pubkey and pay-to-multisig due to their potential for dumping data in the UTXO set. While this may be reasonable for miners, it could pose issues for interoperability between wallets. Therefore, some specific standard forms would still be necessary without a much smarter solver. However, expanding the code required to implement a wallet may be necessary.Peter Todd suggests two uses for non-standard transactions: implementing oracles and one-time-password protection of wallet funds. The oracle case would benefit from more arbitrary rules. The author recommends creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH and dropping pay-to-pubkey and pay-to-multisig. The whitelist should contain various opcodes for complex logic but avoid arithmetic operations to prevent potential problems.
Updated on: 2023-08-01T05:27:14.183756+00:00