Author: Stefan Thomas 2011-12-29 19:54:28
Published on: 2011-12-29T19:54:28+00:00
In this email thread, the discussion revolves around the rollout of OP_EVAL on the Bitcoin network. The concern is that delaying the rollout may encourage people to postpone thoroughly reviewing and testing for a couple of months, leading to delays. It is suggested that OP_EVAL should first be released on testnet to build real-life applications and adjust it if issues arise before deploying it on mainnet. The suggestion is considered a textbook use case for testnet.There is also a discussion about preventing OP_EVAL from executing the result of calculations. The rule should be "OP_EVAL shall fail if asked to execute 8 or fewer bytes." There is a suggestion that OP_EVALs are not executed, and hence their code doesn't have to be part of the transaction, if they are in the non-executed branch of an OP_IF. This could be good for privacy and reducing blockchain size.Additionally, there is a conversation about static analysis and how miners may want to do more static analysis besides standard transaction types. However, until someone smarter than Gavin Andresen has done a deep analysis of Script and all of its opcodes, the standard transaction types and the standard types extended with OP_EVAL are easy to reason about. In practice, it is not believed that EVAL as proposed is a danger.Finally, there is a discussion about rolling out just BIP 11 (up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and delaying EVAL rollout on the main network. However, there is a concern that this may encourage people to delay thoroughly reviewing/testing for a couple of months, and we'll be right back here at the beginning of March.
Updated on: 2023-06-05T01:27:10.373432+00:00