The article "Resurrection" was deleted by the Satoshi Nakamoto Operation Code?, read OP_CATSoft Fork

Original article by Jaleel, BlockBeats

In the Bitcoin codebase, an Operation Code “OP _CAT” that has been deleted by Satoshi Nakamoto and has been sealed by history for a long time may be “resurrected”.

Around the OP_CAT Operation Code, the Bitcoin Non-fungible Token project Taproot Wizards has launched a new series Non-fungible Token Quantum Cats. Although the term OP_CAT does not refer to the familiar “cat”, Taproot Wizard has used the image of a cat to release a new Non-fungible Token called Quantum Cats, using meme culture to help OP_CAT build momentum. Related reading: “Bitcoin “Quantum Cat”: Without Smart Contract, How to Achieve Dynamic Change of Inscriptions?”

OP_CAT, the Operation Code that was once removed by Satoshi Nakamoto from the Bitcoin scripting language, has now been brought back to the table for discussion, and some Bitcoin developers want to “resurrect” this Operation Code and pave the way for Bitcoin to implement Smart Contract through a soft fork of 13 lines of code. Driven by Bitcoin developers and created momentum in the image of a cat meme, the heat and discussion about OP_CAT has reached new heights.

The Operation Code of “Resurrection” deleted by Satoshi Nakamoto

Operation Codes, also known as instructions or functions, are the basic building blocks of the Bitcoin scripting language. Historically, some Operation Code have been removed from earlier versions of Bitcoin due to concerns about possible vulnerabilities in client implementations, OP_CAT Operation Code being one of them.

OP_CAT was originally part of Bitcoin’s official command set, allowing string joining, splicing two elements into one. However, because a critical vulnerability found in Operation Code such as OP_LSHIFT could cause any BitcoinNode to crash, there is a concern that OP_ CAT Operation Code could cause the stack elements to grow exponentially, which can lead to an exponential increase in memory usage and script size.

Therefore, out of an abundance of caution, Satoshi Nakamoto removed the OP_CAT on August 15, 2010. These removed Operation Code are often referred to as “disabled”, but this is not accurate, as they are completely removed from the protocol, making the Operation Code unavailable to anyone using the Bitcoin.

In October 2023, Bitcoin Core developer Ethan Heilman and Botanix Labs Principal Software Engineer Armin Sabouri jointly released a draft Bitcoin Improvement Proposal (BIP) titled “OP_CAT” that took this discussion to a new level.

This draft, consisting of only 13 lines of code, carries a clear and intuitive functional nature, defining a new tap Operation Code that allows two values to be concatenated on the stack. This code implementation was clearly inspired by the original deleted OP_CAT.

The conditions for “resurrection” have been met

As for why an Operation Code that was deleted by Satoshi Nakamoto is now being restored by developers, the motivational section of this BIP draft explains in some detail: this is mainly based on memory usage considerations, and OP_CAT makes the memory usage of script constructions increase exponentially from the size of the script itself. Specifically, a simple script that simply pushes a 1-byte value into the stack, then replicates it with OP_DUP Operation Code, and concatenates it 40 times with OP_CAT Operation Code can cause the stack value to bloat to a massive size of more than 1 TB.

Nevertheless, with the advancement of time and the development of technology, this issue is no longer an obstacle. Under the architecture of TAP, there is a clear rule that the maximum stack element size is strictly limited to 520 bytes. This change effectively solves the memory usage problems that can be caused by OP_CAT, providing the possibility of its “resurrection” and integration.

It follows that OP_CAT is once again being brought out for discussion and considered for reuse, mainly because of its potential value in building more complex and powerful scripts. In addition, a number of reasons and changes have met the conditions for “resurrection”, including:

1. Demand for advanced smart contracts and protocols: As the Bitcoin ecosystem has grown, the demand for more advanced and complex smart contracts and protocols has increased. OP_CAT increases the expressiveness and functionality of taps by allowing objects to be combined on the stack. For example, it can be used to build and evaluate Merkle Tree and other hash data structures, supporting tree signatures, post-quantum Lamport signatures, non-repudiation contracts, vaults, and more.

2. Other on-chain success stories: 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 ways to embed and retrieve data on the Blockchain. This indicates that the OP_CAT can be used safely and effectively under the appropriate environment and restrictions.

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-secure Bitcoin transactions and protocols can be built. 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 has prompted people to reconsider and evaluate previous decisions. As a deeper understanding of the Bitcoin protocol and new technologies emerge, features that were previously considered problematic or inapplicable may find safe and useful use cases in new contexts.

Soft fork, easy to talk about

On a technical level, few other Bitcoin proposals are as easy to interpret and understand as OP_CAT. But OP_CAT Operation Code will be activated by redefining the Soft Fork of Operation Code OP_SUCCESS 126, which is obviously not an easy task.

Recall that Bitcoin’s most recent Soft Fork occurred three years ago as Taproot was activated, thus helping to pave the way for the birth of Ordinals.

Consensus and transparency are highly valued by the Bitcoin community, and any significant code changes are widely discussed and reviewed within the community, including soft forks. For a piece of code to be merged into Bitcoin’s codebase, it needs to go through a rigorous and detailed process that ensures the quality of the proposal and community consensus. Here are the main steps in this process:

1. Write the proposal and code: First, the developer needs to write a detailed proposal document. This document should clearly describe the motivation, technical details, impact assessment, and any potential issues or challenges of the proposal.

2. Community discussion: Once a code proposal is submitted to the Bitcoin community, it is discussed and reviewed by community members (including developers, miners, investors, and users). 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 authors of the code may need to make modifications and improvements to the proposal.

4. Vote, Reach Consensus: Some important improvements (especially those involving the Bitcoin protocol itself) require a certain level of Consensus among community members. This usually involves the support of Miner, who need to show their support for the proposal by including a specific signal in the Block they mine.

5. Code Implementation: Once a Consensus is reached, the code will be reviewed by the Bitcoin Core developer team. This step requires ensuring the quality and security of the code.

6. Merge into codebase: After approval, the code will be merged into Bitcoin’s official codebase.

7. Deployment and activation: Finally, the new code needs to be deployed into their systems by Miners and Node Operators. For protocol-level changes, there is usually an activation threshold that 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 after the BIP draft was written, the BIP number has not yet been determined, and it is still in the first phase of writing the proposal and code and the second phase of community discussions involving developers and users.

What Bitcoin developers are saying

Let’s pay special attention to the discussion of OP_CAT among Bitcoin developers in recent years.

Although OP_CAT Operation Code was removed, the potential utility of OP_CAT in facilitating advanced contracts and enhancing Bitcoin scripting languages has been repeatedly discussed among developers. For example, its ability to connect stack values is considered a barrier to the development of some Bitcoin protocols, such as TumbleBit, whose transaction size can be greatly reduced if OP_CAT is supported.

Now that we’ve gathered the Optech newsletter and a variety of related content, let’s sort out some of the Bitcoin developers’ discussions about OP_CAT Operation Code in chronological order.

2019

Ethan Heilman, one of the sponsors of the OP_CAT Bitcoin Improvement Proposal (BIP) draft, said in an email in October 2019 that he understood why it was removed because of the dire situation faced by scripts at the time, but he emphasized the value of OP_CAT as an Operation Code: "Most protocols that want to build on top of Bitcoin today have a limitation: stack values cannot be connected. As a researcher, if I’m experiencing this limitation, it’s likely that it’s also hindering the progress of others. If I could wave my wand to re-enable one of the disabled Operation Codes, I would choose OP_CAT. Of course, this will be accompanied by a condition: the size of each concatenated value must be limited to 64 bytes or less. 」

When it comes to the discussion of OP_CAT, Andrew Poelstra is a person who can never get around. He wrote an article titled “CAT and Schnorr Tricks I” on January 30, 2021, which caused a wave of discussion about OP_CAT. Andrew Poelstra is the Director of Research at Blockstream and a veteran BitcoinCryptography scripting developer with a strong presence in the industry.

In the article, Andrew Poelstra explains, "OP_CAT helps combine two elements in the stack and push the merged result back into the stack. This function can be used to assemble multiple small elements into one large element, or to decompose a large element into multiple smaller elements. CHECKSIGFROMSTACK (CSFS) is a never-before-seen Operation Code in Bitcoin that allows users to perform signature verification on arbitrary data, unlike CHECKSIG Operation Code, which only verifies transaction signatures. 」

What’s more, he points out that using OP_CAT in conjunction with CHECKSIGFROMSTACK can provide an ingenious approach to transactional introspection.

Note: Transaction introspection refers to the ability to examine and analyze the various components of a transaction itself in Bitcoin Script. Put simply, it allows the script to “understand” and process the details of the transaction it is processing, such as checking the output of the transaction, the amount, or the specific signature. In this way, scripts are able to respond more intelligently and nuanced to the specific content of the transaction.

THIS ALLOWS THE USER TO PROVIDE THE DATA FOR THE ENTIRE TRANSACTION ON THE STACK, AND THE SCRIPT USES OP_CAT TO PACKAGE THE DATA INTO A SINGLE ITEM, HASH IT, AND THEN PASS IT TO CHECKSIGFROMSTACK TO VERIFY THE SIGNATURE ON THE DATA. It then passes the same signature and secret key to CHECKSIG. If both verifications pass, it indicates that the transaction data provided by the user is indeed real transaction data. This way, the script can directly use this data to perform any checks required by the contract.

Andrew Poelstra’s influence, and the idea of the article, caught the attention of Bitcoin developers, and at that week’s conference, there was much discussion about this combination of Operation Codes and how making small changes to the scripting language after taproot activation could improve contract flexibility.

About two weeks after the release of CAT and Schnorr Tricks I, Andrew Poelstra published a second article, CAT and Schnorr Tricks II, in which Andrew Poelstra recounts more details and his thoughts:

In May 2019, Bitcoin developer Jeremy Rubin proposed Bitcoin’s CHECKOUTPUTSHASHVERIFY Operation Code, with the aim of implementing a basic and limited Smart Contract that avoids the technical and social risks of previous Smart Contract designs. This Operation Code was subsequently replaced by SECURETHEBAG and later by CHECKTEMPLATEVERIFY, which officially became Bitcoin Improvement Proposal BIP 0119 in January 2020.

In the meantime, Russell O’Connor suggests adding CHECKSIGFROMSTACK and OP_CAT Operation Code directly to the Bitcoin to support Smart Contract that aren’t constrained by Rubin’s proposal. Although the proposal was met with some opposition and discussion eventually decreased, mainly due to the inefficiencies of CAT+CHECKSIG type smart contracts and the long-term negative impression of full universal smart contract holdings.

Andrew Poelstra was also reluctant to support the so-called BitcoinSmart Contract feature at first. However, in the fall of 2019, a private exchange with Ethan Heilman changed his mind. Ethan Heilman pointed out that despite the concerns, it is actually possible to implement smart contracts that are considered harmful through CHECKMULTISIG and are not actually accepted by wallets and users due to their lack of recognition and availability. To prove it, Ethan Heilman has challenged people on social media to come up with viable “dark” smart contracts, but so far no one has succeeded.

So Andrew Poelstra turned to thinking that everyone’s fear of Smart Contracts might be exaggerated. The article also argues that Smart Contract is inevitable in the development of Bitcoin, even if there are concerns, and encourages continued exploration of the possibility of creating Smart Contract using non-dedicated Operation Code OP_CAT.

In 2021

This was followed by an article by Jeremy Rubin on July 6, 2021, explaining the 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 R&D organization focused on developing Bitcoin’s Smart Contract programming language, Sapio.

In emails and blog posts, Jeremy Rubin discusses how to quantum-verify Bitcoin with OP_CAT Operation Code and Lamport signatures. The author begins by reviewing a previous blog post on how to register 5-byte values 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 could sign up to 20 bytes, we could sign a potentially quantum-safe HASH 160 digest.

Jeremy Rubin further explores the implications of signing a HASH 160 digest in the article and explains the ability to only reveal Private Key without altering the actual signed content even if Quantum Computer crack ECDSA. To do this, the authors consulted Cryptography scientist Madars Virza and received an affirmative 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 of Bitcoin. The 5-byte signature scheme discussed earlier is actually a quantum-safe Lamport signature. Unfortunately, this method requires at least 20 consecutive bytes.

Therefore, Jeremy Rubin proposed that some kind of OP_CAT-like operation was needed. The article explains that OP_CAT cannot be soft forked directly to Segwit v 0 because it modifies the stack. So, to simplify, the author shows how to use a new Operation Code OP_SUBSTRINGEQUALVERIFY that Operation Code checks if some part of a string is equal by validating the semantics.

On November 5, 2021, at the Atlanta Bitcoin Conference, Jeremy Rubin and Andrew Poelstra were among the speakers discussing the proposal to re-enable Operation Code OP_CAT, arguing that OP_CAT is important in the context of Bitcoin and highlighting its potential, especially in terms of quantum safety and making complex Smart Contract. For example, in combination with CAT and Schnorr signature verification Operation Code, non-recursive Smart Contract can theoretically be implemented. This smart contract is able to put the SHA 2 hash of transaction data directly into the stack. By doing so, restrictions can be imposed on various parts of the transaction to some extent.

The discussion also mentioned that if CAT is reintroduced, it may make Bitcoin complicated in some ways, while also introducing new features and possibilities. Restarting the OP_CAT requires careful consideration to avoid problems that have occurred in the past, such as memory explosions.

2022

In a discussion on the May 18, 2022 Bitcoin developer mailing list about the reintroduction of the OP_CAT Operation Code that was removed from the Bitcoin in 2010, developer ZmnSCPxj suggested that to achieve the inevitable recursive Smart Contract, OP_CAT would need to be combined with proposed Operation Code such as OP_TX, OP_CHECKSIGFROMSTACK (CSFS), etc. Recursive Smart Contract make use of BitcoinConsensus rules to ensure that all Bitcoin received from a contract can only be spent on the same contract.

Recursive smart contracts rely on transaction introspection techniques, that is, an Operation Code can parse a portion of the transaction on which the Operation Code is executed. The existing Operation Code provides 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 points 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, which focus on output introspection, can also be combined with CAT to create recursive smart contracts. Ivgi argues that, when used in conjunction with the functionality of taproot, validating the previous output with the next output makes smart contract scripting 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 noted in a follow-up post that recursive smart contracts may be safe because they are not actually Turing Complete. Russell O’Connor cites Andrew Poelstra’s article describing how CAT itself can be combined with existing Bitcoin functionality enough to create non-recursive smart contracts, and theoretically, if re-added to Bitcoin, may also be able to create recursive smart contracts on its own.

In 2023

In January, Anthony Towns launched Bitcoin Inquisition, a replica of Bitcoin Core designed to run on the default signet for testing proposed soft forks and other major protocol changes. As of the end of 2023, Bitcoin Inquisition has supported a number of proposals, and in addition, PRs (pull requests) designed to OP_CAT, OP_VAULT, and limit 64-byte transactions have been submitted to its codebase, which is expected to further expand the capabilities of this testbed.

On August 23, 2023, on the Lightning-Dev mailing list, Thomas Voegtlin came up with the idea of a fraud proof about the status of expired backups. Voegtlin points out that it is possible to use this fraud proof on-chain if OP_CHECKSIGFROMSTACK (CSFS) and OP_ CAT Operation Code are added to the Bitcoin in a Soft Fork way. The proposal sparked a lot of discussion, with Peter Todd pointing out that the basic mechanism is generic and not limited to LN and may be useful in various protocols, but he also proposed a simpler mechanism that will not be discussed here.

By October, Rusty Russell was working on a general-purpose Smart Contract for the Bitcoin scripting language with minimal changes. At the same time, very importantly, Ethan Heilman and Armin Sabouri jointly published a draft BIP proposing the addition of OP_CAT Operation Code, a Operation Code for connecting two elements on the stack. Discussions on these two topics continued into November.

In 2024

It’s January 2024, and Quantum Cats has indeed managed to take the discussion about BIP and the Bitcoin process for OP_CAT to the next level.

In an interaction with the community, Bitcoin Core developer Ava Chow said, "I don’t think CTV is a rough Consensus. I think other more general Smart Contract proposals are actually closer, such as txhash or CAT. However, I didn’t follow the discussion closely. 」

Ranked by number of commits, Ava Chow (@achow 101) is currently ranked 5th in the Bitcoin Core code contributor rankings with 1,292 code commits and is one of the few to have the right to merge Bitcoin code. As a result, she is also very influential in the development community.

"I’m not suggesting that we activate OP_CAT. I support OP_CAT because it is the Operation Code that is most likely to reach consensus. If you don’t know about OP_CAT, I summarize the situation in this image. So says Eric Wall (@ercwl), co-creator of Taproot Wizard.

However, Ava Chow doesn’t seem to be absolutely in favor of the implementation of OP_CAT: "As I’ve already said, I don’t think any Smart Contract proposal comes close to or has a rough Consensus. I don’t think we should try to activate any of them. 」

Ten lines of code to let Bitcoin implement Smart Contract

As Eric Wall (@ercwl), co-creator of Taproot Wizard, explains, "People don’t realize it, 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 to support projects like BitVM, a recently introduced concept of validating arbitrary computation on Bitcoin that will be made easier and more efficient thanks to OP_CAT. The Bitcoin ecosystem enables the creation of more versatile and expressive Smart Contracts.

Related reading: What do veteran developers think of BitVM to compute anything on Bitcoin?

With OP_CAT, so-called smart contracts can be implemented, i.e. pre-specified conditions are set for a specific Bitcoin output. This not only opens the door to new scaling methods, such as Blockstream’s Ark, but also supports many other innovative approaches that rely on Smart Contracts. In addition, it signifies that Bitcoin is not just a payment network, but also a versatile, scalable computing platform.

While Taproot Wizard co-creator Eric Wall is excited about the concept behind BitVM, he believes the proposal could be a “technical dead end” for Bitcoin due to its huge overhead and long implementation cycle. He worries that BitVM could distract the community and hinder real development. Despite this, BitVM’s proposal still shows the active spirit of exploration and innovation in the field of Blockchain technology and Smart Contract.

In fact, the Taproot Wizard project team itself is working on implementing a layer 2 solution on Bitcoin, and in a previous space, they also said that the completed $7.5 million funding round will be used to study Bitcoin scaling options.

Therefore, the soft fork of OP_CAT will also be an important step for them. Eric Wall, who used to be a board member of the StarkNet Foundation, has a great interest in building DeFi on top of creating a permissionless settlement layer, so when Ethereum began to emerge in 2019, he was naturally drawn to the Decentralized Finance space on Ethereum.

Bitcoin’s exploration of Decentralized Finance was almost completely abandoned when it became apparent in 2019 that Ethereum and other blockchains could scale by using zk-rollups or optimistic fraud proofs. With research on the feasibility of zk-rollup scaling applied to Bitcoin, Wall turned to support Decentralized Finance on Ethereum. But eventually, he’s trying to bring this system and these technological advantages to Bitcoin.

In addition, in a discussion thread on OP_CAT in the bitcointalk forum, Carter Feldman (@cmpeq), founder of the QED project, was asked how he intends to leverage this Operation Code in Bitcoin scripts, and if he calculates the average bytes of the witness stack and the fees that may be incurred.

Carter Feldman said he recognises that this can be a bit expensive, but explains that Merkel proof is primarily used in his project to build a trustless locking script or peg system as part of the zk layer two on Bitcoin. This system aims to prove that a certain amount of Bitcoin can be withdrawn to a specific Address given the root of the withdrawal tree (as a public input to a Zero-Knowledge Proof).

To address the cost, he mentioned that this would be a last resort. He envisions that regular users can buy wrapped BTC on the second layer by having the seller of wrapped BTC lock their Token on L2 for a period of time, during which time the buyer must prove that they have paid the seller on Bitcoin L1. They know that they can always exchange Bitcoin trustlessly if they want to. At the same time, several large liquidity providers would become entities that actually swap 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, the BIP proposal of OP_CAT can help build smart contracts on Bitcoin with only 13 lines of code, but there will still be a lot of discussion and trial solutions for the specific details of each project.

Memetic culture builds momentum and advances technology

TaprootWizards team member Rijndael (@rot 13 maxi) took to social media to share the various complex mechanics they use to create artwork. To achieve this, they rely on a variety of techniques, including ordinal recursion, pre-signed transactions, symmetric cryptography, and client-side load management. In the process of creating the art, they specifically chose to use pre-signed transactions to perform operations, showing how to pre-submit the hash of a transaction using a smart contract such as OP_CAT or CTV.

But Armin Sabouri commented sarcastically: "The code and technical effort required to create an evolving collection of Non-fungible Tokens can be 100 times the amount of work required to re-enable an Operation Code. 」

OP_CAT is considered to be a simple and easy-to-understand Operation Code, and it has been argued that it can make Bitcoin “quantum secure” by signing ECDSA signatures. This idea was supported by some and inspired the Taproot Wizard to launch the Quantum Cats Non-fungible Token campaign to raise awareness of OP_CAT.

However, it’s not just OP_CAT that uses memetic culture to build momentum for technological advancement.

Inspired by Quantum Cats and its 0.1 BTC selling price, and perhaps partly dissatisfied with its high selling price, the OP_CTV community has also launched a sandwich meme called #rubinsreubens to promote OP_CTV’s technology.

This sandwich meme was originally intended as a humorous response to the quantum cat and its memes. However, it’s 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 attracted the attention of many people. Memes are funny and can be used to show support for something, but it’s also important to understand the meaning behind it. The purpose of the #rubinsreubens is to improve understanding of the OP_ctv, LNHANCE, and Soft Fork proposals for new BTC Operation Code and enabling Smart Contract.

Potential causes of OP_CAT failures

Going back to OP_CAT, people might object to introducing features like OP_CAT for a number of reasons. First, adding new Operation Codes or features such as OP_CAT could increase the complexity of Bitcoin, making it more difficult to understand and secure to use, increasing risk. Second, security issues when introducing new features should not be overlooked, and features that have not been fully tested can harbor vulnerabilities that compromise the overall security of Bitcoin. In addition, if the soft fork upgrade is not adopted by all nodes, it may cause the network to split, causing different versions of the Bitcoin network to coexist, making reaching consensus more complicated.

New features can pose compatibility issues, especially if they don’t support older nodes, potentially excluding some Nodes from the network, negatively impacting Bitcoin’s ecosystem. Especially for those users who haven’t upgraded, they may find themselves unable to continue participating in the network. Additionally, some may see the introduction of new features as a hasty decision without prioritizing addressing pressing issues in Bitcoin’s core protocol. Rushed 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 fear of Smart Contract in the Bitcoin community, and the lack of “legitimacy” in the BitcoinSmart Contract.

Fear of Smart Contracts

Fear of BitcoinSmart Contract can 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, in the Bitcoin community, the acceptance of smart contracts is relatively low, in part due to concerns about the risks and challenges that smart contracts can pose. Smart Contracts can 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 that are deemed to threaten these values are likely to be opposed.

A major concern with Smart Contracts is that they can increase complexity and security risks across the network. Smart contracts often involve complex logic and code, and any small bug or vulnerability can lead to serious security issues and even massive loss of funds, as has happened in some Blockchain projects in the past. In addition, the introduction of smart contracts may make the entire system more difficult to understand and audit, increasing the likelihood of errors.

In addition, the Bitcoin community has always placed great emphasis on maintaining the stability and security of the network. Bitcoin’s design philosophy leans towards simplicity and conservatism, prioritizing the security and decentralization of the network. As a result, any significant changes that could pose a threat to cyber stability are subject to intense scrutiny and extensive debate. The introduction of OP_CAT and Smart Contracts, while potentially bringing new features and possibilities to Bitcoin, may also be seen as contrary to Bitcoin’s original vision and design philosophy.

Was Satoshi Nakamoto “wrong”?

Restoring OP_CAT Operation Code has sparked a deep discussion in the community, in part because it touches on a sensitive topic: Does this mean Satoshi Nakamoto is wrong?

As the founder of Bitcoin, Satoshi Nakamoto’s decisions and original design are held up as bible by many, and his original vision is considered a central guide to Bitcoin’s development. Therefore, any kind of challenge or modification to Satoshi Nakamoto’s decision may be seen as disrespectful to his legacy or a departure from Bitcoin’s core principles. After all, in the Blockchain industry, legitimacy has always been an unavoidable topic.

Therefore, the proposal to restore the OP_CAT also touches on a broader question: should Bitcoin be a static entity, or should it adapt to the changing technological environment and user needs?

However, the technical field is always progressing and changing, and Bitcoin, as a technological innovation, cannot completely get rid of this law, and apparently the Taproot Wizard team that supports the restoration of OP_CAT thinks so. After all, they deliberately designed the biggest BitcoinBlock ever, just under the Bitcoin 4 MB limit, to release Non-fungible Token Taproot Wizards.

Udi Wertheimer, founder of Taproot Wizard, said he understands that many people believe that Bitcoin should not change. He believes that changes in Bitcoin should be slow, cautious, and deliberate. He argues that Bitcoin is too young to fully solidify, noting that the governance process is somehow broken. Although the technical community generally agrees that there will be more upgrades to Bitcoin, it is really difficult to determine exactly which upgrades will be. Still, Wertheimer stressed that change is necessary because the current Bitcoin is not yet able to serve billions of people.

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

Predictably, going forward, to ensure that the proposed improvements are safe and effective, deploying OP_CAT in a Testnet environment is a critical step that allows developers to identify and resolve issues without impacting the Mainnet.

At the same time, in order to truly realize the “restart” of OP_CAT, the whole process will last for a long time, even in years, because it involves many considerations and balances, including technical details, community consensus, and considerations for the security and stability of Bitcoin network, and most importantly, broad community support and recognition.