This is the third article in a series Deep diving in individual covenant proposals that have reached a maturity point that deserves an in -depth breakdown.
TXHASH AND CHECKTXHASEVENIFY (TXHASH), made by Steven Roose and Brandon Black with a beep number currently unmatched, is a “template -based” covenant that can be conceptually seen as an extension or more advanced version of CheckTemplateverify (CTV).
Before we get into the imperative cruel of how txhash works, let’s update on the data in a Bitcoin transaction.
At a high level, you have output, input and witness (or script to non-Segwit transactions in input).
Global Transaction Fields:
- Version
- Marker that indicates Segwit with a flag value
- Flag that indicates Segwit with a flag value
- Entrance count
- Output counting
- NlockTime, used for time locks
Each input contains:
- Txid for the previous transaction
- Vout (index) of output from the transaction used
- Scriptive -size
- Scriptige (If a Non-Segwit Transaction)
- Sequence number (used for RBF marking and relative timelocks).
Each output contains:
- Amount of Satoshis assigned output
- Scriptpubkeysize, the size of the lock script
- Scriptpubkey, the actual locking cut
We can ignore the witness field when considering Txhash or Checktxhasonify as none of the OPCODE restricts the witness field to preserve certain qualities.
How txhash works
Both TXHASH (TapScript only) and Checktxhasonify (Legacy Script and TapScript) have different performances on the stack due to the differences between older script and tap script. For the purpose of this article, these differences are not material, so we will simply ignore them.
If CTV is a pact-code that limits a Bitcoin output to being used only in a unique and accurately defined way, txhash is a supercharged version of CTV that allows you to choose and choose exactly what pieces of a transaction are limited and need to be used in the exact predefined way and what pieces of a transaction can be what anyone wants to spend time using time.
It gives you the best of both worlds, which requires something to be done when you use a covenant limited coin, but then allows a user to do what they want, with the rest of the means available to them or the transaction they create.
This is achieved using ‘TXFIELDSELECTOR’.
CTV simply uses a single hash of the predefined transaction to verify to spend time. With TXHASH, you need a way to communicate which pieces of information that hash commits to and what pieces of information it is not. It’s TXFIELDSELECTOR’S JOB.
TXFIELDSELECTOR is essentially a number of bytes (which may be varying in length), with each bit communicating which fields in a transaction obliged to by the hash that will be verified against. This allows you to choose specific fields in the transaction, nlockTime, version, etc. It allows you to choose specific fields in input and output, ie. Includes or not the sequence number or the previous output -id or taproot apparatus (a DataAfield specifically for Taproot scripts). Outputs, whether they have to commit to scriptpubkey, the amount values, boats or neither. You can also decide exactly which output and input for which these limitations apply.
There is some complexity and flexibility in how TxfieldSelector is composed and you can read all the finer details here in the proposed beep if you are interested in them, but the most important point to take away is it allows you to choose accurate What parts of the transaction are limited by the pact when someone goes to use the hanging output and which parts are not to a very granular degree.
What is txhash useful for
First, Txhash allows you to do everything you can with CTV. So all the value provided by CTV to optimize coordination costs for everything that is currently possible with foreskin transactions is also provided by TXHASH. But it super plates that capacity massively. Instead of having to commit to the whole of a transaction, you can commit to just the parts you love.
This has two great advantages in theory just outside the bat. First and foremost in tape fees for LAG Two’s becomes easier to handle. Currently, the use of anchor output is required to gebre-bump layers two settlement transactions with a child break for parent, where a transaction that uses an output from an unconfirmed can add the net fees to both. TXHASH allows you to only commit to your counterparties output in a multiparty transaction and leave your free to do what you want with (warning here that other things need to be done to do this safe so that a third party cannot burn all your funds for fees), including decrement a bit to the RBF transaction.
Secondly, the door is now open to multiparty protocols to allow granular guarantees of what off-chain transactions commit to. Some users may now receive a guarantee of how their coins will be used, but do not have to worry about what another group of users are doing with theirs. I can be sure that a TXFIELDSELECTOR guarantees that my coins are handled properly and I don’t have to worry about where other people’s coins are going.
In combination with Checksigfromstack (CSFS), Txhash can facilitate a completely generalized sighash system. The Sighash flag is part of a signature that communicates which parts of the transaction should be checked towards the against. They are currently:
- Sighash_all – sign all input and output
- Sighash_none – sign all input and no output
- Sighash_single – sign all input and output with the same index as this input
None of these Sighash flags allow the addition of new inputs to a transaction without invalid them, but each has an Anyonecanpay version that only signs its own inputs and the appropriate outputs that allow someone else to add new inputs, and new output to the Anyonecanpay version of Sighash_none and Sighash_single.
By being able to “sideload” new TXFIELDSELECTORS using CSFs, users can mimic a sighash system that allows them to choose and choose exactly which individual pieces of a transaction signature commits to or not.
TXHASH also allows to enforce equality between the value of input and output using individual TXFIELDSELECTORS, which only commits to a single valuation of an input or output you want to inspect, and then make sure their hash is the same on the stack.
Closing thoughts
TXHASH is a potential supercharging of CTV, enabling an incredible granular degree of introspection of the expense transaction, which can be incredibly powerful, especially in combination with something like CSFs.
However, this power is expressive enough for it to open the door to an incredibly large design room. One that could potentially have a significant effect on the overall incentives for Bitcoin. Things like securing amount equality across output or input is to get very close to the territory of what is necessary for confidence -free automated exchange on chain. It is a serious source of mines -extractable value (MEV), which has been a very serious incentive and centralization problem for other blockchains to deal with.
Txhash should definitely not be rejected as it provides incredibly powerful primitives for protocol developers to take advantage of, but the potential other order consequences of what people want to build with it must be weighed against the positive things.