Original author:Jaleel，BlockBeats
In the Bitcoin code base, an opcode OP_CAT that was once deleted by Satoshi Nakamoto and has been dusty in history may be resurrected.
Centering around the OP_CAT operation code, the Bitcoin NFT project Taproot Wizards launched a new series of NFT Quantum Cats, causing heated community discussions. Although the name OP_CAT does not refer to the cat we are familiar with, Taproot Wizard used the image of cats to sell a new NFT called Quantum Cats, using meme culture to help OP_CAT build momentum. Related Reading:Bitcoin “Quantum Cat”: Without smart contracts, how can inscriptions change dynamically?》
OP_CAT, this opcode that was once removed from the Bitcoin scripting language by Satoshi Nakamoto, has now been brought back to the table for discussion. Some Bitcoin developers want to resurrect this opcode and use the 13-line code software The fork paved the way for Bitcoin to implement smart contracts. Driven by Bitcoin developers and the cat meme image, the popularity and discussion about OP_CAT has reached new heights.
Resurrection opcode deleted by Satoshi Nakamoto
Opcodes, also known as instructions or functions, are the basic elements that make up the Bitcoin scripting language. Historically, some opcodes were removed from earlier versions of Bitcoin due to concerns about possible vulnerabilities in client implementations, and the OP_CAT opcode was one of them.
OP_CAT was originally part of the official Bitcoin command set and allowed string concatenation operations, splicing two elements into one. But because serious vulnerabilities found in opcodes such as OP_LSHIFT could cause any Bitcoin node to crash, and there are concerns that the OP_CAT opcode could cause stack elements to grow exponentially, this could cause memory usage to grow exponentially with script size.
Therefore, out of caution, Satoshi Nakamoto removed OP_CAT on August 15, 2010. These removed opcodes are often referred to as banned, but this is inaccurate as they are completely removed from the protocol, making them unusable to anyone using Bitcoin.
In October 2023, Bitcoin Core developer Ethan Heilman and Botanix Labs chief software engineer Armin Sabouri jointly released a draft Bitcoin Improvement Proposal (BIP) called OP_CAT, which took this discussion to a new level.
This draft, which contains only 13 concise lines of code but carries clear and intuitive functional properties, defines a new tapscript opcode that allows concatenation of two values on the stack. This code implementation is clearly inspired by the original deleted OP_CAT.
The conditions for resurrection have been met
As for why an opcode deleted by Satoshi Nakamoto is now hoped to be restored by developers, the motivation section of this BIP draft provides some detailed explanations: This is mainly based on considerations of memory usage. OP_CAT enables script construction The memory usage can grow exponentially with the size of the script itself. Specifically, a simple script that simply pushes a 1-byte value onto the stack, copies it with the OP_DUP opcode, and concatenates it 40 times with the OP_CAT opcode can cause the stack value to balloon to over 1 TB. of huge scale.
Nonetheless, as time progressed and technology developed, this issue was no longer an obstacle. Under the tapscript architecture, a clear rule is made that the maximum stack element size is strictly limited to 520 bytes. This change effectively solves the memory usage problems that OP_CAT may cause, providing the possibility of its resurrection and integration.
It can be seen that OP_CAT is once again being discussed and considered for resumption, mainly because of its potential value in building more complex and powerful scripts. In addition, some causes and changes have met the conditions for resurrection, including:
1. Demand for advanced smart contracts and protocols: As the Bitcoin ecosystem develops, the demand for more advanced and complex smart contracts and protocols has increased. OP_CAT increases the expressiveness and power of tapscript by allowing objects to be combined on the stack. For example, it can be used to build and evaluate Merkle trees and other hash data structures, supporting functions such as tree signatures, post-quantum Lamport signatures, non-repudiation contracts, and vaults.
2. Successful cases on other chains: Some Bitcoin forks, such as Bitcoin Cash and sidechain Liquid, have re-enabled OP_CAT and used it to implement token creation and management, payment channels, and in-zone A way to embed and retrieve data on the blockchain. This demonstrates that OP_CAT can be used safely and effectively under appropriate circumstances and constraints.
3. Exploration of quantum security: Some studies have proposed that if operations such as OP_CAT can be used, combined with technologies such as Lamport signatures, quantum-safe Bitcoin transactions and protocols can be constructed. This exploration has potential value in improving the future security of the Bitcoin system.
4. Community and technology development: The continued development of the Bitcoin community and technology prompts people to reconsider and evaluate previous decisions. As the Bitcoin protocol is better understood and new technologies emerge, features previously considered problematic or inapplicable may find safe and useful applications in new contexts.
Soft fork, easier said than done
On a technical level, few other Bitcoin proposals are as easy to decipher and understand as OP_CAT. But the OP_CAT opcode will be activated through a soft fork that redefines the opcode OP_SUCCESS 126, which is obviously not an easy task.
Looking back at Bitcoin’s most recent soft fork, which occurred three years ago, it helped pave the way for the birth of Ordinals due to the activation of Taproot.
The Bitcoin community attaches great importance to consensus and transparency, and any major code changes will be widely discussed and reviewed in the community, including soft forks. For a piece of code to be merged into the Bitcoin code base, it needs to go through a rigorous and detailed process, which ensures the quality of the proposal and the consensus of the community. Here are the main steps of this process:
1. Write proposal and code: First, developers need to write a detailed proposal document. This document should clearly describe the motivation for the proposal, technical details, impact assessment, and any potential issues or challenges.
2. Community discussion: After the code proposal is submitted to the Bitcoin community, community members (including developers, miners, investors, and users) will discuss and review it. This stage is key to ensuring the feasibility of the proposal and gathering feedback.
3. Modifications and improvements: Based on feedback from the community, the author of the code may need to modify and improve the proposal.
4. Vote and reach consensus: For some important improvements (especially those involving changes to the Bitcoin protocol itself), community members need to reach a certain degree of consensus. This usually involves support from miners, who need to show their support for the proposal by including a specific signal in the blocks they mine.
5. Code implementation: Once consensus is reached, the code will be reviewed by the Bitcoin Core developer team. This step is required to ensure the quality and security of the code.
6. Merge into the code base: After passing the review, the code will be merged into the official code base of Bitcoin.
7. Deployment and activation: Finally, the new code needs to be deployed by miners and node operators into their systems. For protocol-level changes, there is usually an activation threshold, and improvements will only take effect when enough network participants upgrade to the new version.
Obviously, the implementation of the OP_CAT soft fork is still in a very early stage. Less than four months have passed since the draft BIP was written. The BIP number has not yet been determined. It is still in the first stage of writing proposals and codes and the third stage. The second stage includes community discussion sessions involving developers and users.
What Bitcoin developers say
Let us first pay special attention to the discussion of OP_CAT by Bitcoin developers in recent years.
Although the OP_CAT opcode has been removed, OP_CATs potential utility in facilitating advanced contracts and enhancing the Bitcoin scripting language has been discussed repeatedly among developers. For example, its ability to concatenate stack values is considered a hindrance to the development of some Bitcoin protocols, such as TumbleBit, whose transaction sizes could be significantly reduced if OP_CAT was supported.
After collecting Optech newsletters and various related content, the following is a chronological collection of discussions about the OP_CAT opcode by some Bitcoin developers.
2019
Ethan Heilman, one of the initiators of this OP_CAT Bitcoin Improvement Proposal (BIP) draft, in October 2019Just in the mailHe expressed that he understood why it was removed - because the situation faced by the script at that time was extremely severe, but he emphasized that OP_CAT as an opcode, its value cannot be ignored: Most protocols currently trying to build on Bitcoin have encountered One limitation: stack values cannot be concatenated. As a researcher, if I encounter this limitation, then it is likely hindering the progress of others. If I could wave a wand and re-enable one of the disabled opcodes, I OP_CAT will be selected. Of course, this will come with a condition: the size of each concatenated value must be limited to 64 bytes or less.
Regarding the discussion of OP_CAT, Andrew Poelstra is a person who can never be bypassed. He wrote an article on January 30, 2021 titled CAT and Schnorr Tricks IThe article caused a discussion about OP_CAT. Andrew Poelstra is the Research Director of Blockstream and a senior Bitcoin cryptography script writing developer. His influence in the industry is self-evident.
In the article, Andrew Poelstra introduces: OP_CAT helps to combine two elements in the stack and push the combined result back to the stack. This function can be used to assemble multiple small elements into one large element, or to assemble a large element. Elements are decomposed into multiple small elements. CHECKSIGFROMSTACK (CSFS) is an opcode that has never been seen in Bitcoin. It allows users to perform signature verification on arbitrary data, unlike the CHECKSIG opcode that can only verify transaction signatures.”
More importantly, he points out that using OP_CAT in conjunction with CHECKSIGFROMSTACK provides a clever method of transaction introspection.
Note: Transaction introspection refers to the ability to inspect and analyze various components of the transaction itself within Bitcoin scripts. Simply put, it allows the script to understand and process the details of the transaction it is processing, such as checking the output content, amount or specific signature of the transaction. This way, the script can respond more intelligently and granularly based on the specifics of the transaction.
This way the user provides data for the entire transaction on the stack, and the script uses OP_CAT to package this data into a single item, hash it, and pass it to CHECKSIGFROMSTACK to verify the signature on the data. Next, it passes the same signature and key to CHECKSIG. If both verifications pass, it means that the transaction data provided by the user is indeed real transaction data. This way, the script can directly leverage this data to perform any checks required by the contract.
The influence of Andrew Poelstra, and the conception of this article, brought to the attention of Bitcoin developers, and meetings that week, a discussion on how this combination of opcodes and small changes to the scripting language could improve upon activating taproot There was much discussion about contract flexibility.
distanceCAT and Schnorr Tricks IAbout two weeks after the release of CAT and Schnorr Tricks II”, in which Andrew Poelstra recounts more details and his thoughts:
In May 2019, Bitcoin developer Jeremy Rubin proposed Bitcoins CHECKOUTPUTSHASHVERIFY opcode with the purpose of implementing a basic and limited smart contract, avoiding the technical and social risks in previous smart contract designs. This opcode was subsequently replaced by SECURETHEBAG, and then by CHECKTEMPLATEVERIFY, which officially became the Bitcoin Improvement Proposal BIP 0119 in January 2020.
Meanwhile, Russell OConnor proposed adding the CHECKSIGFROMSTACK and OP_CAT opcodes directly to Bitcoin to support smart contracts that are not subject to the Rubin proposal. Although the proposal met with some opposition, and discussion eventually waned, mainly due to the inefficiency of CAT+CHECKSIG type smart contracts and the long-standing negative perception of comprehensive universal smart contracts.
Andrew Poelstra was also initially reluctant to support so-called smart contract functionality in Bitcoin. However, in the fall of 2019, a personal conversation with Ethan Heilman changed his mind. Ethan Heilman pointed out that despite concerns, smart contracts considered harmful can actually be implemented through CHECKMULTISIG, and such contracts are not actually accepted by wallets and users due to lack of recognition and usability. To prove this, Ethan Heilman launched a challenge on social media to encourage people to come up with viable dark smart contracts, but no one has succeeded so far.
So Andrew Poelstra turned to thinking that everyones fear of smart contracts might be exaggerated. The article also proposes that, even if there are concerns, smart contracts are inevitable in the development of Bitcoin, and encourages continued exploration of the possibility of creating smart contracts using the non-specific opcode OP_CAT.
2021
Next is an article by Jeremy Rubin on July 6, 2021, which explains OP_CAT from the perspective of Bitcoin quantum security. Jeremy Rubin is not only a Bitcoin developer, but also the founder of Judica, a Bitcoin RD organization focused on developing Sapio, Bitcoin’s smart contract programming language.
existmailandblog post, Jeremy Rubin discusses how to leverage OP_CAT opcodes and Lamport signatures for quantum verification of Bitcoin. The author first reviewed a previous blog post describing how to register a 5-byte value using Bitcoin script arithmetic and Lamport signatures. Although this method is neat, it has its limitations. Jeremy Rubin came up with an idea: What if we could sign longer messages? Especially if we can sign up to 20 bytes, we can sign a HASH 160 digest that may be quantum safe.
Jeremy Rubins article further explores the implications of HASH 160 digest signatures and explains the ability of a quantum computer to break ECDSA only to reveal the private key without changing the actual signature content. To this end, the author consulted cryptologist Madars Virza and got a positive answer.
Jeremy Rubin points out that if we require ECDSA signatures to be signed using a quantum-proof signature algorithm, we can have quantum-proof Bitcoin. The 5-byte signature scheme discussed before is actually a quantum-safe Lamport signature. Unfortunately, this method requires at least 20 consecutive bytes.
Therefore, Jeremy Rubin proposed that something similar to OP_CAT is needed. The article explains that OP_CAT cannot soft-fork directly to Segwit v 0 because it will modify the stack. So, to simplify, the author shows how to use a new opcode, OP_SUBSTRINGEQUALVERIFY, which checks whether a part of a string is equal via validation semantics.
November 5, 2021 atAtlanta Bitcoin ConferenceSpeakers Jeremy Rubin and Andrew Poelstra discussed the proposal to re-enable the opcode OP_CAT, arguing that OP_CAT is important in the context of Bitcoin and highlighting its potential, especially in quantum security and production. Complex smart contracts. For example, combining CAT and Schnorr signature verification opcodes, non-recursive smart contracts can theoretically be implemented. This smart contract is able to put the SHA 2 hash of transaction data directly onto the stack. By doing so, restrictions can be imposed to some extent on various parts of the transaction.
The discussion also mentioned that if CAT is reintroduced, it may make Bitcoin more complex in some aspects and introduce new features and possibilities. Restarting OP_CAT requires careful consideration to avoid problems that have occurred in the past, such as memory explosion issues.
2022
On May 18, 2022Bitcoin developer mailing list, during the discussion about the reintroduction of the OP_CAT opcode that was removed from Bitcoin in 2010, developer ZmnSCPxj proposed that to implement unavoidable recursive smart contracts, OP_CAT needs to be combined with proposed opcodes such as OP_TX, OP_CHECKSIGFROMSTACK (CSFS), etc. . Recursive smart contracts utilize Bitcoin consensus rules to ensure that all Bitcoins received into a contract can only be spent on the same contract.
Recursive smart contracts rely on transaction introspection technology, where an opcode can analyze the part of the transaction that executed the opcode. Existing opcodes provide limited introspection. In order to create a recursive smart contract, you need to ensure that the previous output and the next output are the same. Therefore, either the previous output, or the next output, or both must be dynamically constructed from their constituent elements, which is why CAT or similar structures are needed to implement recursive smart contracts.
Nadav Ivgi pointed out that CAT is still needed to solve the hashing problem when creating recursive smart contracts, but this means that features such as CTV and APO that focus on output introspection can also be combined with CAT to create recursive smart contracts. Ivgi believes that when combined with taproots functionality, validating the previous output with the next output can make smart contract scripts easier to write, and provides links to two recursive smart contract examples.
ZmnSCPxj agreed with Ivgi’s analysis and reiterated his concerns about the risks of enabling recursive smart contracts on Bitcoin, although he also pointed out in a follow-up post that recursive smart contracts may be safe because they are not actually Turing complete. Russell OConnor cited Andrew Poelstras article, describing how CAT itself, combined with existing Bitcoin functionality, is sufficient to create non-recursive smart contracts, and in theory, if added back to Bitcoin, it may also be able to create recursion on its own Smart contracts.
2023
In January, Anthony Towns launched Bitcoin Inquisition, a software fork of Bitcoin Core designed to run on the default signet and used to test proposed soft forks and other major protocol changes. As of late 2023, Bitcoin Inquisition has supported multiple proposals. In addition, PRs (pull requests) aimed at OP_CAT, OP_VAULT, and limiting 64-byte transactions have been submitted to its code base, which is expected to further expand this test platform. Function.
August 23, 2023, atOn the Lightning-Dev mailing list, Thomas Voegtlin proposed an idea for fraud proofs of expired backup states. Voegtlin pointed out that if the OP_CHECKSIGFROMSTACK (CSFS) and OP_CAT opcodes were added to Bitcoin in the form of a soft fork, it would be possible to use this fraud proof on the chain. The proposal triggered a lot of discussion, and Peter Todd pointed out that the basic mechanism is universal and not limited to LN, and may be useful in various protocols, but he also proposed a simpler mechanism, which will not be discussed here.
By October, Rusty Russell was working on a general-purpose smart contract with minimal changes to the Bitcoin scripting language. At the same time and very importantly, Ethan Heilman and Armin Sabouri jointly released aDraft BIP, proposed adding the OP_CAT opcode, which is used to concatenate two elements on the stack. Discussions on these two issues continued into November.
2024
Come January 2024, Quantum Cats has indeed succeeded in taking the discussion about OP_CAT’s BIP and Bitcoin progress to the next level.
In interactions with the community, Bitcoin Core developersAva ChowZeng said: I dont think CTV is a rough consensus. I think other more general smart contract proposals are actually closer, such as txhash or CAT. However, I have not followed the discussion closely.
Sorted by the number of submissions, as of now,Ava Chow（@achow 101 )existBitcoin Core code contributor rankingRanked 5th with 1292 code submissions, he is also one of the few people who has the right to merge the Bitcoin code. Therefore, her influence in the development community is also very large.
Im not suggesting that we activate OP_CAT. I support OP_CAT because its the opcode most likely to reach consensus. If you dont know whats going on with OP_CAT, Ive summarized the situation in this picture. So, Taproot Wizards LianchuangEric Wall （@ercwl) said so.
but,Ava ChowThere seems to be no absolute approval of OP_CATs implementation: As I have said, I dont think any smart contract proposal comes close to or reaches rough consensus. I dont think we should try to activate any of them.
Ten lines of code allow Bitcoin to implement smart contracts
Just like the joint creation of Taproot WizardEric Wall （@ercwl) said: “People don’t realize this, but OP_CAT is actually one of the building blocks of zkrollup on Bitcoin.”
The reintroduction of OP_CAT provides Bitcoin with a powerful tool that can support projects like BitVM. The concept recently introduced by BitVM - verifying arbitrary calculations on Bitcoin will become simpler and more efficient because of OP_CAT. The Bitcoin ecosystem is capable of creating more versatile and expressive smart contracts.
Related Reading:To compute anything on Bitcoin, what do senior developers think of BitVM?》
Through OP_CAT, it is possible to implement so-called smart contracts, which set pre-specified conditions for specific Bitcoin outputs. This not only opens the door to new scaling methods, such as Blockstream’s Ark, but also supports many other innovative methods that rely on smart contracts. Furthermore, this signals that Bitcoin is not just a payment network, but a versatile and scalable computing platform.
Although Taproot Wizard co-founder Eric Wall is excited about the concept behind BitVM, he believes that the proposal may be a technical dead end for Bitcoin due to its huge overhead and long implementation cycle. He worries that BitVM may distract the community and hinder real development. Nonetheless, the introduction of BitVM still shows the active spirit of exploration and innovation in the field of blockchain technology and smart contracts.
In fact, the Taproot Wizard project team itself is also working on implementing a second-layer solution on Bitcoin. In a previous Space, they also stated that the US$7.5 million in financing completed will be used to study Bitcoin expansion solutions. .
Therefore, the soft fork of OP_CAT will also be an important step for them. Eric Wall, a former board member of the StarkNet Foundation, has a huge interest in building decentralized finance on top of a permissionless settlement layer, so when Ethereum began to emerge in 2019, he was naturally attracted to Ethereum. Attracted by the DeFi field.
When it became apparent in 2019 that Ethereum and other blockchains could scale through the use of zk-Rollups or optimistic fraud proofs, Bitcoins exploration of DeFi had been almost entirely abandoned. With research on issues such as the feasibility of zk-Rollup expansion being applied to Bitcoin, Wall turned to supporting DeFi on Ethereum. But ultimately, hes trying to bring this system and these technical advantages to Bitcoin.
In addition, inIn the discussion thread about OP_CAT in the bitcointalk forum, Carter Feldman (@cmpeq), founder of the QED project, was asked how he planned to utilize this opcode in Bitcoin scripts and whether he had calculated the average number of bytes of the witness stack and the fees it might incur.
Carter Feldman acknowledged that this might be a bit expensive, but explained that Merkel proofs are primarily used in his project to build a trustless locking script or peg system as part of the second layer of zk on Bitcoin. . This system is designed to prove that a certain amount of Bitcoin can be withdrawn to a specific address given the root of the withdrawal tree (a public input as a zero-knowledge proof).
To address the cost issue, he mentioned this would be a last resort. He envisioned that ordinary users could buy wrapped BTC on the second layer by letting the seller of wrapped BTC lock their tokens on L2 for a period of time, during which time the buyer would have to prove that they had committed to Bitcoin L1. Seller pays. They know they can always exchange their Bitcoins back trustlessly if they wish. At the same time, several large liquidity providers will become the main body that actually exchanges between wBTC and BTC, and may charge small fees to smaller users who want to buy wBTC from them or bridge it back to Bitcoin.
So in general, OP_CATs BIP proposal can help build smart contracts on Bitcoin with only 13 lines of code, but as for the specific details of each project, there will still be a lot of discussions and attempts. plan.
Meme culture momentum building technology advancement
TaprootWizards team member Rijndael (@rot 13 maxi) shared on social media the various complex mechanisms they use to create their artwork. To achieve this, they rely on a variety of techniques, including ordinal recursion, presigned transactions, symmetric cryptography, and client load management. In the process of creating the art, they specifically chose to use pre-signed transactions to perform the operation, showing how to pre-submit the hash of the transaction using smart contracts such as OP_CAT or CTV.
But Armin Sabouri made an ironic comment about this: The code and technical effort invested in creating an evolving NFT collection may be 100 times the amount of work required to re-enable an opcode.
OP_CAT is considered a simple and easy-to-understand opcode, and some believe it can make Bitcoin quantum safe by signing ECDSA signatures. This view was supported by some and inspired Taproot Wizard to launch Quantum Cats NFT promotions to raise awareness of OP_CAT through these activities.
However, OP_CAT is not the only one who uses meme culture to build momentum for technological advancement.
Inspired by Quantum Cats and its selling price of 0.1 BTC, and perhaps partly dissatisfied with its high selling price, the OP_CTV community also launched a sandwich meme called #rubinsreubens to promote OP_CTV’s technology.
This sandwich meme started as a humorous response to Quantum Cat and its memes. However, its actually very effective because, like CTV, it adds hierarchy and you can make as many layers on the sammich as you want.
This sandwich meme has caught the attention of many people. Memes are fun and can be used to show support for something, but its also important to understand the meaning behind them. The purpose of #rubinsreubens is to increase understanding of op_ctv, lnhance as well as new BTC opcodes and smart contract enabled soft fork proposals.
Potential reasons for OP_CAT failure
Coming back to OP_CAT, one might object to the introduction of a feature like OP_CAT for a number of reasons. First, adding new opcodes or features such as OP_CAT may increase the complexity of Bitcoin, making it more difficult to understand and use safely, increasing risks. Secondly, security issues when introducing new features cannot be ignored. Features that have not been fully tested may contain vulnerabilities and harm the overall security of Bitcoin. In addition, if the upgrade of the soft fork is not adopted by all nodes, it may cause the network to split, causing different versions of the Bitcoin network to coexist, making consensus more complicated.
New features may introduce compatibility issues, especially if they do not support older nodes, which may exclude some nodes from the network and have a negative impact on the Bitcoin ecosystem. Especially for those users who do not upgrade, they may find themselves unable to continue participating in the network. Additionally, some may view the introduction of new features as a hasty decision that does not prioritize addressing pressing issues within the Bitcoin Core protocol. Hasty changes can introduce unnecessary risk and instability.
In addition to security and risk considerations, the two biggest reasons why OP_CAT will fail are: the Bitcoin community’s fear of smart contracts and the lack of “legitimacy” of Bitcoin smart contracts.
Fear of smart contracts
Fear of Bitcoin smart contracts may be another significant obstacle to achieving OP_CAT. As a core component of blockchain technology, smart contracts play a vital role in many blockchain projects, especially on platforms such as Ethereum.
However, acceptance of smart contracts within the Bitcoin community is relatively low, in part due to concerns about the risks and challenges they can pose. Smart contracts may impact Bitcoin’s core values such as peer-to-peer, decentralization, and security. The Bitcoin community takes maintaining these core values very seriously, and any changes deemed to threaten these values may be met with opposition.
A major concern with smart contracts is that they may add complexity and security risks to the entire network. Smart contracts often involve complex logic and code, and any small mistakes or loopholes can lead to serious security issues and even large-scale financial losses, as has happened in some blockchain projects in the past. Additionally, the introduction of smart contracts may make the entire system more difficult to understand and audit, thereby increasing the likelihood of errors.
In addition, the Bitcoin community has always placed great emphasis on maintaining the stability and security of the network. Bitcoins design philosophy tends to be simple and conservative, prioritizing the security and decentralization of the network. Therefore, any significant changes that may pose a threat to network stability will be subject to rigorous scrutiny and extensive debate. The introduction of OP_CAT and smart contracts, while bringing new functionality and possibilities to Bitcoin, may also be seen as running counter to Bitcoin’s original vision and design philosophy.
Was Satoshi Nakamoto wrong?
Restoring the OP_CAT opcode sparked deep discussion in the community, in part because it touched on a sensitive topic: Does this mean Satoshi Nakamoto was wrong?
As the founder of Bitcoin, Satoshi Nakamoto’s decisions and original design are regarded as bible by many people, and his original vision is considered the core guideline for the development of Bitcoin. Therefore, any kind of challenge or modification of Satoshi Nakamoto’s decision-making may be seen as disrespecting his legacy or a departure from Bitcoin’s core principles. After all, in the blockchain industry, legitimacy is always an unavoidable topic.
Therefore, the proposal to reinstate OP_CAT also touches on a broader question: should Bitcoin be a static entity, or should it adapt to changing technological environments and user needs?
However, the technological field is always progressing and changing, and Bitcoin, as a technological innovation, cannot completely escape from this law. Apparently, the Taproot Wizard team that supports the restoration of OP_CAT thinks so. After all, they had intentionally designed the largest Bitcoin block ever, just under Bitcoin’s 4 MB limit, to release NFT Taproot Wizards.
Taproot Wizard founder Udi Wertheimer said that he understands that many people believe that Bitcoin should not change. He believes that changes in Bitcoin should be slow, cautious, and thoughtful. He believes Bitcoin is too young to be fully solidified yet, noting that the governance process is broken to some extent. While the technology community generally agrees that there will be more upgrades to Bitcoin, it’s really hard to pinpoint exactly which upgrades there will be. Still, Wertheimer stressed that change is necessary because current Bitcoin cannot serve billions of people.
Of course, such changes are also accompanied by risks and challenges, such as security issues, network fragmentation risks, compatibility issues, etc., which need to be carefully considered and resolved.
It is foreseeable that, in order to ensure that the proposed improvements are safe and effective, deploying OP_CAT in a test network environment is a crucial step, allowing developers to discover and solve problems without affecting the main network.
At the same time, if we want to truly realize the restart of OP_CAT, the entire process will last for a long time, even measured in years, because it involves many considerations and balances, including technical details, community consensus, and comparison. Bitcoin network security and stability considerations, and most importantly, broad community support and recognition.
