Bitcoin has undergone many changes since its inception. From the development of Layer 2 solutions to the introduction of Bitcoin Ordinals, the protocol has transformed time and time again with each new innovation. But even as new technologies are being built, interest in older codes remains. One such situation involves OP_CAT, an early part of the Bitcoin script that was scrapped nearly as quickly as it was developed.
In this piece, we’ll look at some of the history behind OP_CAT and examine why some Bitcoiners believe it’s time to resurrect it.
What is OP_CAT and Why are We Talking About it Right Now?
OP_CAT is a defunct opcode – short for operation code – that was part of Bitcoin’s original scripting system. This bit of code was used to concatenate (aka combine) multiple data sets from a stack, which together could create complex instructions. Think of an individual opcode as one line of instructions; when joined together, they could create more complicated rules for how bitcoin could be spent.
OP_CAT was removed by Bitcoin creator Satoshi Nakamoto all the way back in 2010, but recently, it has been back in the limelight, spurring debates about whether or not it should be revived. This is in large part due to Taproot Wizards, the company behind a new series of Bitcoin recursive inscriptions known as the Quantum Cats collection.
Quantum Cats is a series of 3,333 cat images that were minted using recursive Ordinals inscriptions. They’ve generated plenty of hype from the public, with their “Genesis Cat” inscription selling at Sotheby’s for roughly $250,000 in late January. Taproot Wizards co-founder Udi Wertheimer has said that the collection is meant to pay tribute to OP_CAT.
Why Do Some Want OP_CAT Back?
Potential use cases are at the heart of the argument. Adherents believe that OP_CAT would create more opportunities for scaling up, as well as for enhancing security. They point to the idea that it can enable covenants, which would provide added utility in the Bitcoin space and alter the dynamics of scripting. They also say it would create stronger protections, such as vaults, for users to rely on.
According to its supporters, OP_CAT could enable the creation of a unique hash, which zero-knowledge rollups on L1 could use. It would also allow for other functionalities, including bridging assets. Taken as a whole, the premise of the pro-OP_CAT argument seems to be that it will expand opportunities for builders on the Bitcoin network.
But it’s not without its detractors. Opponents point to the uncertainty that surrounds OP_CAT, highlighting that we don’t know all the risks that come along with re-enabling this code and that it disappeared for a reason.
So, Why Was OP_CAT Abandoned?
OP_CAT was among the earliest opcodes to be disabled. While the concept may sound simple on its face, it carried significant risks to the platform when first written. At the time, it was possible to combine OP_CAT with other opcodes, building huge transactions that the original protocol’s nodes would be unable to handle. Today, a maximum Bitcoin Script stack element size exists, lessening that risk.
But in its infancy, Bitcoin also had far fewer of the safeguards that are in place today, and there were not many options for how to counter this problem. Satoshi also had concerns that the then-young network could be vulnerable to security failings, attacks and breaches. Ultimately, the threat that bad actors could use OP_CAT (particularly the risk of them generating denial-of-service attacks) was among the potential dangers that led to its disabling.
Is There Room For OP_CAT in Today’s Bitcoin Landscape?
But what would it actually take to restore OP_CAT? And is it compatible with today’s protocol? Bitcoin’s governance structure and focus on security has historically meant that it’s slow to change. Additionally, the development of Bitcoin layers like Lightning, Liquid and Stacks has some users debating whether it’s even necessary.
First let’s examine the difficulty and compatibility. Some builders have suggested that it could be re-enabled through a backward-compatible change known as a soft fork. According to Blockworks, Taproot Wizards’ Wertheimer has said it would involve just 10 lines of code to bring back. This allows developers to avoid a hard fork, a more contentious option.
Then there’s usefulness. The potential for utilizing OP_CAT to improve data and execution availability on L1 does present opportunities for growth, particularly in the eyes of those who believe this will help toward the long-term goal of mass adoption. That isn't to say, however, that L2s won't still be crucial to Bitcoin's growth.
But there’s still reason for caution. Even with the 520 byte safeguard, the impact OP_CAT can have on the network is an unknown quantity. And it’s possible that re-introducing a new (read: old) opcode back into the fold could introduce unforeseen bugs or confusion into the system. Detractors claim that OP_CAT is little more than an out-of-hand meme and that it opens the network up to more risk than reward.
Conclusion
In many ways, the debate over whether or not OP_CAT should rise from its purgatory shows how far Bitcoin has come. When it was created, the technological capabilities of the platform were significantly lower than they are today, and the sort of breaches that Satoshi feared were only too real of a threat.
Bitcoin protocol is still evolving. The introduction of Ordinal Inscriptions, ZK Rollups and Layer 2 solutions have transformed Bitcoin into a force to be reckoned with. Whether Bitcoiners ultimately decide to re-enable OP_CAT, keep the status quo or wait for other opcodes with similar functionality will present an interesting question for builders and users alike.
