This is the third article in a series The deep diving in individual pact proposals that have reached a maturity point that deserves a depth breakdown.
Txhash and Checktxhashverify (Txhash), presented by Steven Roose and Brandon Black with a currently assigned BIP number, is a “template -based” pact that can be seen conceptually as an extension or a more advanced version of Checktemplinge (CTV).
Before entering the sandy of how Txhash works, we will update the data in a Bitcoin transaction.
At a high level, you have the outputs, tickets and the witness (or SCRPT SIG for non -secwit transactions at the entrance).
Global transaction fields:
- Version
- Marker, indicated by Segwit with a flag value
- Flag, indicating secwit with a flag value
- Input count
- Departure count
- nlocktime, used for Timelocks
Each entry contains:
- Txid of the previous transaction
- Vout (index) of the output of that spent transaction
- Scriptsig size
- Scriptsig (if a non -secwit transaction)
- Sequence number (used for RBF brands and relative time selections).
Each output contains:
- Number of satoshis assigned to the output
- Scriptpubkeysize, the size of the blocking script
- Scriptpubkey, the real block script
We can ignore the witnesses field when considering Txhash or Checktxhashverify, since none of the operation codes restrict the witness field to retain certain properties.
How Txhash works
Both Txhash (Tapscript) and Checktxhashverify (Legacy Script and Tapscript) have different behaviors in the battery due to the differences between the inherited script and the tapscript. For the purposes of this article, these differences are not material, so we will simply ignore them.
If CTV is a pact operation code that limits that a Bitcoin output is only spent in a unique and exactly defined way, Txhash is an supercharged version of CTV that allows you to choose exactly what pieces of a transaction are limited and should be spent exactly predefined and what pieces of a transaction can be what someone wants when spending time.
He gives him the best of both worlds, which requires something to spend a restricted currency of the pact, but then allowing a user to do what he wants with the rest of the funds available for them or the transaction that he elaborates.
This is achieved using ‘txfieldselector’.
CTV simply uses a unique hash of the predefined transaction to verify time. With Txhash, he needs a way to communicate to what information has Hash and what information is not. That is the work of the Txfieldselector.
Txfieldselector is essentially a series of bytes (which can be variables of length), with each bit communicating which fields in a transaction are committed by the hash that will be verified. This allows you to select specific fields of the transaction, NLOCKTIME, version, etc., allow you to select specific fields of inputs and outputs, that is, include or not include the sequence number, or the previous output ID, or the Taproot Annex (a specific data field for Taproot scripts). The outputs, either to commit to the scriptpubkey, the values ​​of the quantity, both or none. You can also decide exactly what exits and tickets these restrictions are applied.
There is some complexity and flexibility in how the txfieldselector joins, and you can read all the finest details. here In the proposed bip if you are interested in those, but the main point of removing it is that it allows you to choose exactly What parts of the transaction are restricted by the pact when someone is going to spend the taxed exit, and what parts are not, to a very granular degree.
What is Txhash useful?
First, Txhash allows you to do everything with CTV. Therefore, Txhash also provides all the value provided by CTV to optimize the coordination costs of anything as possible with transactions prior to firmation. But oversthery that capacity enormously. Instead of having to commit to the totality of a transaction, it can compromise only to the parts that care.
This has two great benefits in theory immediately. First, in the management of the band’s rates for the layer of the layer it becomes easier to handle. Currently, the use of anchoring outputs to make a layer of tariff two liquidation transactions with children’s payments by parents, where a transaction spent an output of an unconfirmed one can add the net rates for both. Txhash allows you to commit to only its counterparty outputs in a multiparty transaction, and leave your free to do what you want (consider here that other things must be done so that this is safe so that a third party cannot burn all its funds at the fees), including the slightly decrease to RBF of the transaction.
Second, the door is now open for multiparty protocols to allow granular guarantees about what transactions are committed outside the chain. Some users can now receive a guarantee on how their coins will be spent, but they don’t have to worry about what another group of users does with their own. I can be sure that a txfieldselector guarantees that my coins are handled correctly, and I don’t have to worry about where another person’s coins are going.
In combination with Checksigfromstack (CSFS), Txhash can facilitate a completely generalized Sighash system. The Sighash flag is part of a firm that communicates with which parts of the transaction verify the firm. They are currently:
- Sighash_all: Sign all entrances and exits
- Sighash_none: Sign all entries and not outings
- Sighash_single: Sign all entries and exit with the same index as this entry
None of these sighash indicators allows you to add new entries to a transaction without invalidating them, but each one has an AnyoneCanpay version that only signs their own inputs and the appropriate outputs, which allows any other person to add new entries and new outputs for the Anyonepay version of Sighash_none and Sighash_single.
To the “Sideload” power new txfieldselectors using CSF, users can emulate a SIGHEH system that allows them to choose exactly what individual pieces of a transaction is committed or not.
Txhash also allows us to enforce equality between the value of the entrances and exits through the use of individual txfieldselectors who commit only to a unique value field of an entry or exit that you want to inspect, and then guarantee that your hashes are the same in the pile.
Closing thoughts
Txhash is a possible supercharging of CTV, which allows an incredibly granular degree to introspection of the spending transaction that can be incredibly powerful, especially in combination with something like CSFS.
However, that power is expressive enough to open the door to an incredibly large design space. One that could have a material effect on Bitcoin’s general incentives. Things how to guarantee the amount of equality in exits or entries is to get close to the territory of what is needed for automated exchange without confidence in the chain. That is a serious source of removable value of miners (MEV), which has been a very serious incentive and centralization problem for other blockchains to be dealing.
Txhash should not be discarded absolutely, since it provides incredibly powerful primitive so that protocols developers take advantage of, but the possible second -order implications of what people will build with it must weigh against positive aspects.
