What Is OP_CAT?

Bitcoin upgrades are a contentious subject; whenever they are brought up in conversion, as you can rightly imagine, a larger portion of the population joins in and places their monetary value into the network each year. Now that we’re sitting in the trillion-dollar range, making any changes to Bitcoin becomes a monumental task. 

You’ll find an array of people for or against each one; some subscribe to innovation as the only way to push growth, and you’ll find the ossification crowd, who feel everything is fine and let’s not upset the apple cart. 

Both parties provide a distinct lens through which to review the pros and cons of an upgrade. This allows those who take the middle ground to decide if the trade-offs are worth it and whether they wish to signal for the upgrade. If everyone is happy with the change, it goes ahead; this is how a decentralised network comes to a consensus on changes and why it’s so hard to change Bitcoin.

Bitcoin might be a slow-boomer coin, but it can still be upgraded; it is the OG of programmable money, so allowing for more expressive transactions when needed is possible.  

SegWit and Taproot are evidence of that, but what is the big hoopla about this OP_CAT upgrade? 

What are OP_Codes?

OP_Codes are the foundation of Bitcoin’s scripting capabilities and enable automated, customisable transactions; for example, a timelock forms part of what allows Lightning to exist. 

Imagine Bitcoin as a dance floor. 

Transactions are the moves you bust out, but to truly impress, you tgotta understand the rhythm – the OP_Code. 

These are like the secret instructions for your Bitcoins, telling them when and how to move.

OP_Code upgrades are nothing new; recently, we saw them focused on covenants from CTV to OP_VAULT, all with promising features and being put through the wringer. As I mentioned before, getting an OP_Code into Bitcoin isn’t easy, which is part of the reason why networks like Liquid exist, allowing for more accessible OP_Code launches and testing in production. 

What is OP_CAT?

Cool. Now that we’ve laid the foundation let’s look at OP_CAT. It is a defunct OP_Code—short for operation code—that was part of Bitcoin’s original scripting system. Yes, the mysterious creator of Bitcoin, Satoshi himself, the coolest cat, had his hands on this upgrade.

He included OP_CAT, short for concatenate, which allowed you to combine different steps, like linking a fancy spin with a foot pop for a killer combo. OP_CAT would allow a Bitcoin user to join two data points within an execution stack, setting out prior rules that need to be met to execute the event of a transaction.

But here’s the twist: OP_CAT was banned in 2010 because Satoshi deemed it dangerous. Ever the cautious type, Satoshi worried it could be misused for dance-offs that clogged the whole floor (denial-of-service attacks, for you techies).

However, the debate over OP_CAT is heating back up. Some folks want to bring it back, arguing it can unlock new moves, like covenants. These are agreements built into your Bitcoins, ensuring they can only be spent under specific conditions – like only after a certain date or to a particular address.

OP_CAT is making a comeback

BastionZero co-founder Ethan Heilman and Botanix Labs lead software engineer Armin Sabouri describe OP_CAT as a way to drive the general-purpose functionality that’s been missing from Bitcoin since its very early days. This functionality has been a key driver of growth on Ethereum, the second-biggest blockchain. 

If launched, so-called layer-2 networks might be more manageable to build on than Bitcoin, along with other innovations like decentralised exchanges or file hosting. Yes, it’s starting to sound like the drivechains debate again, same, same, but different. 

Another prominent proponent for OP_CAT is the Taproot Wizards team, which would love to see the rollout not only for the features but also for the branding and synergy opportunities it would bring to their projects, like their recursive inscription Quantum Cats.

With great power comes great responsibility

OP_CAT offers powerful dynamic scripting when you allow the market to leverage that expressiveness to potentially unexpected, unintended consequences from malicious actors. The Taproot upgrade was considerably more restrictive, and from its witness discount, it birthed the ordinal theory madness that has divided a community on how to block space can, will and should be used.

It is unclear how big of an impact OP_CAT can have on the Bitcoin network, even if Satoshi’s original pain point has been eliminated with the 520-byte safeguard in place. The 520-byte limit is a consensus rule that restricts the maximum size of a data push in a Bitcoin script to 520 bytes. 

It could still get messy as this 520-byte rule can affect other operations like large multi-sigs, so it’s not all clear cut, and every possible issue needs to be reviewed. 

Pain in the arse, yes, but rather that than end up downing the network because someone could find a clever way to spam it full of something more harmful than low-quality jpegs. 

What could we do with OP_CAT Covenants?

So I’ve purred your ears off about how OP_CA works and why some people want it, but what will it do for the end user? Well, a few potential use cases proposed thus far include: 

• Non-equivocation contracts: OP_CAT could penalise double spending attempts in payment channels and support protocols like the Lightning Network.
• Failsafe address: OP_CAT could be used to create vaults for your wallet that, if breached, could return exercise return functions which will return all assets to a “Safe address” if a malicious actor obtains your seed keys before the actor is able to send the assets out of your possession, which is great for users, but even more important for businesses and exchanges with complex key management routines. 
• On-chain allow lists: It can create allowlists of wallets and other dynamic restriction output scripts that can be used for on-chain wills/trusts that can pass on Bitcoin to inheritors.
• Bridging funds: OP_CAT could create Layer 2s and Bridging Mechanisms for other chains, similar to what BitVM tries to achieve with its logic circuit.
• Asset briding: OP_CAT could enable the creation of a unique hash, which zero-knowledge rollups on L1 could use to include bridging assets in other Bitcoin environments or various rollups.  
• Vaults: OP_CAT could allow users to set specific spending conditions to restrict how and where an authorised user spends Bitcoin. A vault would require two different transactions to appear in two separate blocks for a user to spend the associated Bitcoin.

Ossification is far off, but any upgrade must be scrutinised 

OP_CAT definitely has some features that could be useful, but they are not without alternative paths to achieve. With the development of second-layer protocols, we never know if their so-called improvements will even be enough to convince the community that the juice is worth the squeese.

So, is OP_CAT a forgotten masterpiece or a recipe for disaster? The Bitcoin community is still cutting a rug on that one. 

If enough time has passed and enough tweet threads have been spammed for Rohan to come to Gondor’s aid, then the hard part is done. Then, all it would take is to patch into an upgraded client and have node operators run the soft forked version. 

Do your own research.

If you want to learn more about OP_CAT, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research other sources, and you can start by checking out the resources below.

• https://blog.yonson.dev/log/2024-02-vol3/
• What the hell is OP_CAT ?