This is the fifth article in a series Deep diving in individual covenant proposals that have reached a maturity point that deserves an in -depth breakdown.
OP_CAT, performed for reactivation in TapScript by Ethan Heilman and Armin Sabouri in BIP 347, is not a pact. It was an opcode that was originally included in the first release of Bitcoin to manipulate data elements on the stack. It was disabled in 2010 with the release of Bitcoin 0.3.10 along with a number of other opcodes due to concerns about the denial of service attacks that could go down to nodes. A global maximum limit of 520 bytes for any individual item on the stack, while a script was also performed.
You must already have a basic understanding of how the script valuation on the stack works and the basic pieces of a Bitcoin transaction, so there is not very much prerequisite that explains necessary for OP_CAT.
While OP_CAT may not be a covenant in itself, it can mimic covenants due to a tip in how schnorr- signatures work. This is a beautiful in -depth topic that is fully explained here by Andrew Poelstra from Blockstream, so I just want to keep myself with a high -level view. Each elliptical curve has a generator point that is essentially “0” used in the elliptical wicker math for key production and signing. With Schnorr you can sign using the generator point as a key and give or take a few bytes that you need 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 it works mathematically for now, and just remember for later that these “strange” signatures allow you to get the current transactions txid on the stack.
How up_cat works
OP_CAT takes the top two data elements on the stack and link them together. So if the two top items on the stack are “1” and “2”, up_cat them both and then put “12” on top of the stack. That’s it.
What is up_cat useful for
Okay, so what’s the big one? Why freaking everyone out of OP_CAT, even if it’s so simple that the explanation of how it works didn’t even take a complete section to write?
Two reasons, although I can give any guarantees that this 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 that enable full granular introspection due to the “strange” schnorrhagic signatures mentioned above.
Verification of Merkle Proof is a key component of Taproot, but the way it implements Merkle Tree verification occurs only when verifying that a tap script -consumption path is obliged in Root Schnorr Public Key in the output script to the coin used. Taproot does not support generic verification of Merkle certificate.
OP_CAT permits this in a completely generic way. Simply delivering leafhash (ES) and then interior hash node in the correct order and call Op_cat successively allows you to reconstruct a Merkle Root Hash and compare with a predefined hash in the script. You can do this to provide unilateral retirement paths to shared UTXOs as in CATVM, you can make transactions dependent on other transactions being included in a block of valid work, you can make a transaction depending on virtually any condition that can be verified with a Merkle certificate.
Now for the covenant mulation that enables full introspection. What you are trying to do is ensure that a transaction must have certain properties to be valid. Now remember that the “strange” signature gets hashish of the transaction on the stack. In fact, a transaction signature is not done over the raw transaction, it is done over its hashish. This allows us to do something interesting.
You can construct very complicated and intricate 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 controlled against predefined hash by simply hacking them and using up_equal. At the end of the script, you have the full transaction on the stack itself and can add the necessary data to it and then hash them, again compare them with OP_EQUAL, this time against the “weird” signature. If this control goes, a normal control can be run and as long as the “strange” signature was made with the transaction used, everything is performed as valid.
OP_EQUAL controls individual pieces of the transaction along the way guarantees that these pieces of the transaction are exactly what they should be. If any of them fail the verification, the transaction is invalid. This enforces the emulated covenants. At the end, if the transaction trash constructed with OP_CAT and the “strange” signature fight, the final check guarantees that the transaction constructed with OP_CAT and controlled against the emulated covenant matches the actual transaction used at that time.
Closing thoughts
Op_cat blasts the doors of introspection and forward data that carry completely. Introspection can be obtained to any desired granular degree where each field of the transaction is capable of being independently obliged to. It enables all the same introspective capabilities that txhash does, and then some.
The ability to verify generic Merkle evidence is also a strong functionality, but questions how this capacity will be used and what type of incentives can create. Bitcoin scripts could be constructed that require some transaction to be made on external blockchain systems as long as they use Merkle trees built with the hash features available in Bitcoin script.
While OP_CAT itself is not a pact, it allows full emulation of covenants with a much less effective blockchain footprint (and potential for developers to make mistakes and burn money). It is a suggestion that despite being incredibly simple self, one must approach gently considering the massive design space it opens up.