OP_CAT is an opcode, which stands for operation code, that was part of the original Bitcoin scripting system. It was used to concatenate, or join, two data sets or elements from a stack, and then put them back into the stack. This allowed for creating complex covenants, which are rules or conditions for how bitcoins can be spent. OP_CAT was disabled by Satoshi Nakamoto in 2010, due to security concerns, such as the possibility of creating DoS (Denial of Service) attacks by using OP_CAT and OP_DUP together to create extremely large stack elements. Some developers have proposed to re-enable it with a soft fork, which is a backward-compatible change to the Bitcoin protocol. Re-enabling OP_CAT could enable more functionality, scalability, and security for Bitcoin transactions, but it could also introduce new risks and complexities.
What are the Pros of OP_CAT?
Some of the potential benefits of re-enabling OP_CAT are:
- It 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.
- It 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.
- It can create allowlists of wallets and other dynamic restriction output scripts, and new forms of wills/trust for sending Bitcoin to inheritors.
- It could create Layer 2s and Bridging Mechanisms to other chains.
What are the Cons of OP_CAT?
Some of the potential drawbacks of re-enabling OP_CAT are:
- OP_CAT is incredibly powerful and can allow for dynamic scripting, but potentially unexpected, unintended consequences from malicious actors. It is not fully clear just how big of an impact OP_CAT can have on the Bitcoin network, even 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. This means that any data element pushed onto the stack, such as a public key, a signature, or a redeem script, cannot exceed 520 bytes in length. If it does, the transaction will be considered invalid and rejected by the network. The 520 byte limit has some implications for the Bitcoin scripting system, especially for the Pay to Script Hash (P2SH) feature, which allows users to create complex scripts and hide them behind a hash. For a P2SH transaction, the entire script is pushed onto the stack and must respect the 520 byte limit. This sets the upper limit to n-of-15 for a P2SH multisignature script, meaning that any larger multisig script would be unspendable due to the 520 byte consensus rule. The implications of OP_CAT are not fully grasped just yet.
- Satoshi removed OP_CAT deliberately from the original Bitcoin script. There is an argument to keep the Bitcoin network unmodified and in Satoshi’s vision. The other argument is to move extremely cautiously, to ensure the stability of the network.
- Complexity — adding more opcodes could introduce more bugs, vulnerabilities, and confusion.
The pros and cons of OP_CAT are not fully understood or agreed upon by the Bitcoin community, and the debate is likely to continue for a long time.
