This is the fifth article in a series You will dive deep into individual contract proposals that have reached maturity worthy of a detailed breakdown.
op_cat, anything submitted for the revitalization of Tapscript by Ethan Heilman and Armin Sabouri on bip 347 is not a contract. This was the opcode that was originally included in the first release of Bitcoin for manipulating data elements on the stack. In 2010, it was deactivated with the release of Bitcoin 0.3.10 along with many other opcodes due to concerns about rejecting service attacks that could cause nodes to crash. A global maximum limit of 520 bytes for individual items on the stack was also added during script execution.
You need to have a basic understanding of how script evaluation in Stack works and the basics of Bitcoin transactions. Therefore, there is not much explanation required for OP_CAT.
OP_CAT may not be a contract in itself, but due to the habit of how Schnorr signing works, it can emulate a contract. This is a rather deep topic and is fully explained here by Andrew Poelstra from BlockStream, so I stick to a high-level view. Every elliptic curve has a generator point that is essentially “0” and is used in elliptic curve mathematics for key generation and signature. Schnorr allows you to sign using the generator point as a key, and give or take bytes that must be signed repeatedly.
Put aside the mechanisms of how it works mathematically for now and remember later that these “strange” signatures allow you to get the current transaction TXID on the stack.
How OP_CAT works
OP_CAT takes the top two data items on the stack and concatenates them. So if the top two items in the stack are “1” and “2”, then OP_CAT will remove both and place “12” on top of the stack. that’s it.
What is OP_CAT?
So, what’s the big deal? Why is everyone getting weird about OP_CAT?
Given the nature of OP_CAT, given the two reasons, we cannot guarantee that these are the only two reasons. OP_CAT directly enables the structure and validation of Merkle trees on the stack, opening the door to interesting behavior and functionality. It also allows for the “strange” schnoll signatures mentioned above, emulation of contracts that allow for full granular introspection.
Merkle Proof validation is an important component of Taproot, but its implementation only occurs in the context of Merkle Tree validation verifying that the tap script spending path is committed with the root Schnorr public key of the output script of the coin used. Taproot does not support general Merkle proof verification.
OP_CAT allows this in a completely general way. You can organize the leaves hash (es) and then provide an internal hash node in the right order, and simply call OP_CAT consecutively to reconstruct the Mercuryroot hash and compare it with the script’s predefined hash. To do this, you can provide a one-sided withdrawal path for a shared UTXOS, like CATVM. You can create transactions that rely on other transactions contained in blocks with valid work. You can create transactions that depend on conditions that can be verified with Markle Proof.
Now, for contract emulation that allows for complete introspection. What you’re trying to do is make sure that the transaction must have certain characteristics for it to be effective. Don’t forget that “strange” signatures get the hash of the transaction on the stack. Transaction signatures are actually done in hashing, not in raw transactions. This allows us to do something interesting.
You can use OP_CAT to build highly complex and complex scripts to shoot individual raw parts of the transaction as part of the witness and slowly put them into stacks in OP_CAT. Along the way, you can check individual pieces of a transaction against a predefined hash by using OP_Equal simply by hashing them. At the end of the script, there is a complete transaction on the stack itself, and you can add the required data before hashing it, this time you can compare it with Op_equal, compared to the “strange” signature. Once that check passes, you can perform a normal check skip and everything runs with effect as long as there is a “strange” signature in which the transaction is being used.
An op_equal check of individual pieces of a transaction along the way ensures that these pieces of a transaction exactly what they should be. If any of them fails validation, the transaction is invalid. This will enforce the emulated contract. Finally, for transaction hash constructed with OP_CAT and “strange” signature match, the final CheckSIG ensures that the transaction checked against the emulated covenant matches the actual transaction at the time.
Close thoughts
OP_CAT blows away that completely carries the door of introspection and forward data. Introduction can be achieved to any fine degree to allow independent commitment for each individual field of the transaction. It enables all of the same introspective features as Txhash.
The ability to verify generic mercle proofs is also a powerful feature, but it raises questions about how that feature is used and what type of incentives can be created. You can build a Bitcoin script as long as you use a Merkle tree built with hash functions that are available in Bitcoin scripts.
OP_CAT itself is not a contract, but it allows for a complete emulation of contracts with inefficient blockchain footprints (and developers can make mistakes and burn money). It’s a suggestion that, despite being very simple, it should be approached carefully given the enormous design space it opens.
This post Bitcoin Contract: OP_CAT (BIP 347) was first published in Bitcoin Magazine and written by Shinobu.
