Title: The Controversial New Proposal OP_CAT, What Impact Will it Have on the BTC Ecosystem?
Author: Haotian
CryptoInsight
How should we view the recent controversial Bitcoin proposal OP_CAT? Although it has not been formally merged into the Bitcoin Core code yet, it has sparked wide discussions within the BTC community.
So, what problems does the OP_CAT opcode actually solve? What enhancements will it bring to the programmability of BTC if introduced? What impact will it have on the subsequent market evolution of the BTC ecosystem? Let’s briefly discuss my understanding:
Table of Contents
Toggle
What is OP_CAT?
What goals can OP_CAT achieve?
What changes can OP_CAT bring to Bitcoin?
Does OP_CAT have a positive effect on BitVM?
OP_CAT is a new opcode proposal, jokingly referred to by developers as being in a quantum entangled state between BIP420 and BIP347. The specific EIP is not important, as long as it is understood that this is a proposal still under discussion and not formally included. In simple terms, OP_CAT can combine and process multiple UTXO unlocking script byte strings, enhancing the programmability, scalability, and on-chain verification complexity of the BTC mainnet.
Similar to the Covenant contract Bitcoin script extension proposal, the goal of OP_CAT is to enhance the expandability of Bitcoin scripts. The difference is that Covenant aims to enable more complex programmability in Bitcoin transactions to support complex smart contracts and application scenarios. In contrast, OP_CAT aims to simplify the construction and execution of complex scripts to increase on-chain verification efficiency.
In layman’s terms, OP_CAT provides the ability to combine script segments. Prior to its introduction, each UTXO script was executed independently. With OP_CAT, a complex execution logic can be split into a series of simple script segments stored in different UTXOs, created by different transactions. When complete execution is required, all nodes use the OP_CAT command to concatenate these script segments in sequence for execution triggering.
With this combination ability, theoretically, Bitcoin can have many complex execution logics, such as:
1. Multi-signature with time locks, enabling more complex execution unlocking conditions across multiple entities, UTXOs, and time lock settings.
2. Recursion and loops, allowing multiple script byte strings to form recursive and conditional executions, looping until a termination condition is met.
3. Modular applications, common script logics can be extracted and reused in multiple program execution segments. For example, Alice transferring funds from Platform C to Bob, requiring three entities to sign simultaneously. If the platform exceeds the signing time, Alice and Bob can sign together to retrieve the funds; if Bob does not sign for a long time, Alice can withdraw the transaction; if Bob suspects issues with Alice’s fund source, he can refuse the transfer, and so on. This is just a simple example, and in reality, the combination of script segments can achieve more complex and granular control.
Previously, BitVM executed complex operations under the chain, only realizing key verification settlement on-chain, igniting great imagination for BTC’s programmability and Turing complete computation. OP_CAT’s “recursive” combined execution on the BTC mainnet is another supplement to this imagination. Moreover, OP_CAT benefits greatly from accelerating the implementation of BitVM and reducing on-chain verification costs.
How should we understand this? Previously, for BitVM to execute, the off-chain programs needed to be encapsulated into independent script segments that can be executed by a single UTXO. The cost of building off-chain was higher, and executing and assembling these segments on-chain would also require a more complex TaprootTree structure, meaning the cost of on-chain interaction verification for BitVM would be relatively higher. With the introduction of OP_CAT, the segments encapsulated by BitVM off-chain do not need to be fully independently executable, and on-chain, after accumulating UTXO unlock conditions to a certain extent, a summary can be carried out and the status updated. Clearly, the combination of script segments can significantly reduce the number of interactions and costs required for on-chain verification.
In summary, the controversy surrounding OP_CAT includes everyone’s expectations for further enhancing the programmability of Bitcoin. If it is truly implemented, it will boost the implementation of BitVM, the security of various BTC layer2 cross-chain asset solutions, the ecological expansion of UTXO homologous chain, the synchronous development of the mainnet, and even potential developments in market segments such as the Lightning Network, RGB client verification, etc. The theoretical improvement of any BTC programmability will have an immediate stimulating effect on its expanding ecosystem. After all, everyone is trying to build an oasis in the desert, and if one day the sand turns into a cement floor, wouldn’t it be much more convenient to build a building?
However, will it be truly merged? Thinking about the Covenant proposal that has been proposed for many years but not adopted, using the new OP_CAT proposal to imagine some market possibilities is also a good idea.