Published on: 2019-10-03T23:22:47+00:00
Jeremy Rubin has proposed an update to the Bitcoin Improvement Proposal (BIP) that replaces Taproot with an OP_NOP upgrade. The BIP introduces OP_NOP4, which enables the OP_SECURETHEBAG feature for segwit and bare script, but not P2SH. Dmitry Petukhov suggests using a control-sig to restrict spending conditions and proposes additional flags for sighash. Anthony Towns suggests simulating OP_SECURETHEBAG with an ANYPREVOUT sighash. The bitcoin-dev mailing list discusses eliminating malleability in UTXOs using the ANYPREVOUTANYSCRIPT signature and the need for improvements in tapscript implementation. There are suggestions to improve script parsing, versioning techniques, and compatibility with templated scripts. The author of the context argues against the use of OP_IF and proposes upgrading the script parser with a new interpreter for Tapscript. They also discuss the introduction of Turing-completeness in Bitcoin SCRIPT and the potential for creating covenants using OP_TWEEKPUBKEY.The debate revolves around the complexity of changes to Bitcoin Core and the need to ensure script semantics are easily understandable. There is a proposal to add the OP_SECURETHEBAG opcode to modify public keys in Bitcoin script, but concerns are raised about its impact on script composability. The commitment of the script itself is questioned, and suggestions are made to include it in the opcode or use an OP_TWEEKPUBKEY operation. Additionally, the possibility of enabling recursive covenants and making Bitcoin SCRIPT Turing-complete is discussed.An alternative approach using an ANYPREVOUT sighash to simulate OP_SECURETHEBAG is suggested. This involves calculating a signature for a pubkey and using "CHECKSIG" in the script. Issues regarding commitment to inputs and the size of the script are raised. Another proposal for an opcode called OP_CHECKTXDIGESTVERIFY is discussed, which could enable covenants and Turing-complete smart contracts. The debate centers around the need to precommit the digest as part of the opcode.In conclusion, the bitcoin-dev mailing list discusses various proposals and improvements related to script semantics, malleability in UTXOs, and the introduction of new opcodes. The focus is on enhancing tapscript implementation, enabling covenants, and exploring the potential for Turing-completeness in Bitcoin SCRIPT.On May 31, 2019, Jeremy Rubin announced the retraction of the proposed opcode 'OP_CHECKOUTPUTSHASHVERIFY' in favor of a new opcode called 'OP_SECURETHEBAG'. The new opcode aims to fix malleability issues and lift the single output restriction to a known number of inputs restriction. It allows for more flexibility while still keeping the ease of use. The proposed change involves pulling a 33-byte value from the stack, consisting of a sha256 hash and a sighash-byte, and adding a new sighash value corresponding to the set of information to include in the hash.The author acknowledges receiving a response from someone named Russell and admits to having missed some points of concern related to malleability. They provide a code snippet showing how TXID is computed and mention that it can be modified in certain cases, leading to potential security issues. However, the author mentions that they have revisited their work and believe they have addressed all the concerns related to malleability. They express hope that their changes will fully address the issue.The new opcode, OP_SECURETHEBAG, commits to both version and locktime, which was not possible with the previous opcode. It also lifts the restriction on the number of inputs needed, allowing for more flexibility. However, this feature requires special design to be safe, and a backout transaction is required before the funding transaction output is committed onchain. For Poon-Dryja channels, the initial commitment transaction is used as the backout transaction. The continued operation of the protocol requires the initial commitment to be revoked at the next update. A plausible backout for the receiver is needed for this purpose. To do so, the funding transaction address is made a Taproot with an internal pubkey 2-of-2 of the receiver and its channel counterparty.The proposed OP_CHECKOUTPUTSHASHVERIFY has been retracted in favor of the new proposal, OP_SECURETHEBAG. The new proposal fixes malleability issues and lifts the single output restriction to a known number of inputs restriction. The previous proposal had some issues with malleability of version and locktime. OP_SECURETHEBAG commits to both of these values and also lifts the restriction that OP_CHECKOUTPUTSVERIFY had to be spent as only a single input, and instead just commits to the number of inputs.
Updated on: 2023-08-02T00:56:33.739774+00:00