This is the third article in a series deep diving into individual covenant proposals that have reached a point of maturity meriting an in-depth breakdown.
TXHASH and CHECKTXHASHVERIFY (TXHASH), put forward by Steven Roose and Brandon Black with a BIP number currently unassigned, is a “template based” covenant that can conceptually seen as an extension or more advanced version of CHECKTEMPLATEVERIFY (CTV).
Before getting into the nitty gritty of how TXHASH works, let’s refresh on the pieces of data in a Bitcoin transaction.
At a high level you have the outputs, the inputs, and the witness (or script sig for non-Segwit transactions in the input).
Global transaction fields:
- Version
- Marker, indicating Segwit with a flag value
- Flag, indicating Segwit with a flag value
- Input count
- Output count
- nLocktime, used for timelocks
Each input contains:
- TXID of the previous transaction
- VOUT (index) of the output from that transaction being spent
- ScriptSig size
- ScriptSig (if a non-segwit transaction)
- Sequence number (used for RBF flagging and relative timelocks).
Each output contains:
- Amount of satoshis assigned to the output
- ScriptPubKeySize, the size of the locking script
- ScriptPubkey, the actual locking script
We can ignore the witness field when considering TXHASH or CHECKTXHASHVERIFY as neither opcode constrains the witness field to retain certain properties.
How TXHASH Works
Both TXHASH (tapscript only) and CHECKTXHASHVERIFY (legacy script and tapscript) have different behaviors on the stack because of the differences between legacy script and tapscript. For the purposes of this article, these differences are not material, so we are simply going to ignore them.
If CTV is a covenant opcode that constrains a bitcoin output to only be spent in a singular and exactly defined way, TXHASH is a supercharged version of CTV that lets you pick and choose exactly what pieces of a transaction are constrained and must be spent in the exactly pre-defined way, and which pieces of a transaction can be whatever someone wants at spending time.
It gives you the best of both worlds, requiring something be done when spending a covenant restricted coin, but then allowing a user to do whatever they want with the rest of the funds available to them or the transaction they are crafting.
This is accomplished using the ‘TxFieldSelector’.
CTV simply uses a single hash of the pre-defined transaction in order to verify at spending time. With TXHASH, you need a way to communicate what pieces of information that hash is committing to, and what pieces of information it is not. That is the TxFieldSelector’s job.
TxFieldSelector is essentially a series of bytes (that can be variable in length), with each bit communicating what fields in a transaction are committed to by the hash that will be verified against. This allows you to select specific fields of the transaction, nLocktime, version etc. It lets you select specific fields of the inputs and outputs, i.e. include or not the sequence number, or the previous output id, or the taproot annex (a datafield specific to taproot scripts). The outputs, whether to commit to the ScriptPubkey, the amount values, both, or neither. You can also decide exactly which outputs and inputs these restrictions apply to.
There is some complexity and flexibility in how the TxFieldSelector is put together, and you can read all the finer details here in the proposed BIP if you’re interested in those, but the chief point to take away is it allows you to pick exactly which parts of the transaction are restricted by the covenant when someone goes to spend the encumbered output, and which parts are not, to a very granular degree.
What Is TXHASH Useful For
Firstly, TXHASH allows you to do everything that you can with CTV. So all of the value provided by CTV to optimize the coordination costs of anything currently possible with pre-signed transactions is also provided by TXHASH. But it supercharges that capability massively. Instead of having to commit to the entirety of a transaction, you can commit to just the parts you care about.
This has two big benefits in theory right off the bat. First of all, in band fee management for layer twos becomes easier to deal with. Currently the use of anchor outputs is required to fee-bump layer two settlement transactions with Child Pays For Parent, where a transaction spending an output from an unconfirmed one can add to the net fees for both. TXHASH lets you commit to only your counterparties outputs in a multiparty transaction, and leave yours free to do whatever you want with (caveat here that other things must be done to make this safe so a third party can’t burn all of your funds to fees), including decrementing slightly to RBF the transaction.
Second, the door is now open for multiparty protocols to allow granular guarantees about what off-chain transactions are committing to. Some users can now receive a guarantee about how their coins will be spent, but not have to care about what some other group of users does with theirs. I can be sure that one TxFieldSelector guarantees my coins are handled properly, and I don’t have to care about where anyone else’s coins go.
In combination with CHECKSIGFROMSTACK (CSFS), TXHASH can facilitate a completely generalized SIGHASH system. The SIGHASH flag is a part of a signature that communicates what parts of the transaction to check the signature against. They are currently:
- SIGHASH_ALL – signs all inputs and outputs
- SIGHASH_NONE – signs all inputs and no outputs
- SIGHASH_SINGLE – signs all inputs and the output with the same index as this input
None of these SIGHASH flags allow adding any new inputs to a transaction without invalidating them, but each has an ANYONECANPAY version that only signs its own input and the appropriate outputs, allowing anyone else to then add new inputs, and new outputs for the ANYONECANPAY version of SIGHASH_NONE and SIGHASH_SINGLE.
By being able to “sideload” new TxFieldSelectors using CSFS, users can emulate a SIGHASH system that allows them to pick and choose exactly which individual pieces of a transaction the signature commits to or not.
TXHASH also allows enforcing equality between the value of inputs and outputs by using individual TxFieldSelectors that commit only to a single value field of an input or output you wish to inspect, and then ensuring their hashes are the same on the stack.
Closing Thoughts
TXHASH is a potential supercharging of CTV, enabling an incredibly granular degree of introspection of the spending transaction which can be incredibly powerful, especially in combination with something like CSFS.
However, that power is expressive enough that it opens up the door to an incredibly large design space. One that could potentially have a material effect on the overall incentives of Bitcoin. Things like ensuring amount equality across outputs or inputs is getting very close to the territory of what is needed for trustless automated exchange on-chain. That is a serious source of Miner Extractable Value (MEV), which has been a very serious incentive and centralization problem for other blockchains to deal with.
TXHASH should absolutely not be dismissed, as it provides incredibly powerful primitives for protocol developers to take advantage of, but the potential second order implications of what people will build with it should be weighed against the positives.
