This represents the third installment in a series thoroughly examining specific covenant proposals that have achieved a level of development warranting an extensive analysis.
TXHASH and CHECKTXHASHVERIFY (TXHASH), introduced by Steven Roose and Brandon Black with a BIP number yet to be assigned, is a “template based” covenant that can be conceptually viewed as an extension or more sophisticated variant of CHECKTEMPLATEVERIFY (CTV).
Before delving into the details of how TXHASH functions, let’s revisit the aspects of data present in a Bitcoin transaction.
At a broad level, you have the outputs, the inputs, and the witness (or script sig for non-Segwit transactions in the input).
Overall transaction fields:
- Version
- Marker, indicating Segwit with a flag value
- Flag, indicating Segwit with a flag value
- Input count
- Output count
- nLocktime, utilized for timelocks
Every input contains:
- TXID of the preceding transaction
- VOUT (index) of the output from that transaction being utilized
- ScriptSig size
- ScriptSig (if it’s a non-segwit transaction)
- Sequence number (used for RBF flagging and relative timelocks).
Every output consists of:
- Value in satoshis assigned to the output
- ScriptPubKeySize, the size of the locking script
- ScriptPubkey, the actual locking script
We can disregard the witness field when analyzing TXHASH or CHECKTXHASHVERIFY since neither opcode restricts the witness field to maintain specific attributes.
How TXHASH Operates
Both TXHASH (tapscript only) and CHECKTXHASHVERIFY (legacy script and tapscript) demonstrate distinct behaviors on the stack due to the differences between legacy script and tapscript. For the purposes of this discussion, these distinctions are not significant, so we will simply overlook them.
If CTV is a covenant opcode that limits a bitcoin output to being spent in a single and precisely defined manner, TXHASH is an enhanced variant of CTV that enables you to selectively determine which components of a transaction are constrained and must be spent in the precisely predefined manner, while allowing other parts of a transaction to be flexible at the time of expenditure.
It offers the best of both scenarios, requiring specific actions when utilizing a covenant-restricted coin, yet permitting a user to utilize the remaining funds available to them or the transaction they are generating in any way they desire.
This is achieved through the ‘TxFieldSelector’.
CTV merely employs a single hash of the predefined transaction to verify at the time of spending. With TXHASH, you require a means to convey which pieces of information that hash commits to, and which it does not. That is the role of the TxFieldSelector.
TxFieldSelector is fundamentally a sequence of bytes (which can vary in length), where each bit indicates what fields in a transaction are committed by the hash that will be verified against. This enables you to select specific fields of the transaction such as nLocktime, version, etc. It allows the selection of particular fields of the inputs and outputs, i.e., to include or exclude the sequence number, the previous output id, or the taproot annex (a data field specific to taproot scripts). The outputs may involve committing to the ScriptPubKey, the value amounts, both, or neither. You can also specify exactly which outputs and inputs these limitations apply to.
There exists some complexity and flexibility in how the TxFieldSelector is constructed, and you can explore all the intricate details here in the suggested BIP if you’re interested in those specifics, but the main takeaway is that it allows you to select precisely which aspects of the transaction are constrained by the covenant when someone seeks to utilize the restricted output, and which aspects are not, to a very detailed extent.
What Is TXHASH Valuable For
Primarily, TXHASH enables you to achieve everything you can with CTV. Hence, all the benefits provided by CTV to optimize the coordination costs of anything currently possible with pre-signed transactions are equally available through TXHASH. However, it vastly enhances that capability. Instead of committing to the entirety of a transaction, you can focus on merely the components that matter to you.
This presents two significant advantages straight away. First, managing in-band fees for layer twos becomes easier to handle. Presently, employing anchor outputs is essential to fee-bump layer two settlement transactions via Child Pays For Parent, where a transaction utilizing an output from an unconfirmed one can contribute to the total fees for both. TXHASH permits you to commit solely to your counterparties’ outputs in a multiparty transaction, freeing yours to be utilized however you choose (with the caveat that additional measures must be taken to ensure safety so a third party cannot consume all of your funds for fees), including slightly reducing it to RBF the transaction.
Secondly, multiparty protocols can now offer granular assurances regarding what off-chain transactions are committing to. Some users can acquire a guarantee on how their coins will be spent, without needing to be concerned about the actions of other user groups. I can be assured that one TxFieldSelector secures my coins are managed correctly, and I don’t need to worry about the destinations of anyone else’s coins.
When combined with CHECKSIGFROMSTACK (CSFS), TXHASH can enable a fully generalized SIGHASH system. The SIGHASH flag is part of a signature that specifies which components of the transaction to validate the signature against. The current options include:
- SIGHASH_ALL – signs all inputs and outputs
- SIGHASH_NONE – signs all inputs and no outputs
- SIGHASH_SINGLE – signs all inputs and the output that shares the same index as this input
None of these SIGHASH flags allow additional inputs to be included in a transaction without rendering them invalid, but each has an ANYONECANPAY version that only signs its own input and the relevant outputs, allowing others to subsequently add new inputs, and new outputs for the ANYONECANPAY variant of SIGHASH_NONE and SIGHASH_SINGLE.
By being capable of “sideloading” new TxFieldSelectors using CSFS, users can simulate a SIGHASH system that allows them to carefully select exactly which individual components of a transaction the signature commits to or does not.
TXHASH further enables enforcing equality between the values of inputs and outputs by utilizing individual TxFieldSelectors that commit solely to a single value field of an input or output you wish to evaluate, and then ensuring their hashes are identical on the stack.
Concluding Remarks
TXHASH represents a potential enhancement of CTV, permitting an extraordinarily detailed degree of examination of the spending transaction which can be highly impactful, particularly when paired with something like CSFS.
Nonetheless, that power is expressive enough to open up a vast design landscape. One that could significantly influence the overall incentives of Bitcoin. Aspects such as ensuring value equality across outputs or inputs are approaching the realm of what is needed for trustless automated exchanges on-chain. This constitutes a serious source of Miner Extractable Value (MEV), which has been a significant incentive and centralization challenge for other blockchains to contend with.
TXHASH should certainly not be overlooked, as it offers incredibly potent tools for protocol developers to leverage, but the potential second-order repercussions of what individuals might construct with it should be carefully considered against the advantages.