Published on: 2019-06-13T08:14:02+00:00
Another aspect discussed in the proposal is the implementation of oracle-less difficulty contracts without the need for CISC type OP_WORKVERIFY. An example contract is provided, which involves a European digital call option on target difficulty after maturity with a 10-block notice period. The contract can be soft forked by redefining OP_NOP as a prefix (OP_EXTENSION). This demonstrates the flexibility of Bitcoin Script and the potential for creating complex smart contracts.The proposal also suggests adding OP_CAT and OP_CHECKSIGFROMSTACKVERIFY to enable flexible programmability in Bitcoin Script. It argues that some parts of Script have been unsuccessful and not useful in practice, and that a subset of concatenation, arithmetic, CHECKDATASIG, transaction reflection, and/or covenants could create particularly useful programs. The proposal includes a debate on simulating an ANYPREVOUT signature with a data signature and the use of the "CHECK_SIG_MSG_VERIFY" opcode for simplicity and generic programming.Anthony Towns suggests that the infrequent use of certain Script features may be due to a lack of tools rather than a lack of demand. He advocates for implementing a pure functional language that can be compiled down to SCRIPT and leveraged with OP_CHECKSIGFROMSTACK. This would require a proof-of-existence compiler targeting Liquid/Elements SCRIPT. Towns also mentions his Smart Contracts Unchained technique as a way to implement Simplicity on top of Bitcoin, using a user-selected federation to enforce Simplicity execution.The effectiveness of Bitcoin Script has been questioned due to the disabling of certain opcodes and consensus bugs. Russell O'Connor proposes implementing OP_CAT and OP_CHECKSIGFROMSTACKVERIFY as a solution. The proposal suggests that CAT's usefulness is acknowledged, but there is uncertainty about CHECKSIG, which takes the message from the stack. A concrete example of transaction introspection using simulated SIGHASH_ANYPREVOUT is provided.The discussion also revolves around the OP_COSHV opcode and its potential replacement with transaction reflection primitives like OP_NUMINPUTS and OP_PUSHOUTPUTSHASH. The proposal for OP_CHECK_TXID_TEMPLATE_DATA is debated, allowing a variable number of inputs and fixing potential bugs related to TXID malleability. The idea of implementing an alternative CISC-style taproot leaf type is suggested. The benefits and drawbacks of OP_CHECKSIGFROMSTACKVERIFY are discussed, with concerns raised about its potential recursive covenant and negative interaction with future opcodes.In summary, the proposal suggests introducing new opcodes, OP_CAT and OP_CHECKSIGFROMSTACKVERIFY, to enhance the functionality and flexibility of Bitcoin Script. These opcodes can enable various applications and improve the programmability of Bitcoin. However, there are ongoing debates and discussions regarding the implementation and potential limitations of these opcodes, as well as the overall effectiveness of Bitcoin Script in real-world use cases.
Updated on: 2023-08-02T00:53:10.913427+00:00