Add BIP for OP_TXHASH and OP_CHECKTXHASHVERIFY

bip-txhash.mediawiki

@@ -0,0 +1,230 @@
+<pre>
+  BIP: tbd
+  Layer: Consensus (soft fork)
+  Title: OP_TXHASH and OP_CHECKTXHASHVERIFY
+  Author: Steven Roose <[email protected]>
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-tbd
+  Status: Draft
+  Type: Standards Track
+  Created: 2023-09-03
+  License: BSD-3-Clause
+</pre>
+
+==Abstract==
+
+This BIP proposes two new opcodes, OP_CHECKTXHASHVERIFY, to be activated
+as a change to the semantics of OP_NOP4 in legacy script, segwit and tapscript;
+and OP_TXHASH, to be activated as a change to the semantics of OP_SUCCESS189
+in tapscript only.
+
+These opcodes provide a generalized method for introspecting certain details of
+the spending transaction, which enables non-interactive enforcement of certain
+properties of the transaction spending a certain UTXO.
+
+The constructions specified in this BIP also open up the way for other
+potential updates; see Motivation section for more details.
+
+
+==Summary==
+
+OP_CHECKTXHASHVERIFY uses opcode OP_NOP4 (0xb3) as a soft fork upgrade.
+
+OP_CHECKTXHASHVERIFY does the following:
+
+* There is at least one element on the stack, fail otherwise.
+* The element on the stack is at least 32 bytes long, fail otherwise.
+* The first 32 bytes are interpreted as the TxHash and the remaining suffix
+  bytes specify the TxFieldSelector.
+* If the TxFieldSelector is invalid, fail.
+* The actual TxHash of the transaction at the current input index, calculated
+  using the given TxFieldSelector must be equal to the first 32 bytes of the
+  element on the stack, fail otherwise.
+
+
+OP_TXHASH uses tapscript opcode OP_SUCCESS189 (0xbd) as a soft fork upgrade.
+
+OP_TXHASH does the following:
+
+* There is at least one element on the stack, fail otherwise.
+* The element is interpreted as the TxFieldSelector and is popped off the stack.
+* If the TxFieldSelector is invalid, fail.
+* The 32-byte TxHash of the transaction at the current input index,
+  calculated using the given TxFieldSelector is pushed onto the stack.
+
+
+The TxFieldSelector has the following semantics. We will give a brief conceptual
+summary, followed by a reference implementation of the CalculateTxHash function.
+
+* There are two special cases for the TxFieldSelector:
+  - the empty value, zero bytes long: it is set equal to 0xff|0xf6|0xbf|0xbf,
+    the de-facto default value which means everything except the prevouts and
+    the prevout scriptPubkeys.
+  - the 0x00 byte: it is set equal to 0xff|0xff|0xbf|0xbf, which means "ALL"
+    and is primarily useful to emulate SIGHASH_ALL when OP_TXHASH is used in
+    combination with OP_CHECKSIGFROMSTACK.
+
+* The first byte of the TxFieldSelector has its 8 bits assigned as follows,
+  from lowest to highest:
+  1. version
+  2. locktime
+  3. current input index
+  4. current input control block (or empty)
+  5. current script last OP_CODESEPARATOR position (or 0xffffffff)
+  6. inputs
+  7. outputs
+
+* The last (highest) bit of the first byte, we will call the "control bit", and
+  it can be used to control the behavior of the opcode. For OP_TXHASH and
+  OP_CHECKTXHASHVERIFY, the control bit is used to determine whether the
+  TxFieldSelector itself has to be included in the resulting hash. (For
+  potential other uses of the TxFieldSelector (like a hypothetical OP_TX), this
+  bit can be repurposed.)
+
+* If either "inputs" or "outputs" is set to 1, expect another byte with its 8
+  bits assigning the following variables, from lowest to highest:
+  * Specifying which fields of the inputs will be selected:
+    1. prevouts
+    2. sequences
+    3. scriptSigs
+    4. prevout scriptPubkeys
+    5. prevout values
+    6. taproot annexes
+  * Specifying which fields of the outputs will be selected:
+    7. scriptPubkeys
+    8. values
+
+For both inputs and then outputs, do the following:
+
+* If the "in/outputs" field is set to 1, another additional byte is expected:
+  * The highest bit indicates whether the "number of in-/outputs" should be
+    committed to.
+  * For the remaining bits, there are three exceptional values:
+    - 0x00 means "no in/outputs" (hence only the number of them as 0x80).
+    - 0x40 means "select only the in/output of the current input index"
+      (it is invalid when current index exceeds number of outputs).
+    - 0x3f means "select all in/outputs".
+  * The second highest bit is the "specification mode":
+    - Set to 0 it means "leading mode".
+    - Set to 1 it means "individual mode".
+  * The third highest bit is used to indicate the "index size", i.e. the number
+    of bytes will be used to represent in/output indices.
+  * In "leading mode",
+    - With "index size" set to 0, the remaining lowest 5 bits of the first byte
+      will be interpreted as the number of leading in/outputs to select.
+    - With "index size" set to 1, the remaining lowest 5 bits of the first byte
+      together with the 8 bits of the next byte will be interpreted as the
+      number of leading in/outputs to select.
+  * In "individual mode", the remaining lowest 5 bits of the first byte will be
+    interpreted as `n`, the number of individual in/outputs to select.
+    - With "index size" set to 0, interpret the following `n` individual bytes
+      as the indices of an individual in/outputs to select.
+    - With "index size" set to 1, interpret the next `n` pairs of two bytes as
+      the indices of individual in/outputs to select.
+
+Effectively, this allows a user to select
+- all in/outputs
+- the current input index
+- the leading in/outputs up to 8192
+- up to 32 individually selected in/outputs
+
+The TxFieldSelector is invalid when
+- a byte is expected but missing
+- additional unexpected bytes are present
+- index size is set to 1 while not being necessary
+- a leading number of individual index is selected out of bounds of the in/outputs
+- individual indices are duplicated or not in increasing order
+
+These limitations are to avoid potential TxFieldSelector malleability. It is
+however allowed to use leading mode where it could be "all". This
+is important to allow for optional addition of extra inputs or outputs.
+//TODO(stevenroose) should we disallow individual that could be leading?
+
+
+===Resource limits===
+
+* For legacy scripts and segwit, we don't add any extra resource limitations,
+  with the argumentation that OP_CHECKTXHASHVERIFY already requires the user to
+  provide at least 32 bytes of extra transaction size, either in the input
+  scriptSig, or the witness. Additional more complex hashes require additional
+  witness bytes. Given that OP_CAT is not available in this context, if a
+  malicious user tries to increase the number of TransactionHashes being
+  calculated by using opcodes like OP_DUP, the TxFieldSelector for all these
+  calculations is identical, so the calculation can be cached within the same
+  transaction.
+
+* For tapscript, primarily motivated by the cheaper opcode OP_TXHASH (it
+  doesn't require an additional 32 witness bytes be provided) and the potential
+  future addition of byte manipulation opcodes like OP_CAT, an additional cost
+  is specified per TransactionHash execution.
+  Using the same validation budget ("sigops budget") introduced in BIP-0342,
+  each TransactionHash decreases the validation budget by 10. 
+  If this brings the budget below zero, the script fails immediately.
+
+  The following considerations should be made:
+
+  * All fields that can be of arbitrary size are cachable as TransactionHash
+    always hashes their hashed values.
+  * In "individual mode", a user can at most commit 32 inputs or outputs, which we
+    don't consider excessive for potential repeated use.
+  * In "prefix mode", a caching strategy can be used where the SHA256 context is
+    stored every N in/outputs so that multiple executions of the TransactionHash
+    function can use the caches and only have to hash an additional N-1 items at
+    most.
+
+
+==Motivation==
+
+This BIP specifies a basic transaction introspection primitive that is useful
+to either reduce interactivity in multi-user protocols or to enforce some basic
+constraints on transactions.
+
+Additionally, the constructions specified in this BIP can lay the groundwork for
+some potential future upgrades:
+* The TxFieldSelector construction would work well with a hypothetical opcode
+  OP_TX that allows for directly introspecting the transaction by putting the
+  fields selected on the stack instead of hashing them together.
+* The TransactionHash obtained by OP_TXHASH can be combined with a hypothetical
+  opcode OP_CHECKSIGFROMSTACK to effectively create an incredibly flexible
+  signature hash, which would enable constructions like SIGHASH_ANYPREVOUT.
+
+===Comparing with some alternative proposals===
+
+* This proposal strictly generalizes BIP-119's OP_CHECKTEMPLATEVERIFY, as the
+  default mode of our TxFieldSelector is effectively the same (though not 
+  byte-for-byte identical) as what OP_CTV acomplishes, without costing any 
+  additional bytes. Additionally, using OP_CHECKTXHASHVERIFY allows for more
+  flexibility which can help in the case for
+  * enabling adding fees to a transaction without breaking a multi-tx protocol;
+  * multi-user protocols where users are only concerned about their own inputs
+    and outputs.
+
+* Constructions like OP_IN_OUT_VALUE used with OP_EQUALVERIFY can be emulated by
+  two OP_TXHASH instances by using the TxFieldSelector to select a single input
+  value first and a single output value second and enforcing equality on the
+  hashes. Neither of these alternatives can be used to enforce small value
+  differencials without the use of 64-bit arithmetic.
+
+* Like mentioned above, SIGHASH_ANYPREVOUT can be emulated using OP_TXHASH when
+  combined with OP_CHECKSIGFROMSTACK:
+  `<txfs> OP_TXHASH <pubkey> OP_CHECKSIGFROMSTACK` effectively emulates
+  SIGHASH_ANYPREVOUT.
+
+
+
+
+==Detailed Specification==
+
+A reference implementation in Rust is provided attached as part of this BIP
+together with a JSON file of test vectors generated using the reference
+implementation.
+
+
+==Acknowledgement==
+
+Credit for this proposal mostly goes to Jeremy Rubin for his work on BIP-119's
+OP_CHECKTEMPLATEVERIFY and to Russell O'Connor for the original idea of
+generalizing CTV into OP_TXHASH.
+
+Additional thanks to Andrew Poelstra, Greg Sanders, Rearden Code, Rusty Russell
+and others for their feedback on the specification.
+

bip-txhash/ref-impl/Cargo.toml

@@ -0,0 +1,14 @@
+[package]
+name = "txhash-ref"
+version = "0.1.0"
+edition = "2021"
+
+# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
+
+[dependencies]
+bitcoin = { version = "0.31.0", features = [ "serde" ] }
+serde_json = "1.0.108"
+
+[patch.crates-io]
+bitcoin = { path = "/home/steven/code/rust/bitcoin/bitcoin" }
+bitcoin-io = { path = "/home/steven/code/rust/bitcoin/io" }