Today, the main problem with Bitcoin protocol development seems to be modularity. By this I mean that the implementation or rejection of a single programmability capability or feature in Bitcoin determines the shape and changes that its protocol will experience in 2025. These changes could be large, significant, and affect the currency network forever.  

By 2025, Bitcoin could see a rapid, perhaps even greater, transformation than usual if developers opt for modernizing and “accelerating” the protocol by implementing covenants, ZK-rollups , and layer-2 solutions, all of which would be possible through a single opcode : OP_CAT. This is a programming code in Bitcoin Script that allows two values ​​to be concatenated into a single stack of code. 

OP_CAT was implemented by Satoshi Nakamoto, the creator of Bitcoin, and later removed from his scripts in 2010, following an event known as the value overflow incident.  

This incident allowed the creation of over 184 billion non-existent bitcoins. This amount far exceeded the fixed supply of 21 million BTC. The devaluation episode was resolved by rejecting the overflow of value by publishing a new version of the bitcoin client, which had the effect of a soft fork in the network's consensus rules. 

Today, this opcode is back in use, but as a proposal in the Bitcoin development repository with the identifier BIP: 347. That is, it has been rescued from the past (and promises to be important for the future) for the functionalities it would add to the protocol of the most important cryptoasset in the world. 

Why OP_CAT? 

According to the proposal repository, Bitcoin scripts, specifically the Tapscript extension of this programming language, lack a general-purpose way to combine objects into code stacks, which imposes limitations on the protocol's programmability. 

The absence of this technical capability restricts Tapscript's expressiveness and power. This prevents, among many other things, the ability to build and evaluate Merkle trees and other hash data structures in Tapscript. OP_CAT, by adding a general-purpose way to concatenate values ​​from the stack, would overcome this limitation and greatly increase Tapscript's functionality. 

Github, BIP 347.

It is said that the future of Bitcoin development is modular because the integration of OP_CAT alone would allow for a considerable expansion of its protocol.  

Below is a list of use cases that the inclusion of this opcode would enable: 

Bitcoin to pay for information natively 

Bitstream is a protocol that allows payment with bitcoin to data and file hosting servers. While this protocol could be implemented without OP_CAT, the inclusion of this opcode simplifies the process and resources, eliminating the need for more complex technical solutions.  

An atomic swap of coins [bitcoin] for files would enable an open market for content hosting, where anyone can monetize their excess bandwidth and data storage capabilities, offering decentralized media services. 

Bitstream Whitepaper, data hosting server.

This means that OP_CAT would allow decentralized media content distributors to be paid directly through the Bitcoin chain. BTC would thus expand its use cases, specifically its scope as a means of payment on the internet. 

Tree signatures for advanced multi-signature transactions 

Tree signatures allow for more flexible spending conditions, especially in multi-signature conditions. They allow for more complex conditional spending than the traditional “n-of-m” spending used by current multi-signature transactions, where “n” is the number of signatures required and “m” is the total number of keys. 

According to the Bitcoin proposal repository, tree signatures allow that “a transaction less than 1 KB in size could support tree signatures with up to 4,294,967,296 public keys.” Therefore, they contain many public keys without the transactions needing to take up much space. 

Protection against quantum attacks 

Lamport signatures, a system of one-time keys, can theoretically protect bitcoin against quantum attacks. It is clear that such attacks will be possible in the future, especially now that the first stone in the building of commercial quantum technology has been laid: Google's Willow chip. 

One expert says that in order for Lamport signatures to protect Bitcoin from quantum processing, the introduction of OP_CAT is required. 

If we required the ECDSA signature to be signed with a quantum-safe signature algorithm, then we would have a quantum-safe Bitcoin. And the 5-byte signature scheme we discussed above is a Lamport signature, which is quantum-safe. Unfortunately, we need at least 20 contiguous bytes… so we need some kind of OP_CAT-like operation. 

Jeremy Rubin, Bitcoin developer.

ECDSA stands for Elliptic Curve Digital Signature Algorithm. Simply put, it is defined as the method used by Bitcoin to generate digital signatures and verify their authenticity and integrity, all of which helps protect Bitcoiners’ keys. 

ECDSA's security, which is based on the difficulty of solving the mathematical problem of the private key from the public key (elliptic discrete logarithm problem), is practically invulnerable against the computing power of current computers. Quantum computers, however, could defeat it, which is why a quantum-proof algorithm is needed. 

Punishing attempted double spending on Bitcoin 

No-mistake contracts serve to prevent and punish double spending in Bitcoin sidechains. Preventing double spending in digital payment systems is important because the proliferation of these, and even just one, can lead to a loss of confidence in the electronic system.  

These contracts can be used using the Tapscript language, but using OP_CAT, as this opcode applies “rules on the nonce [unique numbers used once] of the spending transaction.” Since bitcoin already has ways to prevent double spending from happening on its mainnet, this technological advancement would especially affect payment channels.  

Bitcoin's new lines of defense 

Vaults are specialized contracts that protect a user's funds from theft, even if they lose their private key, which has historically been considered the last line of defense in Bitcoin self-custody.  

Using OP_CAT, Bitcoin scripts can use covenants , smart contracts that restrict how bitcoins can be spent. These covenants are necessary to design vaults that allow attackers to be banned from fraudulently possessing funds.  

Vaults are an attractive key backup and access option for many developers who see traditional single-key private key custody as a point of failure in the wide-scale adoption of bitcoin. 

Is there a secondary interest in OP_CAT? 

The discussion on OP_CAT, which would bring all the possibilities mentioned above among many others, has become lively in recent years, especially in 2023.  

The reason it is back in the spotlight is that its reintegration would allow for the creation of smart contracts on Bitcoin. That's right: part of the developer community envisions a future where Bitcoin has similar functionalities to Ethereum, even if OP_CAT is intended to improve the conservative core of Bitcoin's technical side.  

With OP_CAT, it is plausible that Bitcoin, in addition to being a payment network, could also function as an application and business layer on top of the Internet. This would allow many Internet businesses and companies to capture a significant market share of one of the most important assets in the world. 

Of course, not all developers agree with this fate for Bitcoin. Some consider OP_CAT to open the door to bugs and security vulnerabilities, and would prefer Bitcoin to remain a conservative network, specialized in transfers of monetary value.  

Finally, it is not ruled out that the Bitcoin development community will create a technical solution that does not require a network fork to add smart contracts and other advanced features, which would be a middle ground between conservative and progressive Bitcoiners.