OP_CAT was a part of the set of opcodes available for use in Bitcoin’s script early on in its history. In 2010 it was disabled due to concerns over its potential due to security concerns as it enabled creating a denial of service attack against the network. It enabled an attacker to repeatedly call OP_CAT with OP_DUP over data to possibly create a stack object the size of terabytes. Nowadays, this concern is no longer relevant, as a maximum Bitcoin Script stack element size exists.
The current discourse on reintroducing OP_CAT is centered around its potential use cases for Bitcoin and the recently evolving culture in Bitcoin development that favors increased experimentation.
The most promising application OP_CAT enables is ZKRollups on Bitcoin. ZK-Rollups (Zero-Knowledge Rollups) are a type of blockchain scalability solution that bundle (or “roll up”) hundreds of transfers into a single transaction. By using ZK proofs, they allow the blockchain to validate all the transfers in the bundle simultaneously without revealing individual transaction details. This allows for significantly increasing transaction throughput and reducing costs. In a transaction-throughput constrained network like Bitcoin, this is a must for bringing user-adoption.
On a technical level, OP_CAT allows ensuring that Bitcoin that was locked in a rollup script and hasn’t been withdrawn by their owner yet, remains in the script from one rollup state update to the next, until it is withdrawn by the rightful owner. (https://bitcoinrollups.org)
Another useful construction enabled by OP_CAT, this time with security consequences are Vaults. This construction allows for scripting a spending requirement (this output would be called a vault) of a fixed output (a staging output). The staging output in turn, would hold a timelock that allows sending funds arbitrarily only after expiry. Before this expiry, the funds may be sent back to the vault only, and the timelock be reset. As such, a user can create a “waiting area” for his funds. This construction would make it impossible for attackers to steal vault funds. The best case for a victim is that an attacker could only send the victim’s funds to the staging output (if they had compromised the vault key). Should the staging private key be compromised too, then at worst the attacker and victim would start an indefinite battle where they take turns resetting the timelock, with neither gaining control of the funds.
(https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html)
A third possible construction is restricting ways of spending coin given to you by requiring a specific transaction. For example, requiring an identical output script. For example, you may spend an output if you take exactly 1 BTC from it, and send the rest in the change address.
(https://bitcointalk.org/index.php?topic=5471637.msg63056894#msg63056894)
To conclude, adding OP_CAT is a necessary step for the advancement of the Bitcoin ecosystem. We’ve shown how this single opcode can introduce scalability, security and new scripting features to the Bitcoin network. It is an exciting time to witness all these developments and experimentation reigniting on the Bitcoin chain, and as such 2024 is poised to be a very interesting year. Meow.
