Author: Gavin Andresen 2011-12-29 16:23:56
Published on: 2011-12-29T16:23:56+00:00
Gavin Andresen, the lead developer of Bitcoin, has expressed his opinion on the proposed alternative to OP_EVAL. Although he is sympathetic to the argument that "OP_EVAL starts down the code-as-data path, and There Be Dragons", he believes that the proposed alternative would not be any better in practice. He sees two main disadvantages over OP_EVAL: it is about 20-bytes larger than the original proposal, and it means going back to where they were two months ago, writing more code, reviewing it, finding bugs, etc. There are also some minor disadvantages, including the fact that 'standard' scripts will need to be slightly different in the scriptSig and the scriptPubKey. Gavin Andresen also mentioned that OP_EVALs are not executed so the code associated with them does not 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 the blockchain size.In discussions in IRC yesterday, Gavin Andresen suggested amending BIP 12 to state that OP_EVAL shall cause script validation to fail if the top item on the stack is less than 8 bytes long. He is also tempted to propose a rule that OP_EVAL shall fail if the top item on the stack is the result of any calculation, but he doesn't think the extra code it would take to implement that would be worth it.Lastly, he echoes theymos' observation that he thinks they'll eventually do something very much like OP_EVAL in the future, maybe to support (in a backwards-compatible way) a quantum-computing-resistant signature algorithm or SHA3. When that is done, he thinks it might make sense to do a bottom-up redesign of Script based on what they've learned.
Updated on: 2023-06-05T01:23:54.335378+00:00