Bitcoin Covenants: OP_CAT (BIP 347)

Bitcoin Covenants News

Bitcoin Covenants: OP_CAT (BIP 347)
OP_CATBIP 347

The fifth article in the Covenant series, examining the OP_CAT reactivation proposal from Ethan Heilman and Armin Sabouri.

, 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 thealong 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 explainedby Andrew Poelstra from Blockstream, so I’ll just stick with a high level view. Every elliptic curve has a generator point, which is essentially “1”, 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.

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. 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 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, 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. 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 . It is a proposal that despite being incredibly simple itself, should be approached cautiously given the massive design space it opens up. Shinobi is an pseudonymous self taught educator in the Bitcoin space.

He was the co-host of Block Digest, a news/tech oriented Bitcoin podcast, as well as What Bitcoin Did Tech Show with Peter McCormack which centered around explaining technical concepts to non-technical users. That is all he will tell us about himself.

We have summarized this news so that you can read it quickly. If you are interested in the news, you can read the full text here. Read more:

BitcoinMagazine /  🏆 461. in US

OP_CAT BIP 347

 

United States Latest News, United States Headlines

Similar News:You can also read news stories similar to this one that we have collected from other news sources.

Biggest Bitcoin Critic Schiff Demands SEC Antifraud Investigation Into Saylor and StrategyBiggest Bitcoin Critic Schiff Demands SEC Antifraud Investigation Into Saylor and StrategyMichael Saylor and Strategy are facing calls for an SEC antifraud investigation as Peter Schiff warns that the company's STRC model exposes retirees to what he calls a Bitcoin-linked Ponzi scheme.
Read more »

Bitcoin 'Trend Reversal Signal' Flashes as $82.5K Resistance Key for BullsBitcoin 'Trend Reversal Signal' Flashes as $82.5K Resistance Key for BullsBitcoin MVRV momentum indicator’s “golden cross” suggests BTC could be in a macro reversal.
Read more »

Una ballena de bitcoin que permaneció silenciosa desde 2013 mueve 40 millones de dólares en BTCUna ballena de bitcoin que permaneció silenciosa desde 2013 mueve 40 millones de dólares en BTCUna ballena que había estado inactiva por largo tiempo despertó el domingo, moviendo millones en bitcoin en la cadena. Esto es lo que significa para BTC.
Read more »

Bitcoin Could Surge as AI Race and War Fuel Money Printing says HayesBitcoin Could Surge as AI Race and War Fuel Money Printing says HayesArthur Hayes says rising AI spending and the Iran war could trigger more money printing by China and the US, creating favorable conditions for Bitcoin and the wider crypto market to rally.
Read more »



Render Time: 2026-05-17 07:10:56