The hotly debated new proposal, OP_CAT, what impact will it have on the Bitcoin ecosystem? Although it has not yet been officially merged into the Bitcoin Core code, it has already sparked extensive discussions in the BTC community.
So, what problem does OP_CAT opcode actually solve? What improvements will it bring to the programmability of BTC? What impact will it have on the future market development of the BTC ecosystem? Next, let me 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 any benefits for BitVM?
OP_CAT is a brand new opcode proposal, jokingly referred to by developers as being in a quantum entangled superposition state between BIP420 and BIP347. The specific EIP is not important, as long as it is clear that this is a proposal that is still under discussion and has not been formally adopted. In simple terms, OP_CAT can achieve the combination and processing of multiple UTXO unlocking script byte strings, which can enhance the programmability, scalability, and on-chain verification complexity of the BTC mainnet.
Similar to Covenant as a Bitcoin script extension proposal, the goal of OP_CAT is also to enhance the extensibility of Bitcoin scripts. The difference is that Covenant aims to achieve more complex programmability of Bitcoin transactions to support complex smart contracts and application scenarios. In comparison, OP_CAT is more practical. Its goal is to simplify the construction and execution of complex scripts to improve on-chain verification efficiency.
In layman’s terms, OP_CAT provides the ability to combine script fragments. Prior to its introduction, each UTXO script was executed independently. With OP_CAT, we can break down a complex execution logic into a series of simple script fragments and store them in different UTXOs, created by different transactions. When complete execution is required, full nodes use the OP_CAT instruction to concatenate and execute these script fragments in order.
With this combination ability, theoretically, Bitcoin can have many complex execution logics. For example:
1. Multi-signature with time lock, which can have more complex execution and unlocking conditions across multiple entities, UTXOs, and time locks.
2. Recursion and looping, allowing multiple script byte strings to form recursive and conditional executions, continuously looping until a certain termination condition is met.
3. Modular applications, common script logics can be extracted and reused in multiple program execution fragments. For example, Alice transfers money held on platform C to Bob, requiring signatures from all three entities. If the signing time exceeds the time limit, Alice and Bob can jointly sign to retrieve the funds. If Bob does not sign for a long time, Alice can cancel the transaction. If Bob suspects issues with the source of Alice’s funds, he can refuse to accept them, and so on. This is just a simple example. In reality, the combination of script fragments can be used to achieve more complex and granular control.
Previously, BitVM executed complex operations off-chain, only implementing crucial verification and settlement on-chain, sparking great imagination for the programmability and Turing-completeness of BTC. OP_CAT on the BTC mainnet is another supplement to the imagination of recursive combination execution. Moreover, OP_CAT has many benefits, such as accelerating the implementation of BitVM, reducing on-chain verification costs, and more.
How to understand it? Previously, for BitVM to execute, the off-chain programs had to be packaged into independent script fragments that can be executed by a single UTXO. The off-chain construction cost was high. When executing and assembling these fragments on-chain, a more complex TaprootTree structure would be needed. This means that the cost of on-chain verification and interaction for a segment of BitVM program execution would be relatively high. After OP_CAT is introduced, the fragments packaged by BitVM off-chain do not need to be able to execute independently for each one. On-chain, the UTXO unlock conditions can accumulate to a certain extent before performing a summary and updating the state. Obviously, the combination of script fragments can greatly reduce the number of interactions and costs required for on-chain verification.
In conclusion, the heated discussion surrounding OP_CAT reflects everyone’s expectations for further enhancing the programmability of Bitcoin. If it is truly implemented, it will have a catalytic effect on the implementation of BitVM, the security improvement of various BTC layer2 cross-chain asset solutions, the expansion of the UTXO-bound chain ecosystem, the development of the mainnet at the same frequency, and even the potential progress of scalable markets such as the Lightning Network and RGB client verification. Theoretically, any improvement in BTC’s programmability will have an immediate stimulating effect on its extended ecosystem. After all, everyone is trying to build an oasis in the desert, and if one day the sand turns into a concrete floor, it will be much more convenient to build a building.
However, will it be officially merged? Considering the Covenant proposal that has been put forward for many years but not adopted, it is also good to use OP_CAT’s new proposal to imagine some market possibilities.
Successful Conclusion of CoinEx Taiwan’s 7th Anniversary Celebration, Embracing the Arrival of the Web3 Era Hand in Hand with Users
Since its establishment in 2017, CoinEx has been a professional cryptocurrency trading pla…