OP_CAT: Simple uprade for Bitcoin with endless possibilities?

There is currently a new proposal for a Bitcoin Improvement Proposal(BIP) under the name "OP_CAT", which has been increasingly discussed in recent days on platforms such as 𝕏, but also within the developer community. The change itself consists of just 13 lines of code, and the functionality is similarly straightforward at first glance.

In this article, we explain what this new but old proposal is all about, what possibilities it offers for Bitcoin and whether there is still a catch somewhere!

Hardly any other proposed change to Bitcoin is as easy to explain on a purely technical level as OP_CAT. Unfortunately, this opcode is not about cats - even though the 😺 emoji quickly established itself as a trademark - but about concatenation, i.e. the linking or appending of two input values to an output value.

Remember: all Bitcoin outputs are secured with a small mini-program created using the Bitcoin script language. Such a program classically 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 just such an opcode, with the rather simple but all the more powerful function of appending two values together. For example, if the two values "block" and "trainer" are on the stack, OP_CAT takes these two inputs and simply appends them together so that the result "block trainer" is saved. At first, this functionality seems almost too boring to enable any exciting functions, but appearances are deceptive...

In fact, the CAT opcode is nothing new; on the contrary, it was already part of the official command set of Bitcoin Script in a very early version of Bitcoin. At the time, however, Satoshi Nakamoto had legitimate concerns that the small programming language he had more or less put together could end up being too powerful and cause problems. That is why, among other things, the decision was made to quietly and secretly deactivate OP_CAT as a precaution.

However, vehemently rejecting the current proposal because the Bitcoin inventor himself decided against it is a little too hasty a conclusion. One of the main reasons for the deactivation at the time was the potential possibility of creating an exponentially growing storage problem through skillful and repeated use, as individual elements on the stack could continue to inflate.

In the meantime, to be precise since the deactivation back then, a maximum size of 512 bytes has been set 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 does not really apply here, as a script that wants to create elements above this limit would simply be invalid.

OP_CAT fails if there are less than two values on the stack or if the concatenated value would have a combined size of more than the maximum 520 bytes for stack elements.
_{From the BIP}

It turns out that appending two inputs together is such a fundamental operation that it is almost impossible to keep up when starting to list potential use cases for Bitcoin. For example, the BIP draft mentions new possibilities for signatures, including even quantum-safe lamport signatures or Bitcoin vaults to provide additional protection against the compromise of one's own Bitcoin wallet.

In principle, OP_CAT can be used to implement so-called covenants, i.e. pre-defined conditions to whom a certain Bitcoin output can be issued. This in turn opens the door to new scaling methods such as Ark and many other approaches that are dependent 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 only to a valid signature, but to a specific valid signature, thus providing effective protection for unconfirmed transactions. The aforementioned Ark concept, for example, would also benefit from this...

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 lacking in 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 about ways to do cool things with bitcoin script, I would say that about 90% of the time it ends up that we could do it if only we had OP_CAT. And the remaining 10% usually don't need much else.
_{Andrew Poelstra in a response to the draft}

Actually, it all sounds far too promising to be true and you 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's consensus rules, is necessary, which should always be carefully planned and weighed up - along with an extra pinch of caution.

However, the current BIP proposal is quite simple, straightforward and, at least on a basic level, understandable for everyone. Such a soft fork is also welcome because the focus is clearly on a single adjustment rather than lumping umpteen different concepts together. Combined with the aforementioned fixed limitations, the obvious concerns that led to deactivation at the time are also eliminated.

Even though 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, it is easy to lose track of potential risks and possibly even completely overlook critical aspects. The controversial covenants in particular are likely to make some people skeptical. After all, these have been discussed more frequently in the past, for example in the course of BIP-119.

However, the fear of so-called recursive covenants, i.e. the ongoing determination and effective blocking of how certain Bitcoin may be issued, is unfounded. As it currently stands, OP_CAT in combination with Taproot's Schnorr signatures is not in a position to implement such a complex restriction.
Furthermore, OP_CAT has also been part of some altcoins and the liquid sidechain for some time now, without any security vulnerabilities having arisen in this regard.

Even though it can certainly be annoying for dedicated developers at times, the beauty (and importance) of Bitcoin's development is its controlled slow pace. No change, whether OP_CAT or something completely different, can and will be implemented overnight. Even if it is, at the end of the day it is still up to the users themselves to decide whether they want to use or even support a particular update.

In any case, the ratio between effort and possible use cases is very promising with OP_CAT, while there are currently no obvious disadvantages apart from the principles mentioned. However, it should not be forgotten that we are still at the draft stage of a proposal and that actual activation in the Bitcoin network is still a relatively long way off in any case.

So there is still plenty of time to philosophize about OP_CAT and perhaps discover one or two disadvantages or even positive side effects.