From afc605f8e2b2cb65766101a0fb06abc1e0382ab4 Mon Sep 17 00:00:00 2001 From: Jeremy Rubin Date: Fri, 15 Oct 2021 12:19:13 -0700 Subject: [BIP-119] Describe Synergies with future soft fork proposals --- bip-0119.mediawiki | 69 ++++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 59 insertions(+), 10 deletions(-) (limited to 'bip-0119.mediawiki') diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index 7ac7a1d..5c02f3f 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -397,9 +397,10 @@ a hash midstate in the script. =====The Ordering of Fields===== -Strictly speaking, the ordering of fields is insignificant. However, with a carefully selected -order, the efficiency of future scripts (e.g., those using a OP_CAT or OP_SHA256STREAM) may be -improved. +Strictly speaking, the ordering of fields is insignificant. However, with a +carefully selected order, the efficiency of future scripts (e.g., those using a +OP_CAT or OP_SHA256STREAM) may be improved (as described in the Future Upgrades +section). In particular, the order is selected in order of least likely to change to most. @@ -430,12 +431,6 @@ does not make sense for input index to be the last field. However, given the des able to express a "don't care" index easily (e.g., for decentralized kickstarter-type transactions), this value is placed last. -As an example, the following code checks an input index argument and concatenates it to the template and -checks the template matches the transaction. - - OP_SIZE 4 OP_EQUALVERIF - - OP_SWAP OP_CAT OP_SHA256 OP_CHECKTEMPLATEVERIFY ===Design Tradeoffs and Risks=== Covenants have historically been controversial given their potential for fungibility risks -- coins @@ -535,7 +530,7 @@ signature operations. This can be significant when constructing large payment trees or programmatic compilations. CHECKTEMPLATEVERIFY also has a feature-wise benefit in that it provides a robust pathway for future template upgrades. -CHECKSIGFROMSTACK along with OP_CAT may also be used to emulate +OP_CHECKSIGFROMSTACKVERIFY along with OP_CAT may also be used to emulate CHECKTEMPLATEVERIFY. However such constructions are more complicated to use than CHECKTEMPLATEVERIFY, and encumbers additional verification overhead absent from CHECKTEMPLATEVERIFY. These types of covenants also bear similar potential @@ -546,6 +541,60 @@ Given the simplicity of this approach to implement and analyze, and the benefits applications, CHECKTEMPLATEVERIFY's template based approach is proposed in lieu of more complete covenants system. +====Future Upgrades==== + +This section describes updates to OP_CHECKTEMPLATEVERIFY that are possible in +the future as well as synergies with other possible upgrades. + +=====CHECKTEMPLATEVERIFY Versions===== +OP_CHECKTEMPLATEVERIFY currently only verifies properties of 32 byte arguments. +In the future, meaning could be ascribed to other length arguments. For +example, a 33-byte argument could just the last byte as a control program. In +that case, DefaultCheckTemplateVerifyHash could be computed when the flag byte +is set to CTVHASH_ALL. Other programs could be added similar to SIGHASH_TYPEs. +For example, CTVHASH_GROUP could read data from the Taproot Annex for +compatibility with SIGHASH_GROUP type proposals and allow dynamic malleability +of which indexes get hashed for bundling. + +=====Eltoo with OP_CHECKSIGFROMSTACKVERIFY===== + +Were both OP_CHECKTEMPLATEVERIFY and OP_CHECKSIGFROMSTACKVERIFY to be added to +Bitcoin, it would be possible to implement a variant of Eltoo's floating +transactions using the following script: + + witness(S+n): + program(S): OP_CHECKTEMPLATEVERIFY OP_CHECKSIGFROMSTACKVERIFY OP_CHECKLOCKTIMEVERIFY + +Compared to SIGHASH_ANYPREVOUTANYSCRIPT, because OP_CHECKTEMPLATEVERIFY does not +allow something similar to SIGHASH_ANYONECANPAY or SIGHASH_SINGLE, protocol +implementers might elect to sign multiple versions of transactions with CPFP +Anchor Outputs or Inputs for paying fees or an alternative such as transaction +sponsors might be considered. + +=====OP_AMOUNTVERIFY===== + +An opcode which verifies the exact amount that is being spent in the +transaction, the amount paid as fees, or made available in a given output could +be used to make safer OP_CHECKTEMPLATEVERIFY addressses. For instance, if the +OP_CHECKTEMPLATEVERIFY program P expects exactly S satoshis, sending S-1 +satoshis would result in a frozen UTXO and sending S+n satoshis would result in +n satoshis being paid to fee. A range check could restrict the program to only +apply for expected values and default to a keypath otherwise, e.g.: + + IF OP_AMOUNTVERIFY OP_GREATER CHECKSIG ELSE OP_CHECKTEMPLATEVERIFY + +=====OP_CAT/OP_SHA256STREAM===== + +OP_CHECKTEMPLATEVERIFY is (as described in the Ordering of Fields section) +efficient for building covenants dynamically should Bitcoin get enhanced string +manipulation opcodes. + +As an example, the following code checks an input index argument and +concatenates it to the template and checks the template matches the transaction. + + OP_SIZE 4 OP_EQUALVERIF + + OP_SWAP OP_CAT OP_SHA256 OP_CHECKTEMPLATEVERIFY == Backwards Compatibility == OP_CHECKTEMPLATEVERIFY replaces a OP_NOP4 with stricter verification semantics. Therefore, scripts -- cgit v1.2.3