Bitcoin Covenants: BIP 347

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

OP_CATThe covenant that Ethan Heilman, Armin Sabouri, and BIP 347 propose for the reactivation of tapscript is not one. This was an opcode originally added to the Bitcoin first release for manipulating the data elements in the stack. In 2010, it was disabled with the release of Bitcoin 0.3.10 Along with other opcodes, due to fears of denial-of-service attacks which could crash nodes. There was also a global maximum of 520 Bytes per item while running a script. 

There isn’t much explaining required for OP_CAT, as you should have an understanding of the script evaluation stack and how bitcoin transactions work. 

The Schnorr signatures can make OP_CAT mimic covenants. The topic is explained in detail. here Andrew Poelstra, Blockstream. I will just give a very high-level view. Each elliptic curvature has a “generator point”, which is basically “0”The elliptic-curve math is then used to generate the key and sign it. Schnorr lets you sign with the generator point, but you’ll have to repeat the process a couple of times to make sure you get it right. 

For now, forget the math and remember that these “weird” Signing allows you to put the current transaction TXID in the stack. 

 How OP_CAT works

OP_CAT concatenates the two top data items in the stack. The top two data items in the stack will be concatenated together. “1” The following are some examples of how to get started: “2”OP_CAT then removes them both and puts “12” The stack is stacked on top. That’s it. 

Uses of OP_CAT

What’s all the fuss about? Why are people so upset about OP_CAT, even though the answer to how it functions is so straightforward that it didn’t take a whole paragraph to explain? 

There are only two, though I am not certain that this is the case. OP_CAT enables the creation and verification of merkle-trees directly on the pile, allowing for some very interesting functionality. This allows for the simulation of covenants, allowing full introspection. “weird” The Schnorr Signatures are listed above. 

Taproot is built around merkle proof verification. But the way that it’s implemented, merkle tree validation only happens when a tapping script spending path has been committed by the Schnorr root public key of the output of the currency being spent. Taproot does not support generic merkle proof verification. 

OP_CAT can do this with a completely generic approach. You can reconstruct the merkle hash by providing leaf hashes and interior hash nodes sequentially, then calling OP_CAT. It is possible to use this method for providing unilateral withdrawal paths of shared UTXOs like in CatVMYou can depend on a condition to make the transaction. This can be done with any merkle proof. 

Here is the covenant imitation that allows full introspection. You are attempting to ensure that the transaction must have certain features to be valid. Now that you know the basics, it’s important to remember what they are. “weird” Signature gets the hash on the stack. It’s not the original transaction that is signed, but its hash. We can do some interesting things. 

You can create very complex and convoluted scripts by using OP_CAT. Take the raw parts of the transaction and put them on the stack slowly. You can compare individual transactions to predefined hashes using just OP_EQUAL and hashing. After the script, you will have a full stack of transactions. Add the required data, hash them, then compare with OP_EQUAL. “weird” signature. If the check is successful, a CHECKSIG may be performed. “weird” If the signature is made on the same transaction as being spent, then everything will be valid. 

Checking individual parts of the transactions along the journey with OP_EQUAL will ensure that they are as expected. The transaction will be invalid if any one of these fails to pass verification. The emulated covenants are enforced. If the hash of the transaction constructed using OP_CAT is the same as the “weird’ signature match, then the final CHECKSIG guarantees that the transaction constructed with OP_CAT and checked against the emulated covenant matches the actual transaction being spent at the time. 

Closing Thoughts

OP_CAT opens the door to introspection, and data forwarding. The introspection is possible to the smallest degree. Each field can be committed independently. The same capabilities as TXHASH are available, but with more. 

This capability is powerful, but it also raises the question of how and why this will be implemented, as well as what incentives could result. Bitcoin scripts that require transactions to be done on other blockchain systems could be created, so long as the merkle tree is built using hash functions within Bitcoin script. 

While OP_CAT itself is not a Covenant, it allows the full emulation and replication of Covenants using a less efficient Blockchain footprint (and possibly allowing developers to make errors or burn money). This proposal, despite its simplicity, is one that should be treated with caution due to the vast design possibilities it offers.