Published on: 2023-08-22T20:23:09+00:00
In this email exchange, Greg provides additional information related to a previous conversation with Brandon. He suggests replacing the term "OP_2" with "OP_4" and mentions that BIP118 allows for the use of the pubkey "1" as a substitute for the taproot inner pubkey. Greg proposes adding an opcode called "OP_INNER_PUBKEY" to achieve the same effect. He also highlights that BIP118 addresses taproot malleability bugs by allowing non-APO signatures to have a sighash digest that commits to additional data.Greg includes a link to a discussion on GitHub for further exploration of this topic. He acknowledges that these details are not crucial but suggests addressing them if possible.In another email, Brandon provides a quick update to his proposal based on feedback from James O'Beirne. He states that CTV is less expensive than previously thought when used alone. He clarifies that script success requires exactly "OP_TRUE" instead of just a CastToBool()=true value on the stack. This means that his proposal is slightly larger than CTV when both are used in Tapscript.Brandon then presents a proposal that combines the functionality of bip118 and bip119 while addressing objections and providing clear upgrade paths. The aim of this proposal is to clarify the similarities and differences between the two proposals and promote consensus through discussion.The proposal introduces three new Tapscript-only opcodes: OP_TXHASH, OP_CHECKSIGFROMSTACK, and OP_CHECKSIGFROMSTACKVERIFY. These opcodes replace existing opcodes and provide different hashing and signature checking behaviors depending on the arguments popped from the stack.The motivation behind this proposal is to address objections to bip118 and bip119 and provide a more general solution. Objections to bip119 include it not being general enough, inefficiency when validating the hash, and using extension semantics instead of available OP_SUCCESSx. Objections to bip118 include it not being general enough, enabling inefficient and hard-to-use covenants accidentally, and requiring a new Tapscript key version for safety.The proposal aims to provide the behavior of both bip118 and bip119, offer explicit upgrade hooks for further generality, split the hashing from the validation in bip119, enable some sighash-based covenants accidentally enabled by bip118, and use new signature checking opcodes without requiring a new Tapscript key version.The specification of the proposal defines the behavior of OP_TXHASH and OP_CHECKSIGFROMSTACK(VERIFY) in Tapscript validation. OP_TXHASH hashes the transaction based on a minimally encoded numeric argument popped from the stack, while OP_CHECKSIGFROMSTACK(VERIFY) verifies a signature against a message and public key according to bip340.The email also discusses the efficiency of this proposal compared to bip118 and bip119 in terms of witness bytes. Examples and calculations are provided for different scenarios, and it is concluded that this proposal may be slightly more costly than bare CTV but offers compatibility with ln-symmetry, PTLCs, and OP_VAULT.The email concludes with a discussion on the fields that are hashed in different modes of the proposal and mentions some notes related to validation and signature lengths. Brandon seeks feedback on this proposal and aims to contribute to the discussion on bitcoin script development, specifically regarding bip118 and bip119.
Updated on: 2023-08-24T01:52:55.046913+00:00