Author: Alan Reiner 2011-12-29 21:31:11
Published on: 2011-12-29T21:31:11+00:00
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 notes that he has not been a part of the brainstorming discussions and therefore is offering an unbiased perspective. Alan expresses concern that pride may be prioritized over security and reminds readers that the network is functioning fine without OP_EVAL. 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.
Updated on: 2023-06-05T01:28:05.794403+00:00