Author: Brandon Black 2023-08-22 17:04:38+00:00
Combined Summary of all posts in threadPublished on: 2023-08-22T17:04:38+00:00
In this email, the sender is seeking feedback on a proposal that combines the functionality of bip118 and bip119, while addressing objections and providing clear upgrade paths. The sender has created this proposal to help clarify the similarities and differences between the two proposals and promote discussion towards consensus.The proposal suggests 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 both bip118 and bip119 and provide a more general solution. The objections to bip119 include it not being general enough, inefficient when validating the hash, and using extension semantics instead of available OP_SUCCESSx. The 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.This 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 how the efficiency of this proposal compares to bip118 and bip119 in terms of witness bytes. It provides examples and calculations for different scenarios and concludes that this proposal may be slightly more costly than bare CTV but offers compatibility with ln-symmetry, PTLCs, and OP_VAULT.The email ends 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.Overall, the sender is seeking feedback on this proposal and aims to contribute to the discussion on bitcoin script development, specifically regarding bip118 and bip119.
Updated on: 2023-08-23T01:51:10.856046+00:00