13 lines of code help Bitcoin achieve smart contracts? Understanding the OP_CAT soft fork

Author: Jaleel, BlockBeats

In the Bitcoin codebase, an opcode that was once deleted by Satoshi Nakamoto and long buried in history, "OP_CAT," may be "revived."

The Bitcoin NFT project Taproot Wizards has launched a new series of NFTs called Quantum Cats, sparking heated discussions in the community around the OPCAT opcode. Although the name OPCAT does not refer to the "cats" we are familiar with, Taproot Wizards has used the image of cats to release a new NFT named Quantum Cats, leveraging meme culture to promote OP_CAT.

OPCAT, an opcode that was once removed from the Bitcoin scripting language by Satoshi Nakamoto, is now being discussed again. Some Bitcoin developers want to "revive" this opcode and lay the groundwork for smart contracts on Bitcoin through a soft fork of 13 lines of code. With the push from Bitcoin developers and the meme image of cats, the popularity and discussion surrounding OPCAT have reached new heights.

"Reviving" the Opcode Deleted by Satoshi Nakamoto

Opcodes, also known as instructions or functions, are the basic building blocks of the Bitcoin scripting language. Historically, some opcodes were removed from early versions of Bitcoin due to concerns about potential vulnerabilities in client implementations, and OP_CAT was one of them.

Initially, OPCAT was part of the official Bitcoin command set, allowing for string concatenation operations to combine two elements into one. However, serious vulnerabilities found in opcodes like OPLSHIFT could cause any Bitcoin node to crash, and there were concerns that the OP_CAT opcode could lead to exponential growth of stack elements, potentially causing memory usage to increase 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 "disabled," but this term is not accurate, as they were completely deleted from the protocol, making it impossible for anyone using Bitcoin to utilize these opcodes.

In October 2023, Bitcoin Core developers Ethan Heilman and Armin Sabouri, Chief Software Engineer at Botanix Labs, jointly released a draft Bitcoin Improvement Proposal (BIP) titled "OP_CAT," bringing this discussion to a new level.

This draft, consisting of just 13 concise lines of code, carries a clear and intuitive functional nature, defining a new tapscript opcode that allows for concatenating two values on the stack. The implementation of this code is clearly inspired by the originally deleted OP_CAT.

The Conditions for "Revival" Have Been Met

As for why developers wish to restore an opcode that was deleted by Satoshi Nakamoto, the motivation section of this BIP draft provides some detailed explanations: it is primarily based on considerations of memory usage. OPCAT could cause the memory usage of script construction to grow exponentially relative to the size of the script itself. Specifically, a simple script that pushes a 1-byte value onto the stack, then uses the OPDUP opcode to copy it, and subsequently concatenates it 40 times with OP_CAT, could lead to stack values ballooning to over 1TB.

However, with the passage of time and advancements in technology, this issue is no longer a barrier. Under the architecture of tapscript, a clear rule has been established that strictly limits the size of stack elements to 520 bytes. This change effectively addresses the memory usage issues that OP_CAT could cause, making its "revival" and integration possible.

Thus, it is evident that OP_CAT is being discussed again and considered for restoration mainly because of its potential value in constructing more complex and powerful scripts. Additionally, several reasons and changes have met the conditions for its "revival," including:

1. Demand for Advanced Smart Contracts and Protocols: With the development of the Bitcoin ecosystem, the demand for more advanced and complex smart contracts and protocols has increased. OP_CAT enhances the expressiveness and functionality 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 features like tree signatures, post-quantum Lamport signatures, non-repudiation contracts, vaults, and more.

2. Successful Cases on Other Chains: Some Bitcoin forks, such as Bitcoin Cash and the Liquid sidechain, have re-enabled OPCAT and used it to implement token creation and management, payment channels, and methods for embedding and retrieving data on the blockchain. This indicates that OPCAT can be used safely and effectively in appropriate environments and under certain constraints.

3. Exploration of Quantum Security: Research has suggested that if operations like OP_CAT can be used in conjunction with technologies like Lamport signatures, quantum-secure Bitcoin transactions and protocols can be constructed. This exploration has potential value for enhancing the future security of the Bitcoin system.

4. Community and Technological Development: The ongoing development of the Bitcoin community and technology has prompted a reconsideration and reevaluation of previous decisions. With a deeper understanding of the Bitcoin protocol and the emergence of new technologies, features previously deemed problematic or unsuitable may find safe and useful applications in new contexts.

Soft Forks Are Not Easy

On a technical level, few other Bitcoin proposals are as easy to interpret and understand as OPCAT. However, the OPCAT opcode will be activated through a soft fork that redefines the OP_SUCCESS126 opcode, which is clearly not an easy task.

Looking back, the last soft fork in Bitcoin occurred three years ago when Taproot was activated, paving the way for the birth of Ordinals.

The Bitcoin community places a high value on consensus and transparency, and any significant code changes will be widely discussed and reviewed within the community, including soft forks. For a piece of code to be merged into the Bitcoin codebase, it must go through a strict and detailed process that ensures the quality of the proposal and community consensus. The main steps of this process are as follows:

1. Writing the 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 assessments, and any potential issues or challenges.

2. Community Discussion: Once 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 crucial for ensuring the feasibility of the proposal and gathering feedback.

3. Modifications and Improvements: Based on community feedback, the author of the code may need to modify and improve the proposal.

4. Voting and Reaching Consensus: For some significant improvements (especially those involving changes to the Bitcoin protocol itself), a certain level of consensus among community members is required. This often involves support from miners, who need to signal their support for the proposal by including specific signals 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 ensures the quality and security of the code.

6. Merging into the Codebase: After passing the review, the code will be merged into the official Bitcoin codebase.

7. Deployment and Activation: The new code needs to be deployed by miners and node operators to their systems. For protocol-level changes, there is usually an activation threshold, and the improvement will only take effect when a sufficient number of network participants upgrade to the new version.

Clearly, the implementation of the OP_CAT soft fork is still in a very early stage, having been less than four months since the BIP draft was written. Currently, the BIP number has not yet been determined, and it is still in the first phase of writing proposals and code, as well as the second phase of community discussions that include developers and users.

What Bitcoin Developers Are Saying

Let’s take a closer look at the discussions among Bitcoin developers regarding OP_CAT in recent years.

Although the OPCAT opcode was removed, its potential utility in facilitating advanced contracts and enhancing the Bitcoin scripting language has been repeatedly discussed among developers. For example, its ability to connect stack values is seen as a barrier to the development of certain Bitcoin protocols, such as TumbleBit, where supporting OPCAT could significantly reduce transaction sizes.

After gathering information from the Optech newsletter and various related content, the following is a chronological compilation of discussions by Bitcoin developers regarding the OP_CAT opcode.

2019

One of the initiators of the "OPCAT" Bitcoin Improvement Proposal (BIP) draft, Ethan Heilman, expressed in an email in October 2019 his understanding of why it was removed—because the scripting situation at the time was extremely severe. However, he emphasized that the value of OPCAT as an opcode should not be overlooked: "Most protocols that want to build on Bitcoin currently face a limitation: stack values cannot be concatenated. As a researcher, if I encounter this limitation, it is likely hindering others' progress as well. If I could wave a magic wand to re-enable one of the disabled opcodes, I would choose OP_CAT. Of course, this would come with a condition: each concatenated value must be limited to 64 bytes or less."

When discussing OPCAT, Andrew Poelstra is an unavoidable figure. He wrote an article titled "CAT and Schnorr Tricks I" on January 30, 2021, which sparked a wave of discussions about OPCAT. Andrew Poelstra is the Director of Research at Blockstream and a seasoned Bitcoin cryptographic script developer, whose influence in the industry is undeniable.

In the article, Andrew Poelstra introduced: "OP_CAT helps combine two elements in the stack and pushes the merged result back onto the stack. This function can be used to assemble multiple small elements into a larger one or to decompose a large element into several smaller ones. CHECKSIGFROMSTACK (CSFS) is an opcode that has never existed in Bitcoin, allowing users to verify signatures on arbitrary data, unlike the CHECKSIG opcode, which can only verify transaction signatures."

More importantly, he pointed out that combining OP_CAT with CHECKSIGFROMSTACK could provide a clever method for transaction introspection.

Note: Transaction introspection refers to the ability to inspect and analyze the various components of a transaction within Bitcoin scripts. In simple terms, it allows the script to "understand" and process the details of the transaction it is handling, such as checking the output content, amounts, or specific signatures. This way, the script can make more intelligent and nuanced responses based on the specifics of the transaction.

Thus, users provide the entire transaction data on the stack, and the script uses OP_CAT to package this data into a single item, hashes it, and then passes it to CHECKSIGFROMSTACK to verify the signature on the data. It then passes the same signature and key to CHECKSIG. If both verifications pass, it indicates that the transaction data provided by the user is indeed genuine. In this way, the script can directly use this data to perform any checks required by the contract.

Andrew Poelstra's influence and the conception of this article caught the attention of Bitcoin developers, leading to many discussions in that week's meeting about the combination of these opcodes and how minor changes to the scripting language after the activation of Taproot could enhance contract flexibility.

About two weeks after the publication of "CAT and Schnorr Tricks I," Andrew Poelstra published a second article, "CAT and Schnorr Tricks II," in which he elaborated on more details and his thoughts:

In May 2019, Bitcoin developer Jeremy Rubin proposed the CHECKOUTPUTSHASHVERIFY opcode for Bitcoin, aiming to implement a basic and limited smart contract that avoids the technical and social risks present in previous smart contract designs. This opcode was later replaced by SECURETHEBAG, and subsequently by CHECKTEMPLATEVERIFY, which officially became Bitcoin Improvement Proposal BIP 0119 in January 2020.

At the same time, Russell O'Connor suggested directly adding CHECKSIGFROMSTACK and OP_CAT opcodes to Bitcoin to support smart contracts not constrained by Rubin's proposal. Although this proposal faced some opposition and discussions gradually diminished, mainly due to the inefficiency of CAT+CHECKSIG type smart contracts and the long-standing negative perception of fully general smart contracts.

Initially, Andrew Poelstra was also reluctant to support the so-called Bitcoin smart contract functionality. However, a private conversation with Ethan Heilman in the fall of 2019 changed his mind. Ethan Heilman pointed out that despite concerns, harmful smart contracts could actually be implemented through CHECKMULTISIG, and these types of contracts were not accepted by wallets and users due to a lack of recognition and usability. To prove this point, Ethan Heilman challenged people on social media to propose viable "dark" smart contracts, but no one has succeeded to date.

Thus, Andrew Poelstra began to think that the fear of smart contracts might be exaggerated. The article also suggested that even with concerns, smart contracts are inevitable in the development of Bitcoin and encouraged continued exploration of the possibility of creating smart contracts using the non-specialized opcode OP_CAT.

2021

Next, Jeremy Rubin wrote an article on July 6, 2021, discussing OP_CAT from the perspective of Bitcoin's quantum security. Jeremy Rubin is not only a Bitcoin developer but also the founder of Judica, a Bitcoin research organization focused on developing the smart contract programming language Sapio.

In emails and blog posts, Jeremy Rubin discussed how to use the OP_CAT opcode and Lamport signatures for quantum verification of Bitcoin. The author first reviewed a previous blog post that described 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 proposed an idea: what if we could sign longer information? Specifically, if we could sign up to 20 bytes, we could sign a potentially quantum-secure HASH160 digest.

In the article, Jeremy Rubin further explored the implications of signing HASH160 digests and explained that even if quantum computers break ECDSA, they would only leak the private key without altering the actual signature content. To this end, the author consulted cryptographer Madars Virza and received a positive response.

Jeremy Rubin pointed out that if we require ECDSA signatures to be signed using quantum-proof signature algorithms, we could have quantum-proof Bitcoin. The previously discussed 5-byte signature scheme is, in fact, a quantum-secure Lamport signature. However, unfortunately, this method requires at least 20 consecutive bytes.

Therefore, Jeremy Rubin proposed the need for some operation similar to OPCAT. The article explained that OPCAT could not be directly soft-forked into Segwit v0 because it would modify the stack. Thus, to simplify, the author demonstrated how to use a new opcode, OP_SUBSTRINGEQUALVERIFY, which checks whether a certain part of a string is equal through verification semantics.

On November 5, 2021, at the Atlanta Bitcoin Conference, Jeremy Rubin and Andrew Poelstra, as speakers, discussed the proposal to re-enable the OP_CAT opcode. They emphasized its importance in the context of Bitcoin and highlighted its potential, especially in quantum security and creating complex smart contracts. For example, combining CAT and Schnorr signature verification opcodes could theoretically enable non-recursive smart contracts. These smart contracts could directly place the SHA2 hash of transaction data onto the stack. By doing so, certain restrictions could be applied to various parts of the transaction.

The discussion also mentioned that reintroducing CAT could complicate Bitcoin in some ways while also introducing new functionalities and possibilities. Restarting OP_CAT requires careful consideration to avoid past issues, such as memory explosion problems.

2022

On May 18, 2022, in the Bitcoin developer mailing list, during discussions about reintroducing the OPCAT opcode removed from Bitcoin in 2010, developer ZmnSCPxj suggested that to achieve inevitable recursive smart contracts, OPCAT would need to be combined with proposed opcodes like OPTX and OPCHECKSIGFROMSTACK (CSFS). Recursive smart contracts leverage Bitcoin consensus rules to ensure that all Bitcoin received by the contract can only be spent on the same contract.

Recursive smart contracts rely on transaction introspection techniques, where opcodes can analyze a portion of the transaction executing that opcode. Existing opcodes provide limited introspection. To create recursive smart contracts, it is necessary to ensure that the previous output and the next output are the same. Therefore, either the previous output, 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 when creating recursive smart contracts, CAT is still needed to solve hash issues, but this means that focusing on output introspection features like CTV and APO can also be combined with CAT to create recursive smart contracts. Ivgi believes that when combined with the functionalities of taproot, verifying the previous output through the next output can make smart contract scripts easier to write and provided links to two examples of recursive smart contracts.

ZmnSCPxj agreed with Ivgi's analysis and reiterated his concerns about the risks of enabling recursive smart contracts on Bitcoin, although he also noted in subsequent posts that recursive smart contracts might be safe because they are not Turing complete. Russell O'Connor cited Andrew Poelstra's article, describing how CAT itself could combine with existing Bitcoin functionalities to create non-recursive smart contracts, and theoretically, if re-added to Bitcoin, it could also create recursive smart contracts on its own.

2023

In January, Anthony Towns launched Bitcoin Inquisition, a software that replicates Bitcoin Core, designed to run on the default signet for testing proposed soft forks and other significant protocol changes. By the end of 2023, Bitcoin Inquisition had already supported multiple proposals, and pull requests (PRs) aimed at OPCAT, OPVAULT, and limiting 64-byte transactions had been submitted to its codebase, which is expected to further expand the functionality of this testing platform.

On August 23, 2023, in the Lightning-Dev mailing list, Thomas Voegtlin proposed an idea for fraud proofs of expired backup states. Voegtlin pointed out that if OPCHECKSIGFROMSTACK (CSFS) and OPCAT opcodes were added to Bitcoin in a soft fork, it would be possible to use such fraud proofs on-chain. This proposal sparked extensive discussion, with Peter Todd noting that the basic mechanism is universal and not limited to LN, potentially useful in various protocols, although he also proposed a simpler mechanism that will not be discussed here.

By October, Rusty Russell conducted research on general smart contracts for the Bitcoin scripting language. Meanwhile, it is very important that Ethan Heilman and Armin Sabouri jointly released a BIP draft proposing the addition of the OP_CAT opcode, which is used to concatenate two elements on the stack. Discussions on these two topics continued into November.

2024

As of January 2024, Quantum Cats has indeed successfully elevated the discussion about the OP_CAT BIP and the Bitcoin process to a new level.

In interactions with the community, Bitcoin Core developer Ava Chow stated, "I don't think CTV is rough consensus. I think actually other more general smart contract proposals are closer, like txhash or CAT. However, I haven't been closely following the discussions."

In terms of submission counts, Ava Chow (@achow101) ranks 5th among Bitcoin Core code contributors, with 1,292 code submissions, and is one of the few with merge rights to Bitcoin code. Therefore, her influence in the developer community is also significant.

"I'm not suggesting we activate OPCAT. I support OPCAT because it is an opcode that is very likely to reach consensus. If you don't understand the situation with OP_CAT, I've summarized it in this image," said Eric Wall (@ercwl), co-founder of Taproot Wizard.

However, Ava Chow seems to express no absolute agreement on the implementation of OP_CAT: "As I've said before, I don't think any smart contract proposal is close to or has reached rough consensus. I think we shouldn't try to activate any of them."

Ten Lines of Code to Enable Smart Contracts on Bitcoin

As Eric Wall (@ercwl), co-founder of Taproot Wizard, stated, "People don't realize this, but OP_CAT is actually one of the building blocks for zkrollups on Bitcoin."

The reintroduction of OPCAT provides a powerful tool for Bitcoin, enabling projects like BitVM, which recently launched the concept of verifying arbitrary computations on Bitcoin, to become simpler and more efficient due to OPCAT. The Bitcoin ecosystem can create more general and expressive smart contracts.

With OP_CAT, so-called smart contracts can be implemented, setting predefined conditions for specific Bitcoin outputs. This not only opens the door for new scaling methods, such as Blockstream's Ark, but also supports many other innovative approaches that rely on smart contracts. Furthermore, this marks Bitcoin's evolution from merely a payment network to a multifunctional, scalable computing platform.

While Taproot Wizard co-founder Eric Wall is excited about the concept behind BitVM, he believes the proposal could be a "technical dead end" for Bitcoin due to its high overhead and long implementation cycle. He worries that BitVM might distract the community and hinder real progress. Nevertheless, the proposal of BitVM still indicates an active exploration and innovative spirit in the blockchain technology and smart contract field.

In fact, the Taproot Wizard project team is also working on implementing second-layer solutions on Bitcoin. In a previous Space, they stated that the completed $7.5 million funding would be used to research Bitcoin scaling solutions.

Thus, the OP_CAT soft fork will also be an important step for them. Eric Wall, who was once a board member of the StarkNet Foundation, has a great interest in building decentralized finance on a permissionless settlement layer. Therefore, when Ethereum emerged in 2019, he was naturally attracted to the DeFi space on Ethereum.

When it became clear in 2019 that Ethereum and other blockchains could scale using zk-Rollups or optimistic fraud proofs, Bitcoin's exploration in DeFi had almost been completely abandoned. With research questions like "the feasibility of zk-Rollup scaling applied to Bitcoin," Wall turned to support DeFi on Ethereum. Ultimately, he is trying to bring this system and these technological advantages to Bitcoin.

Additionally, in a discussion thread about OP_CAT on the Bitcointalk forum, Carter Feldman (@cmpeq), founder of the QED project, was asked how he plans to utilize this opcode in Bitcoin scripts and whether he has calculated the average byte size of the witness stack and the potential costs involved.

Carter Feldman acknowledged that this might be a bit expensive, but he explained that Merkle proofs in his project are primarily used to build a trustless locking script or hooking system as part of a zk second layer on Bitcoin. This system aims to prove that a certain amount of Bitcoin can be withdrawn to a specific address given a withdrawal tree root (as the public input of a zero-knowledge proof).

To address cost issues, he mentioned that this would be a means. He envisions that ordinary users can purchase wrapped BTC on the second layer by having sellers lock their tokens for a period of time, during which buyers must prove they have paid the seller on Bitcoin L1. They know that if they wish, they can always redeem their Bitcoin trustlessly. Meanwhile, several large liquidity providers will become the entities actually exchanging wBTC and BTC, potentially charging small fees to those small users who want to purchase wBTC or bridge it back to Bitcoin.

Overall, this BIP proposal for OP_CAT, consisting of just 13 lines of code, can help build smart contracts on Bitcoin. However, regarding the specific handling details for each project, there will still be a lot of discussions and attempts at solutions.

Meme Culture and Technical Promotion

Rijndael (@rot13maxi), a member of the Taproot Wizards team, shared on social media various complex mechanisms they used to create artwork. To achieve this goal, they relied on multiple technologies, including ordinal recursion, pre-signed transactions, symmetric cryptography, and client load management. In the process of artistic creation, they specifically chose to use pre-signed transactions to execute operations, demonstrating how to use OP_CAT or CTV to pre-submit the hash of transactions.

However, Armin Sabouri made a sarcastic comment: "In creating a constantly evolving NFT collection, the amount of code and technical effort invested may be 100 times the workload required to re-enable an opcode."

OPCAT is considered a simple and understandable opcode, and there are views that it could make Bitcoin "quantum secure" through ECDSA signatures. This view has garnered some support and inspired the Taproot Wizard to launch the Quantum Cats NFT campaign to raise awareness of OPCAT.

However, it is not just OP_CAT that is being promoted through meme culture for technical advancement.

Inspired by Quantum Cats and its price of 0.1 BTC, and perhaps carrying some dissatisfaction with its high price, the OPCTV community also launched a sandwich meme called #rubinsreubens to promote the technology of OPCTV.

This sandwich meme initially served as a humorous response to the quantum cats and their memes. However, it has proven to be very effective, as with CTV, it adds layers, allowing you to create any number of layers in the "sammich" as needed.

This sandwich meme has attracted the attention of many. Memes are fun and can be used to express support for something, but it is also important to understand the meaning behind them. The purpose of #rubinsreubens is to raise awareness of op_ctv, lnhance, and new BTC opcodes and soft fork proposals to enable smart contracts.

Potential Reasons for OP_CAT's Failure

Returning to OPCAT, there may be various reasons why people oppose introducing features like OPCAT. First, adding new opcodes or features like OP_CAT could increase the complexity of Bitcoin, making it harder to understand and use securely, thus increasing risks. Second, the security issues associated with introducing new features cannot be overlooked; inadequately tested features may harbor vulnerabilities that could compromise the overall security of Bitcoin. Additionally, if a soft fork upgrade is not adopted by all nodes, it could lead to network splits, resulting in the coexistence of different versions of the Bitcoin network, complicating consensus.

New features may also bring compatibility issues, especially if they do not support older nodes, potentially excluding some nodes from the network and negatively impacting the Bitcoin ecosystem. Particularly for users who do not upgrade, they may find themselves unable to continue participating in the network. Furthermore, some may view the introduction of new features as a hasty decision, without prioritizing the urgent issues within the core Bitcoin protocol. Hasty changes could introduce unnecessary risks and instability.

Besides considerations of security and risk, two major reasons for OP_CAT's potential failure are the Bitcoin community's fear of smart contracts and the lack of "orthodoxy" for Bitcoin smart contracts.

Fear of Smart Contracts

The fear of Bitcoin smart contracts may be another significant barrier to the realization of OP_CAT. Smart contracts play a crucial role as a core component of blockchain technology in many blockchain projects, especially on platforms like Ethereum.

However, within the Bitcoin community, the acceptance of smart contracts is relatively low, partly due to concerns about the risks and challenges they may bring. Smart contracts could impact Bitcoin's core values, such as peer-to-peer, decentralization, and security. The Bitcoin community places a high value on maintaining these core values, and any changes perceived as threatening these values may face opposition.

One major concern about smart contracts is that they could increase the complexity and security risks of the entire network. Smart contracts often involve complex logic and code, and any small error or vulnerability could lead to serious security issues, potentially resulting in large-scale financial losses, as has happened in some past blockchain projects. Additionally, the introduction of smart contracts could make the entire system harder to understand and audit, increasing the likelihood of errors.

Moreover, the Bitcoin community has always placed great importance on maintaining the stability and security of the network. The design philosophy of Bitcoin tends to favor simplicity and conservatism, prioritizing the security and decentralization of the network. Therefore, any significant changes that could threaten network stability will undergo rigorous scrutiny and extensive debate. The introduction of OP_CAT and smart contracts, while potentially bringing new functionalities and possibilities to Bitcoin, may also be seen as contrary to Bitcoin's original vision and design philosophy.

Was Satoshi Nakamoto "Wrong"?

The proposal to restore the OP_CAT opcode has sparked profound discussions within the community, partly because it touches on a sensitive issue: does this mean Satoshi Nakamoto was wrong?

As the founder of Bitcoin, Satoshi Nakamoto's decisions and original design are revered by many, and his original vision is considered the core guide for Bitcoin's development. Therefore, any challenge or modification to Satoshi's decisions may be viewed as disrespectful to his legacy or a departure from Bitcoin's core principles. After all, orthodoxy has always been an unavoidable topic in the blockchain industry.

Thus, the proposal to restore OP_CAT also raises a broader question: should Bitcoin be a static entity, or should it adapt to the ever-changing technological environment and user needs?

However, the technology field is always evolving and changing, and Bitcoin, as a technological innovation, cannot completely escape this rule. Clearly, the Taproot Wizard team, which supports the restoration of OP_CAT, thinks this way. After all, they intentionally designed one of the largest Bitcoin blocks in history, just below the 4MB limit of Bitcoin, to release the NFT Taproot Wizards.

Udi Wertheimer, founder of Taproot Wizard, stated that he understands many people believe Bitcoin should not change. He believes that changes to Bitcoin should be slow, cautious, and well-considered. He thinks Bitcoin is still too young to be fully solidified and points out that the governance process is somewhat broken. While the technical community generally agrees that Bitcoin will undergo more upgrades, it is indeed difficult to determine what specific upgrades will occur. Nevertheless, Wertheimer emphasizes that change is necessary, as the current Bitcoin cannot serve billions of people.

Of course, such changes come with risks and challenges, such as security issues, network split risks, compatibility issues, etc., all of which need to be carefully considered and addressed.

It is foreseeable that to ensure the proposed improvements are safe and effective, deploying OP_CAT in a test network environment will be a crucial step, allowing developers to discover and resolve issues without affecting the main network.

At the same time, the actual "reboot" of OP_CAT will take a considerable amount of time, potentially measured in years, as it involves multiple considerations and balances, including technical details, community consensus, and considerations for the security and stability of the Bitcoin network, as well as, very importantly, obtaining broad community support and recognition.