Published on: 2012-01-02T17:10:25+00:00
A proposal has been made to create a new transaction type called "pay to Script hash" that allows users to publish a short "funding address" that is the hash of an arbitrary redemption script. The proposal aims to implement this in a backward-compatible-in-the-blockchain way. It is considered a cleaner and more straightforward implementation than the previous proposal, OP_EVAL. Clients/miners will recognize this new transaction type and do additional validation.There was some discussion on whether to make the script: OP_NOP1 HASH160 EQUAL to make it easier to identify as a special transaction but the consensus was that every byte matters and code replacement would be more common. Overall, it is considered a cleaner and more straightforward implementation than OP_EVAL with no special cases.The proposal suggests making two amendments to the script. First, make the script: OP_NOP1 HASH160 EQUAL to make it extremely easy to see from the first byte that this is very likely to be a special transaction. Second, if you feel like spending another byte, make the script: OP_NOP1 and assign 1 to this special script, making this case: OP_NOP1 OP_1 HASH160 EQUAL. This proposal is cleaner than OP_EVAL and more straightforward to implement.The current proposal eliminates the static analysis properties in Bitcoin, as it can stand for any number of operations, which might be part of some piece of data and change the script that is executed by OP_EVAL at runtime. However, proponents argue that it is possible to "dry run" the script, avoiding the expensive OP_CHECKSIG operation and running only the other very cheap operations. But a dry runner cannot predict the outcome of conditional branches in the presence of an OP_CHECKSIG, so it has to either do the OP_CHECKSIG or follow both branches. This makes it too complicated to involve the protocol rules such as the sigops limit. Several proposals for OP_EVAL that allow static analysis have been suggested, such as using a fixed position reference prefix, using an execute bit on data set by an opcode, using OP_CODEHASH, using OP_CHECKEDEVAL, and using OP_HASH160 OP_EQUALVERIFY as a special sigPubKey.In a discussion about the Bitcoin script language, Joel Joonatan Kaartinen suggested restricting the number of executions of OP_EVAL allowed per transaction to prevent unlimited looping. However, roconnor at theorem.ca warned that OP_EVAL adds dangerously expressive power to the scripting language. The addition of OP_EVAL made the script language essentially Turing complete, with only an artificial limit on recursion depth preventing arbitrary computation. Despite the potential for expressive power, some consider OP_EVAL to be dangerous.In an email conversation, a person explains the significance of OP_DUP in creating looping operations and achieving Turing completeness. They also suggest that using stack operations, one can implement the SK-calculus given an OP_EVAL that allows arbitrary depth. The writer mentions the concatenative programming mailing list where people create stack languages with minimal operations that exploit similar functionality to reduce the required built-in operations. The discussion on the list is mostly about stack-based languages where programs can be pushed on the stack and executed. However, they question whether the scripting engine in bitcoin has the ability to manipulate scripts on the stack to be evaluated.In an email thread discussing alternative proposals to OP_EVAL, Alan warns against the potential consequences of injecting new, powerful functionality into over 50% of the nodes on the Bitcoin network. He suggests considering the recovery path of unanticipated problems and warns against opening up a hole that could allow someone to satisfy arbitrary scripts or create one-packet DoS/crash attacks. Alan proposes leaning towards a more conservative solution such as sandboxing the sub-scripting engine.In response to Gavin's request for an alternative to OP_EVAL, Pieter offers his proposal for OP_CHECKEDEVAL. He explains its specifications, advantages, and disadvantages. The proposal guarantees backward compatibility and static code analysis but disallows dynamic interaction with serialized scripts.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. There is also 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.
Updated on: 2023-08-01T02:48:45.314516+00:00