BIP-420 Development

Bitcoin’s scripting system was created by Satoshi himself. When a transaction is checked to see if it was actually signed by the corresponding key, a sequence of operations takes place through which data is accumulated, hashed, and verified. This scripting system is modeled after an old, simple device programming language, Forth, and operates by placing commands on a so-called stack and calling them from there.

Like a calculator, Bitcoin software has various instructions, called opcodes. These instructions aren’t Turing-complete like in a conventional programming language, but in combination they allow for various operations that go far beyond standard transactions. Many of these commands, which were initially included in Bitcoin, were later deactivated.

Satoshi feared that they could be misused, for example, to conduct congestion attacks, while they were not necessary for ordinary transactions, which was what he was concerned with, at least in the early days of Bitcoin.

One of these deactivated codes is OP_CAT. «CAT» stands for concatenation, and in computer science, it means concatenating elements in list-like data structures without changing their order. If you concatenate 1 and 2, the result is 12 instead of 3, as with addition.

OP_CAT has long been on many developers’ wish lists of opcodes to be reactivated. OP_CAT could be used to map numerous operations on the blockchain that are currently not possible, including: Vaults can be created.

This is a way to store Bitcoins in such a way that they cannot be stolen even with knowledge of the private key. Vaults or covenants were supposed to be introduced with BIP-119, but this failed. OP_CAT would be sufficient to create vaults even without this. One can introduce quantum-safe Lampert signatures (although it is not entirely clear whether they would really be quantum-safe in this context).

The Bitstream protocol allows for decentralized key exchange, which would enable, among other things, decentralized file hosting Tree signatures can also be used to build large multisig constructions with extremely low data consumption. OP_CAT could improve payment channels in a certain way. OP_Cat allows for a whole new class of operations.

As with Taproot, it’s safe to assume that the examples mentioned above only cover a small part of what will be possible, and probably not even the most interesting ones. The problem with OP_CAT is that the opcode made it possible to sneak operations into a transaction whose execution would be exponentially more complex than the data itself. This could have overloaded the memory of all nodes. BIP 420 circumvents this problem by introducing OP_CAT as Tapscript.

Tapscript is the scripting language used in Taproot signatures. With a few exceptions, it is identical to Bitcoin’s traditional scripting language. One difference is that each stack element is limited to 520 bytes, effectively mitigating the attack.

Blockchain researcher and Bitcoin developer Ethan Heilman submitted BIP – without the number 420 – for discussion in December 2023. It was well received by the developer community. Since the OP_CAT proposal was formally given the BIP-420 number in April 2024, the Bitcoin development community has acknowledged its significance. OP_CAT first appeared on «SIGNET», the official Bitcoin testnet, in May 2024. In a real-world testnet environment, developers were able to test and create applications that make use of the operation.

However, community consensus and a thorough assessment of OP_CAT’s security and usefulness are required before it can be implemented on the Bitcoin mainnet.

Despite OP_CAT’s many potential benefits, there are a few things to think about carefully before putting it into practice:

Security

Adding new opcodes to the Bitcoin scripting language always carries some risk. It is essential to ensure that OP_CAT is implemented safely and without any flaws that an attacker could exploit.

Consensus

Any changes to the protocol must be approved by the Bitcoin community. This includes node operators, miners, developers, and other interested parties. Reaching an agreement on a new opcode, such as OP_CAT, can be challenging and time-consuming. The existing Bitcoin infrastructure, which consists of wallets, exchanges, and other services, must be compatible with OP_CAT. Careful planning and collaboration are required to ensure a smooth transition.

What sets OP_CAT apart from other scaling solutions for Bitcoin?

The OP_CAT base layer improvement will increase the blockchain’s capacity for Bitcoin smart contracts. It offers a more adaptable and effective framework for developing sidechains and second-layer protocols, two more methods of scaling Bitcoin.

For instance, OP_CAT can be used to create more effective and safe bridges between sidechains and Bitcoin, making it easier to move data and assets between the two chains. Additionally, it can be used to enhance the functioning of second-layer protocols, such the Lightning Network, which enables the development of increasingly intricate applications and smart contracts on top of Bitcoin.

Without widespread use and evidence of its resilience, the use of OP_CAT is still debatable and needs more research.