Hardly any other proposed change for Bitcoin is as easy to explain on a purely technical level as OP_CAT. Unfortunately, this opcode is not about cats — even if the 😺 emoji quickly established itself as a trademark — but about concatenation , i.e. the linking or joining of two input values to one output value.
We remember: All Bitcoin outputs are secured with a small mini-program that was created using the Bitcoin-Script language . Such a program typically consists of checking whether a digital signature is valid, but can also use more complex combinations of various commands (opcodes) to cover other use cases.
OP_CAT is exactly such an opcode, with the fairly simple but powerful function of concatenating two values. For example, if there are two values “block” and “trainer” on the stack, OP_CAT takes these two entries and simply puts them together so that the result “block trainer” is now saved. At first, this functionality seems almost too boring to enable any exciting functions, but appearances are deceptive…
An old acquaintance
In fact, the CAT opcode is nothing new, on the contrary, it was already part of the official Bitcoin-Script instruction set in a very early version of Bitcoin. At the time, Satoshi Nakamoto was justifiably worried that the small programming language he had more or less put together would eventually become too powerful and cause problems. That’s why, among other things, the decision was made to quietly and secretly deactivate OP_CAT for security reasons .
However, vehemently rejecting the current proposal because the Bitcoin inventor himself ultimately decided against it is a somewhat hasty conclusion. One of the main reasons for disabling it at the time was the potential for skillful and repeated use to create an exponentially growing memory problem as individual elements on the stack could continue to bloat.
In the meantime, to be precise since it was deactivated, a maximum size of 512 bytes has been provided for stack elements and this is also actively enforced today within Tapscript, i.e. Bitcoin Script under the Taproot update. The problem from back then doesn’t really apply here, as a script that wants to create elements above this limit would simply be invalid.
OP_CAT fails if there are fewer than two values on the stack or if the concatenated value would have a combined size greater than the stack element maximum of 520 bytes.
From the GDP draft
The possibilities
It turns out that concatenating two inputs is such a fundamental operation that when you start listing potential use cases for Bitcoin, it’s almost impossible to keep up with it. For example, the BIP draft mentions new options for signatures, including quantum-safe Lamport signatures or Bitcoin vaults, in order to provide additional protection against the compromise of one’s own Bitcoin wallet.
With the help of OP_CAT, so-called covenants can in principle be implemented, i.e. predetermined conditions to whom a certain Bitcoin output can be issued. This in turn opens the door for new scaling methods such as Ark and many other approaches that depend on covenants. The recently introduced BitVM concept for verifying any calculations on Bitcoin would also be much easier to implement and more efficient with OP_CAT.
Another very interesting possibility is to link the validity of a transaction not just to a valid signature, but to a specific valid signature, thereby enabling effective protection for unconfirmed transactions. The previously mentioned Ark concept, for example, would also benefit from this…
Personally, I’m particularly excited about the prevention of double-spend [in unconfirmed transactions]. This would result in Ark payments being processed immediately, similar to Lightning.
Ark developer Burak on 𝕏
But before we get too lost in the land of milk and honey of possible applications, we can simply agree on the conclusion that OP_CAT will certainly not be short of potential possibilities. In addition to the already known functions, many new ideas and approaches could also develop that were previously nipped in the bud at an early stage due to a lack of framework conditions.
When brainstorming ways to do cool things with Bitcoin Script, I would say that about 90% of the time it ends up being something we could do if only we had OP_CAT. And the remaining 10% usually doesn’t need much more.
Andrew Poelstra in a response to the draft
What is the catch?
Actually, this all sounds far too promising to be true and one might think that there must surely be an obvious downside. Sure, of course, for an actual reintroduction of OP_CAT, a soft fork , i.e. a change to Bitcoin consensus rules, is necessary, which should always be carefully planned and considered — along with an extra pinch of caution.
But the current GDP proposal is quite simple, manageable and, at least at the basic level, understandable for everyone. Such a soft fork is also welcome because the focus is clearly on a single adaptation and you don’t lump dozens of different concepts together. Combined with the fixed limitations mentioned, the obvious concerns that led to deactivation at the time also disappear.
Even if OP_CAT is extremely simple in itself, the power of the function should not be underestimated. When a tiny function opens up such a flood of possibilities, you can quickly lose track of potential risks and perhaps even completely overlook critical aspects. The controversial covenants in particular are likely to make some people skeptical. After all, these have been discussed more often in the past, for example in the wake of BIP-119 .
However, the fear of so-called recursive covenants, i.e. the ongoing determination and effective blocking of how certain Bitcoins may be issued, is unfounded. As it currently stands, OP_CAT combined with Taproot’s Schnorr signatures is not capable of implementing such a complex restriction.
Furthermore, OP_CAT has been part of some altcoins and the Liquid sidechain for a long time, without any security gaps having arisen in this regard.
Conclusion
While it can certainly be annoying at times for dedicated developers, the beauty (and important) thing about Bitcoin development is its controlled slow pace. No change, regardless of whether it is OP_CAT or something completely different, can and will be implemented overnight. Even if so, at the end of the day the users still have to decide for themselves whether they want to use or even support a particular update.
The ratio between effort and possible use cases for OP_CAT is very promising, while currently, apart from the principles mentioned, there are actually no obvious disadvantages. In all of this, one should not forget that we are currently still at a draft of a proposal and actual activation in the Bitcoin network is still relatively far away.
So there is still a lot of time left to philosophize about OP_CAT and perhaps discover one or two disadvantages or even positive side effects.
