Author: Gavin Andresen 2011-12-29 18:00:23
Published on: 2011-12-29T18:00:23+00:00
In a discussion about preventing OP_EVAL from executing the result of calculations, it is suggested that "OP_EVAL shall fail if asked to execute 8 or fewer bytes". However, some users argue that this rule is inadequate as OP_SHA256 OP_EVAL runs random code that is more than 5 bytes. Furthermore, there is a debate about the advantages and disadvantages of non-executed branch of an OP_IF. The "Either This or That can redeem" case motivated Gavin Andresen to allow for 2-deep EVAL recursion. For backwards compatibility with old clients, the definition of CODEHASH needs to be modified to hash only the stuff between CODESEPARATORS instead of hashing from CODESEPARATOR to the end of the scriptSig. Regarding static analysis, Gavin mentions that miners are "discouraging" anything besides 'standard' transaction types. He believes that until somebody smarter than him has done a deep analysis of Script and all of its opcodes, things should remain the same. Gavin argues that in practice, he does not believe that EVAL as proposed is a danger. Finally, in response to delaying EVAL rollout, Gavin suggests rolling out just BIP 11 (up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and delaying EVAL rollout on the main network. However, he worries that this will only encourage people to delay reviewing/testing for a couple of months.
Updated on: 2023-06-05T01:24:16.853325+00:00