Bitcoin Covenants: TXHASH And CHECKTXHASHVERIFY(BIP 346)

It is the third of four articles in this series. series A detailed analysis of individual covenants that are mature enough to warrant a thorough breakdown.

TXHASH and CHECKTXHASHVERIFY The (TXHASH) proposed by Steven Roose & Brandon Black, with a currently unknown BIP number is a “template based” The covenant can be seen conceptually as a more advanced version or an extension of CHECKTEMPLATEVERIFY. 

Let’s review the data that makes up a Bitcoin transaction before we get into TXHASH. 

The outputs are the scripts and inputs. 

Transacting globally:

• The Version of the Website that You Want is Available
• Marker indicating Segwit using a flag value
• Segwit flag with value
• Put Count
• Count the output
• Use of Locktime for Timelocks

Each input contains:

• The TXID number of the transaction before this one
• This is an index of the amount spent.
• ScriptSig size
• ScriptSig is required (if the transaction does not use Segwit)
• The sequence number is used for RBF marking and relative timing.

Each output contains:

• Quantity of satoshis allocated to output
• ScriptPubKeySize – the size of a locking script
• ScriptPubkey is the locking script

When using TXHASH, CHECKTXHASHVERIFY or CHECKTXHASHVERIFY we can disregard the witness fields as they do not require the witness to maintain certain properties. 

TXHASH – How It Works

Due to the difference between tapscript and legacy script, TXHASH and CHECKTXHASHVERIFY have slightly different behavior on the stack. These differences do not matter for the purpose of this article.

TXHASH, a version supercharged of CTV, allows you to choose which parts of the transaction must adhere to a predefined pattern and what portions can be used however they please. 

This allows users to have the best of both the worlds. They can spend a coin that is restricted by covenant, and then do what they like with the remaining funds or transaction. 

This is accomplished using the ‘TxFieldSelector’. 

CTV only uses one hash for the predefined transaction to check at spend time. You need to be able to tell TXHASH what information the hash commits to and which information it does not. TxFieldSelector is responsible for this. 

TxFieldSelector (which can have a variable length) is basically a sequence of bytes. Each bit communicates which fields within a transaction will be committed by the hash to be verified. You can select the specific fields in a transaction such as nLocktime or version. You can select inputs or outputs fields. You can choose whether to include the sequence numbers, the outputs ids, the taproot data (a field specific for scripts with taproot), or any other fields. The amount values and whether or not to commit the script to ScriptPubkey. You can specify which inputs and outputs are affected by these restrictions. 

You can find out all about the TxFieldSelector’s flexibility and complexity. here If you are interested, you can find out more about the BIP proposal. But the main point is that it gives you the freedom to choose. Exactly, you can contact us by clicking here. It is possible to specify to an extremely fine degree which aspects of the deal are subject to the covenant, when it comes to spending the encumbered production. 

TXHASH: What is it useful for?

TXHASH lets you do all that is possible with CTV. TXHASH provides all the benefits of CTV in optimizing the costs associated with transactions that are currently pre-signed. It supercharges this capability. The entire transaction does not have to be committed to. Only the portions that you are interested in can. 

In theory, there are two huge benefits. The management of band fees for layer twos is made easier. The use of anchor outputs Fee-bumping two settlements transactions is necessary with Child Pays for Parent. A transaction that spends an output of an unconfirmed transaction can increase the fees both parties pay. TXHASH enables you to agree to the outputs of only one party in a multiple-party transaction and to leave the other free. 

Second, multiparty protocols can now provide more granular information about the off-chain transaction. Now, some users will receive guarantees about the use of their coins and not be concerned about other users’ actions. TxFieldSelector ensures that all my coins will be handled correctly, but I do not have to concern myself with where other people’s coins end up. 

TXHASH in conjunction with CHECKSIGFROMSTACK can provide a SIGHASH solution that is fully generalized. SIGHASH is an element of signatures that indicates which parts of a transaction should be checked against the signature. They currently are: 

• 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

These SIGHASH flags do not allow the addition of new inputs without invalidating the transaction. However, each of them has an ANYONECANPAY variant that signs only its input and output, which allows anyone to add additional inputs and outputs.

By being able to “sideload” With the new TxFieldSelectors, users are able to emulate a SIGHASH-like system where they can choose and select which parts of a transaction their signature is committed to. 

TXHASH allows you to enforce equality of value between inputs and out-puts. You can do this by using TxFieldSelectors which commit to only a single field value for an input or output that you want to inspect. Then, ensure their hashes on the stack are identical. 

Closed Thoughts

TXHASH can supercharge CTV by allowing a granular level of insight into the transaction. This is powerful when combined with something such as CSFS. 

But this power is powerful enough to open up a vast design space. It could also have an important impact on Bitcoin’s incentives. The need for trustless, automated on-chain exchange is becoming more and more apparent. Things such as ensuring equal amounts across inputs and outputs are getting closer to being a reality. This is an important source of the Miner Extracted Value (MEV), a centralization and incentive problem that other blockchains have had to address. 

TXHASH shouldn’t be discounted, because it is a powerful tool for protocol designers to use. But, you should weigh its potential negative implications against what it will allow people to build.