GMEOW – So you just saw some Quantum Cats evolve and now you’re interested in learning about what OP_CAT is and it’s significance in Bitcoin history. Let's try to break this down and go over a few terms before we go in deeper.

Before we dive in – Just wanted to go over a few terms that I and many other people did/do not know.

Bitcoin Script – A  programming language that allows Bitcoin to be locked, unlocked, and then spent/used once the script verifies. A transaction will typically include an unlock script, and a locking script. 

Stack – A data structure, somewhat similar to an array, in which data is placed on top of each other and “stacked” in an order such as last in, first out. 

Opcode – A  code or a function, that contains operations which will be performed to the data in a bitcoin stack. Typically, it will “pop” two or more items from the top of the stack, do something with/to that data, and then push/return the new item(s) back to the stack.  An example of this is “OP_CHECKSIG”. CHECKSIG. This will pop two items off a stack (the public key and signature), and then it will check that the signature will match the public key, or is a valid signature. If it is valid, it will push a 1 to the top of the stack, and if it is invalid, it will push a 0 to the stack. A script/batch of bitcoin can be spendable If after running the script, there is a 1 at the top of the stack.

Covenant – In real estate, a covenant is a restriction which is placed on land, that dictates how the land may be used moving forward. For example, a covenant may restrict a set of land to only be used for farming. If a real estate developer would like to build apartment complexes, they would be unable to due to the legally binding nature of the covenant to that land. Another example can be of a Home Owner’s Association – implying there are certain things you can and can’t do with your home.

In Bitcoin, it works similar. A Bitcoin Covenant is a script that restricts the way a transaction can spend coins. These restrictions would be added to bitcoins which were transferred over to someone else, and the receiver of these bitcoin would need to comply with these covenants.
Examples of this are… Limiting a max amount of how much bitcoin can be spent in the next transaction, whitelisting of addresses, determining the next transaction, or even implementing a recovery transaction to send bitcoin to a safe address if the covenant is violated.

Now, what the hell is OP_CAT?

OP_CAT was an original opcode included in the bitcoin script in 2009. The “CAT”, stands for concatenate, which just means linking two or more things together (in this case, text which represents data). A simple example of a concatenate function in computer science would be the following. =CONCATENATE("Satoshi", " ", "Nakamoto!"). This simply is combining the word “Satoshi”, a space, and “Nakamoto” to create and link together to equal “Satoshi Nakamoto” as the final output. This is just the tip of the iceberg however, and the reality of OP_CAT is much more complicated and dynamic. 

The idea here with OP_CAT, is that it takes two data sets/elements in a stack, concatenates them (combines them), and finally pushes it back into the stack. This allows it to create complex covenants as seen in the examples above, alluding again to the vault. The technicals are significantly more complicated than this, and I am definitely leaving a lot out, but this is the extent to which my understanding takes me.

If there are less than two elements/values on a stack, then OP_CAT will fail. Similarly, if the combined result of an OP_CAT operation is greater than 520 bytes, then it will also fail, however the 520 byte limit was implemented after the removal of OP_CAT. 

The reason why OP_CAT was actually removed/disabled by Satoshi in  2010, was due to potential exploits or vulnerabilities with the OP_CAT function. OP_CAT is a relatively simple, but powerful function combining data elements, and can also be used to create complex covenants. One exploit was using the OP_CAT and OP_DUP functions together, which allowed you to greatly increase the stack size. This could infinitely scale and create extremely large stack elements, leading to DoS (Denial of Service) attacks, causing normal bitcoin transactions to not be made. Simply put, by using OP_CAT, bad actors can hurt the bitcoin network/infrastructure. Now, we have the 520 byte stack size limit, so if the an OP_CAT would exceed it, the TX would fail and be considered Invalid, putting some safeguards in place to protect the network and it’s users. However, re-enabling it can also lead to new unintended consequences which were not explored yet due to it’s dynamic nature. 

But OP_CAT is disabled? How do we get it back?

Easily enough, through a soft-fork and around a dozen lines of code, the OP_CAT function can be re-enabled. This soft fork would be similar to the one in 2021, which lead to the taproot and bitcoin ordinals! Fun fact – Bitcoin Cash actually also re-enabled OP_CAT back in 2018. 

A softfork can be done to re-add the OP_CAT opcode, which is a safer route that would not change the blockchain rules and split the network in the way a hardfork would do. Furthermore, this can be done from the consensus of an economic majority. It would be easy to implement, allowing for more utility, scalability, and complex transactions to be created, while not requiring that the Nodes upgrade – but it may take time.

So In conclusion, let’s jot down some Pro’s and Con’s to OP_CAT

PROS:

- Can enable and emulate covenants, changing the dynamic of scripting and providing more utility in the bitcoin network. Similar to the soft fork in 2021 with ordinals, it can create a whole new layers of functionality
- Can enable and enhance a further level of security, such as vaults, or even 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. Higher level of protection for users against theft. 
- Can create allowlists of wallets and other dynamic restriction output scripts. 
- Can create new forms of wills/trust for sending bitcoin to inheritors
- Can potentially create Layer 2s and Bridging Mechanisms to other chains 

CONS:

- OP_CAT is incredibly powerful and can allow for dynamic scripting, but potentially unexpected, unintended consequences from bad actors. It is not fully clear just how big of an impact OP_CAT can make on the bitcoin network, even with the 520 byte safeguard in place. The implications of OP_CAT are not fully understood just yet.
- Satoshi removed OP_CAT intentionally from the original bitcoin script. There is an argument to keep the bitcoin network unchanged and in Satoshi’s vision. The other argument is to move extremely slowly, to ensure the stability of the network.
- Complexity – Many argue that bitcoin needs to remain simple, and that adding this layer of complexity can harm the space as a whole for new users/entrants.    

This was an incredible experience to dive deep in a part of bitcoin that I have never seen before, or even know about. Even though I use the bitcoin network on a daily basis, and engage with ordinals and inscriptions, at the end of the day I realize I don’t truly understand the tech, and considering the amount of time I’ve been in this space, it’s a shame. I truly appreciate @TaprootWizards and @QuantumCatsXYZ for pushing everyone in the space, including myself, to continue to educate ourselves with the blockchain that we use everyday. I am extremely grateful to have obtained a very basic understanding of OP_CAT and it’s history, and I look forward to continuing to expand on that foundation and diving deeper into the tech, and the engine behind the hood. Thank you for your time! 

Twitter: @RiskETH 
Discord: risk.eth