This is the fifth article in a series deep diving into individual covenant proposals that have reached a point of maturity meriting an in-depth breakdown.
OP_CAT, put forward for reactivation in tapscript by Ethan Heilman and Armin Sabouri in BIP 347, is not a covenant. It was an opcode that was originally included in the first release of Bitcoin for manipulating data elements on the stack. It was deactivated in 2010 with the release of Bitcoin 0.3.10 along with a number of other opcodes due to concerns of denial of service attacks that could crash nodes. A global maximum limit of 520 bytes for any individual item on the stack while executing a script was also added.
You should already have a basic understanding of how script evaluation on the stack works, and the basic pieces of a bitcoin transaction, so there isn’t really much pre-requisite explaining necessary for OP_CAT.
While OP_CAT may not be a covenant in and of itself, it can emulate covenants due to a quirk in how Schnorr signatures work. This is a pretty in depth topic, fully explained here by Andrew Poelstra from Blockstream, so I’ll just stick with a high level view. Every elliptic curve has a generator point, which is essentially “0”, that is used in the elliptic curve math for key generation and signing. With Schnorr, you can sign using the generator point as a key, and give or take a few bytes that you have to sign repeatedly to get right, the resulting signature is actually the same hash of the transaction you signed.
Set aside the mechanics of how that works mathematically for now, and just remember for later that these “weird” signatures allow you to get the current transactions TXID on the stack.
How OP_CAT Works
OP_CAT takes the top two data items on the stack and concatenates them together. So if the top two items on the stack are “1” and “2”, OP_CAT removes both of them and then puts “12” on top of the stack. That’s it.
What Is OP_CAT Useful For
Okay, so what’s the big deal? Why is everyone freaking out about OP_CAT even though it’s so simple the explanation of how it works didn’t even take a full paragraph to write?
Two reasons, although given the nature of OP_CAT I can give no guarantees these are the only two reasons. OP_CAT allows the construction and verification of merkle trees directly on the stack, which opens the door to some interesting behavior and functionality. It also allows emulation of covenants enabling full granular introspection due to the “weird” Schnorr signatures mentioned above.
Merkle proof verification is a key component of Taproot, but the way it is implemented merkle tree verification only occurs in the context of verifying that a tapscript spending path is committed to in the root Schnorr public key in the output script of the coin being spent. Taproot does not support generic merkle proof verification.
OP_CAT allows this in a totally generic manner. Simply providing the leaf hash(es) and then interior hash nodes in the right order and calling OP_CAT successively will allow you to reconstruct a merkle root hash, and compare against a pre-defined hash in the script. You could do this to provide unilateral withdrawal paths for shared UTXOs like in CatVM, you could make transactions dependent on other transactions having been included in a block with valid work, you can make a transaction dependent on pretty much any condition that can be verified with a merkle proof.
Now, for the covenant emulation that enables full introspection. What you are trying to do is ensure that a transaction has to have certain characteristics to be valid. Remember now that the “weird” signature gets the hash of the transaction on the stack. A transaction signature isn’t actually done over the raw transaction, it’s done over its hash. This allows us to do something interesting.
You can construct very complicated and convoluted scripts using OP_CAT to take the individual raw pieces of the transaction as part of the witness, and slowly put them together on the stack with OP_CAT. Along the way, individual pieces of the transaction can be checked against predefined hashes by just hashing them and using OP_EQUAL. At the end of the script you have the full transaction on the stack itself, and can append the necessary data to it and then hash it, once again comparing it with OP_EQUAL, this time against the “weird” signature. If that check passes, a normal CHECKSIG can be run and as long as the “weird” signature was made with the transaction being spent, everything executes as valid.
The OP_EQUAL checks of individual pieces of the transaction along the way guarantee that those pieces of the transaction are exactly what they should be. If any of them fails verification, the transaction is invalid. This enforces the emulated covenants. At the end, if the transaction hash constructed with OP_CAT and 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 blows open the doors of introspection and forward data carrying completely. Introspection can be accomplished to any granular degree desired, with each individual field of the transaction being able to be independently committed to. It enables all the same introspective capabilities that TXHASH does, and then some.
The capability to verify generic merkle proofs is also a powerful functionality, but brings into question how that capability will be used, and what type of incentives that could create. Bitcoin scripts could be constructed requiring some transaction be made on external blockchain systems, as long as they use merkle trees built with the hash functions available in Bitcoin script.
While OP_CAT is itself not a covenant, it allows full emulation of covenants with a much less efficient blockchain footprint (and potential for developers to make mistakes and burn money). It is a proposal that despite being incredibly simple itself, should be approached cautiously given the massive design space it opens up.
