13-line code helps Bitcoin achieve smart contracts? Understanding the OP_CAT soft fork.

In the Bitcoin codebase, an opcode called “OP_CAT” that was once deleted by Satoshi Nakamoto and has been buried in history for a long time may be “resurrected”.

Taproot Wizards, a Bitcoin NFT project, has launched a new series of NFTs Quantum Cats, which has caused a hot discussion in the community around the OP_CAT opcode. Although the term OP_CAT does not refer to the “cat” we are familiar with, Taproot Wizard has used the image of a cat to sell a new NFT called Quantum Cats, using meme culture to promote OP_CAT.

Related Reading:”Bitcoin “Quantum Cat”: Without smart contracts, how can inscriptions change dynamically?》

OP_CAT, an opcode that was once removed from the Bitcoin script 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 13-line code soft fork. With the push of Bitcoin developers and the hype created by the cat meme, the popularity and discussion of OP_CAT has reached new heights.

“Resurrection” opcode deleted by Satoshi Nakamoto

Operation codes (Opcodes), also known as instructions or functions, are the basic building blocks of the Bitcoin scripting language. In the past, due to concerns about potential vulnerabilities in client implementations, some opcodes were removed from early versions of Bitcoin, including the OP_CAT opcode.

OP_CAT was originally part of the official Bitcoin command set, allowing for string concatenation by joining two elements into one. However, serious vulnerabilities were discovered in OP_LSHIFT and other opcodes, which could cause any Bitcoin node to crash. There were also concerns that the OP_CAT opcode could lead to exponential growth in stack elements, potentially causing memory usage and script size to grow exponentially.

Therefore, out of caution, Satoshi Nakamoto removed OP_CAT on August 15, 2010. These removed opcodes are commonly referred to as “disabled,” but this is not accurate because they were completely deleted from the protocol, making it impossible for anyone using Bitcoin to use these opcodes.

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

This draft contains only concise 13 lines of code, but carries a clear and intuitive functional nature, defining a new tapscript opcode that allows two values to be concatenated on the stack. The inspiration for this code implementation is clearly derived from the original deleted OP_CAT.

“Resurrection” conditions have been met

As for why a deleted opcode by Satoshi Nakamoto is now being sought 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, where OP_CAT can cause the memory usage of script construction to grow exponentially with the size of the script itself. Specifically, a simple script that only pushes a 1-byte value onto the stack, duplicates it using the OP_DUP opcode, and concatenates it 40 times using the OP_CAT opcode, can cause the stack value to expand to a huge scale exceeding 1TB.

However, with the passage of time and the development of technology, this issue is no longer a barrier. Under the architecture of tapscript, a clear rule has been established, which strictly limits the size of the maximum stack element to within 520 bytes. This change effectively solves the memory usage problem that OP_CAT may cause, providing the possibility for its “resurrection” and integration.

It can be seen from this that OP_CAT has once again been brought up for discussion and consideration for restoration of use, mainly due to its potential value in building more complex and powerful scripts. In addition, some reasons and changes have met the conditions for its “resurrection”, including:

1. Requirements for advanced smart contracts and protocols: With the development of the Bitcoin ecosystem, there is an increasing demand for more advanced and complex smart contracts and protocols. OP_CAT increases 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, support tree signatures, post-quantum Lamport signatures, non-repudiable contracts, insurance libraries, and other functions.
2. Other successful cases on the chain: Some Bitcoin forks, such as Bitcoin Cash and sidechain Liquid, have re-enabled OP_CAT and used it to create and manage tokens, payment channels, and methods for embedding and retrieving data on the blockchain. This indicates that OP_CAT can be used safely and effectively in the appropriate environment and limitations.
3. Exploration of Quantum Security: Some studies have proposed that by using operations such as OP_CAT, combined with Lamport signatures and other technologies, quantum-secure Bitcoin transactions and protocols can be constructed. This exploration has potential value for improving the future security of the Bitcoin system.
4. Community and Technological Development: The continuous development of the Bitcoin community and technology has prompted people to reconsider and evaluate previous decisions. With a deeper understanding of the Bitcoin protocol and the emergence of new technologies, features that were previously considered problematic or not applicable may find secure and useful applications in new contexts.

Soft forks, not easy

On a technical level, few Bitcoin proposals are as straightforward to interpret and understand as OP_CAT. However, activating the OP_CAT opcode through a soft fork by redefining the opcode OP_SUCCESS126 is evidently not a simple task.

Reflecting on Bitcoin’s latest soft fork that took place three years ago, the activation of Taproot facilitated the emergence of Ordinals.

The Bitcoin community highly values consensus and transparency. Any significant code change, including soft forks, undergoes extensive discussion and review within the community. Integrating code into Bitcoin’s codebase requires a rigorous and detailed process that ensures the quality of the proposal and the consensus of the community. The main steps of this process include:

1. Writing the proposal and code: Initially, 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 problems or challenges.

2. Community discussion: After the code proposal is submitted to the Bitcoin community, community members (including developers, miners, investors, and users) discuss and review it. This stage is crucial for ensuring the feasibility of the proposal and collecting feedback.

3. Revision and improvement: Based on community feedback, the code’s author may need to modify and improve the proposal.

4. Voting, reaching consensus: For some significant improvements (especially those involving changes to the Bitcoin protocol itself), a certain level of consensus is required among community members. This usually involves the support of miners, who need to include specific signals in the blocks they mine to indicate their support for the proposal.

5. Code implementation: Once a consensus is reached, the code is reviewed by the Bitcoin Core development team. This step ensures the quality and security of the code.

6. Merging into the codebase: After the review is passed, the code is merged into the official Bitcoin code repository.

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 the improvements only take effect once enough network participants upgrade to the new version.

Clearly, the implementation of the OP_CAT soft fork is still in its very early stages. Less than four months have passed since the BIP draft was written, and the BIP number has not yet been determined. It is still in the first stage of writing the proposal and code and the second stage of community discussions, including developers and users.

What Bitcoin Developers Say

Let’s first pay special attention to the discussions among Bitcoin developers about OP_CAT in recent years.

Despite the removal of the OP_CAT opcode, its potential utility in facilitating advanced contracts and enhancing the Bitcoin scripting language has been a topic of ongoing discussion among developers. For instance, its capability in concatenating stack values is considered a barrier hindering the development of certain Bitcoin protocols, such as TumbleBit, which could significantly reduce transaction sizes if OP_CAT were supported.

After gathering information from Optech newsletters and various related sources, some discussions among Bitcoin developers about the OP_CAT opcode are organized chronologically below.

2019

In October 2019, Ethan Heilman, one of the initiators of the “OP_CAT” Bitcoin Improvement Proposal (BIP) draft, expressed his understanding of why it was removed in an email—due to the extremely severe situation faced by the script at that time. However, he emphasized the value of OP_CAT as an opcode, stating: “Most protocols currently intended to be built on Bitcoin encounter a limitation: stack values cannot be concatenated. As a researcher, if I encounter this limitation, it’s likely also hindering others’ progress. 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: the size of each concatenated value must be limited to 64 bytes or less.”

Andrew Poelstra is an indispensable figure in the discussions about OP_CAT. He wrote an article titled “CAT and Schnorr Tricks I“ on January 30, 2021, which sparked a flurry of discussions about OP_CAT. As the Director of Research at Blockstream and a seasoned developer of cryptographic scripts for Bitcoin, his influence in the industry is undeniable.

In his article, Andrew Poelstra introduced: “OP_CAT helps combine two elements in the stack and pushes the combined result back to the stack. This function can be used to assemble multiple small elements into a large element, or to break down a large element into multiple small elements. On the other hand, CHECKSIGFROMSTACK (CSFS) is an opcode never before seen in Bitcoin, allowing users to perform signature verification 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 offer a clever method for transaction introspection.

Note: Transaction introspection refers to the ability in Bitcoin scripts to inspect and analyze various components of the transaction itself. Simply put, it allows the script to “understand” and handle detailed information of the transaction it is processing, such as checking the transaction’s output content, amount, or specific signatures. This enables the script to respond more intelligently and meticulously based on the specific content of the transaction.

This way, users provide the entire transaction data on the stack, and the script uses OP_CAT to package these data into a single item, processes it with a hash, and then passes 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 indicates that the transaction data provided by the user is indeed genuine. Thus, the script can directly utilize these data to perform any checks required by the contract.

The influence of Andrew Poelstra, and the conception of this article, caught the attention of Bitcoin developers, and many discussions were held in that week’s meeting about the combination of these opcodes and how minor changes to the scripting language after activating taproot could enhance contract flexibility.

About two weeks after the release of “CAT and Schnorr Tricks I,” Andrew Poelstra published the second paper, “CAT and Schnorr Tricks II,“ where he elaborated on more details and his thoughts.

In May 2019, Bitcoin developer Jeremy Rubin introduced the CHECKOUTPUTSHASHVERIFY opcode for Bitcoin, aiming to implement a basic yet restricted form of smart contract, thereby avoiding the technical and societal risks previously inherent in smart contract design. This opcode was subsequently replaced by SECURETHEBAG, and later by CHECKTEMPLATEVERIFY, which formally became the Bitcoin Improvement Proposal BIP 0119 in January 2020.

Simultaneously, Russell O’Connor suggested adding the CHECKSIGFROMSTACK and OP_CAT opcodes directly to Bitcoin to support smart contracts not limited by Rubin’s proposal. Although this suggestion faced some opposition and discussions eventually dwindled, mainly due to the inefficiency of CAT+CHECKSIG type smart contracts and the long-standing negative perception towards universally applicable smart contracts.

Initially, Andrew Poelstra was also reluctant to support the so-called Bitcoin smart contract feature. However, a private conversation with Ethan Heilman in the autumn of 2019 changed his mind. Ethan Heilman pointed out that despite concerns, the smart contracts considered harmful could actually be implemented through CHECKMULTISIG. However, these contracts are not accepted by wallets and users due to a lack of recognition and availability. To prove this point, Ethan Heilman initiated a challenge on social media, encouraging people to propose viable “dark” smart contracts, but so far, no one has succeeded.

Thus, Andrew Poelstra began to reconsider, thinking that the fear of smart contracts might be exaggerated. The article also suggests that, despite existing concerns, the development of smart contracts in Bitcoin is inevitable, and it encourages the continued exploration of the possibilities of creating smart contracts using the non-dedicated opcode OP_CAT.

2021

Subsequently, there was an article by Jeremy Rubin on July 6, 2021, elaborating on 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 and development organization focused on developing Sapio, a smart contract programming language for Bitcoin.

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 revisited a previous blog post, which 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 posed a question: What if we could sign longer pieces of information? Especially, if we could sign up to 20 bytes, we could sign a HASH160 digest that might be quantum secure.

Jeremy Rubin further explored the implications of signing a HASH160 digest in the article and explained that even if a quantum computer cracked ECDSA, it would only reveal the private key without changing the ability to sign actual content. To this end, the author consulted with cryptographer Madars Virza and received affirmative answers.

Jeremy Rubin pointed out that if we require ECDSA signatures to use a quantum-proof signature algorithm, we could have quantum-proof Bitcoin. The previously discussed 5-byte signature scheme is actually a quantum-safe Lamport signature. Unfortunately, this method requires at least 20 consecutive bytes.

Therefore, Jeremy Rubin proposed the need for an operation similar to OP_CAT. The article explains that OP_CAT cannot be soft-forked directly into Segwit v0, as it would modify the stack. Therefore, for simplicity, the author demonstrated how to use a new opcode, OP_SUBSTRINGEQUALVERIFY, which checks whether a part of a string is equal by verifying semantics.

On November 5, 2021, at the Atlanta Bitcoin Conference, Jeremy Rubin and Andrew Poelstra spoke about the proposal to re-enable the OP_CAT opcode. They considered OP_CAT to be important in the context of Bitcoin and emphasized its potential, especially in terms of quantum security and creating complex smart contracts. For example, combining CAT with Schnorr signature verification opcodes could theoretically realize non-recursive smart contracts. Such smart contracts would be able to put the SHA2 hash of transaction data directly into the stack, thereby imposing restrictions on various parts of the transaction to some extent.

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

2022

In the Bitcoin developers mailing list on May 18, 2022, during discussions about reintroducing the OP_CAT opcode, which was removed from Bitcoin in 2010, developer ZmnSCPxj proposed that to implement inevitable recursive smart contracts, OP_CAT needs to be combined with proposed opcodes such as OP_TX, OP_CHECKSIGFROMSTACK (CSFS). Recursive smart contracts use Bitcoin consensus rules to ensure that all Bitcoins received by the contract can only be spent on the same contract.

Recursive smart contracts rely on transaction introspection technology, meaning that opcodes can analyze parts of the transaction executing that opcode. Existing opcodes offer limited introspection. To create recursive smart contracts, it’s 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 a similar structure is needed to implement recursive smart contracts.

Nadav Ivgi pointed out that while creating recursive smart contracts, CAT is still needed to solve the hash problem. However, this means that features focusing on output introspection, like CTV and APO, can also be combined with CAT to create recursive smart contracts. Ivgi believes that when used in conjunction with the functionality of taproot, validating the previous output through the next output can make smart contract scripts easier to write and provided 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 subsequent posts that recursive smart contracts might be safe because they are not actually Turing complete. Russell O’Connor cited Andrew Poelstra’s article, which described how CAT itself, combined with existing Bitcoin functionalities, is sufficient to create non-recursive smart contracts and, theoretically, if reintroduced to Bitcoin, might also be able to create recursive smart contracts on its own.

2023

In January, Anthony Towns launched Bitcoin Inquisition, a fork of Bitcoin Core software 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 several proposals. Moreover, PRs (Pull Requests) intended for OP_CAT, OP_VAULT, and restricting 64-byte transactions were submitted to its code repository, with expectations of further expanding this testing platform’s functionalities.

On August 23, 2023, in the Lightning-Dev mailing list, Thomas Voegtlin proposed an idea about a fraud proof for expired backup states. Voegtlin noted that if OP_CHECKSIGFROMSTACK (CSFS) and OP_CAT opcodes were added to Bitcoin via a soft fork, it would be possible to use such a fraud proof on-chain. The proposal sparked extensive discussions, with Peter Todd noting that the basic mechanism is universal, not limited to LN, and might be useful in various protocols. However, he also suggested a simpler mechanism, which is not elaborated here.

By October, Rusty Russell researched the universal smart contracts of the Bitcoin scripting language with minimal changes. Simultaneously, it was significant that Ethan Heilman and Armin Sabouri jointly published a BIP draft, proposing to add the OP_CAT opcode, which concatenates two elements on the stack. Discussions on these two topics continued into November.

2024

By January 2024, Quantum Cats indeed elevated the discussion about the BIP for OP_CAT and the Bitcoin process to a new level.

In interactions with the community, Bitcoin Core developer Ava Chow once stated, “I don’t think CTV represents a rough consensus. I believe other more general smart contract proposals are closer, such as txhash or CAT. However, I have not been closely following the discussions.”

Ranked by the number of contributions, Ava Chow (@achow101) is currently ranked 5th among Bitcoin Core code contributors, with a total of 1292 commits, and is one of the few with the right to merge Bitcoin code. Hence, her influence in the development community is significant.

“I’m not suggesting that we activate OP_CAT. I support OP_CAT because it’s an opcode that is very likely to reach a consensus. If you’re not familiar with the situation of OP_CAT, I have summarized it in this picture,” said Eric Wall (@ercwl), co-founder of Taproot Wizards.

However, Ava Chow seems to not absolutely endorse the implementation of OP_CAT, stating, “As I’ve already said, I don’t think any smart contract proposal is close to or has reached a rough consensus. I believe we shouldn’t attempt to activate any of them.”

Ten Lines of Code, Enabling Smart Contracts on Bitcoin

As co-founder of Taproot Wizard, Eric Wall (@ercwl) put it: “People may not realize it, but OP_CAT is actually one of the building blocks for zkrollup on Bitcoin.”

The reintroduction of OP_CAT provides Bitcoin with a powerful tool that can support projects like BitVM. The recently introduced concept of BitVM – verifying arbitrary computation on Bitcoin – will become more straightforward and efficient with OP_CAT. The Bitcoin ecosystem can create more versatile and expressive smart contracts.

Related Reading:”To compute anything on Bitcoin, what do veteran developers think about BitVM?》

Through OP_CAT, so-called smart contracts can be realized, setting predefined conditions for specific Bitcoin outputs. This not only opens the door for new extension methods like Blockstream’s Ark but also supports many other innovative methods reliant on smart contracts. Moreover, it signifies that Bitcoin is not just a payment network but can also become a multi-functional, scalable computing platform.

While Eric Wall, co-founder of Taproot Wizard, is excited about the concept behind BitVM, he believes the proposal could be a “technical dead-end” for Bitcoin due to its significant overhead and long implementation period. He worries that BitVM may divert the community’s attention and hinder real progress. Nevertheless, the introduction of BitVM still demonstrates the active exploration and innovative spirit in the blockchain technology and smart contract domain.

In fact, the Taproot Wizard project team is also committed to implementing a second-layer solution on Bitcoin. In a previous Space, they mentioned completing a $7.5 million funding round, which will be used to research Bitcoin scaling solutions.

Therefore, the soft fork of OP_CAT will also be an important step for them. Eric Wall, once a board member of the StarkNet Foundation, has a keen interest in creating permissionless settlement layers for building decentralized finance. So naturally, he was drawn to the DeFi sector on Ethereum when it started emerging in 2019.

When it became apparent in 2019 that Ethereum and other blockchains could scale by using zk-Rollups or optimistic fraud proofs, Bitcoin’s exploration in DeFi was almost entirely abandoned. With research questions such as the feasibility of applying zk-Rollup scaling to Bitcoin, Wall turned to support DeFi on Ethereum. Ultimately, he is striving to bring this system and these technological advantages to Bitcoin.

Moreover, in the discussion thread about OP_CAT on the bitcointalk forum, Carter Feldman (@cmpeq), the founder of the QED project, was asked how he plans to utilize this opcode in Bitcoin script, 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 mainly used to build a trustless lock script or hook system, as part of the 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 the zero-knowledge proof).

To address the cost issue, he mentioned this will be a means. He envisioned that ordinary users could purchase wrapped BTC on the second layer by having sellers of wrapped BTC lock their tokens on L2 for a period. During this time, buyers must prove that they have paid the seller on Bitcoin L1. They know they can always trustlessly swap back to Bitcoin if they wish. Meanwhile, several large liquidity providers would be the actual entities exchanging between wBTC and BTC, and might charge a small fee to those small users who want to buy wBTC from them or bridge it back to Bitcoin.

Therefore, in summary, this BIP proposal for OP_CAT, with only 13 lines of code, can help build smart contracts on Bitcoin. However, there will still be a lot of discussions and trial solutions regarding the specifics of each project’s handling details.

Meme Culture Drives Technological Advancement

Team member Rijndael (@rot13maxi) from Taproot Wizards shared on social media the various complex mechanisms they use to create artworks. To achieve this, they rely on multiple technologies, including ordinal recursion, pre-signed transactions, symmetric cryptography, and client-side load management. During the art creation process, they specifically use pre-signed transactions to execute operations, demonstrating how to pre-commit transaction hashes using smart contracts such as OP_CAT or CTV.

However, Armin Sabouri commented , “The code and technical effort invested in creating an evolving NFT collection might be a hundred times the workload needed to re-enable a certain 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 sentiment has gained support from some and inspired Taproot Wizard to launch a Quantum Cats NFT campaign to raise awareness for OP_CAT.

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, 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 caught the attention of many people. Memes are fun and can be used to show support for something, but it’s 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 the Failure of OP_CAT

People might oppose the introduction of functionalities like OP_CAT for various reasons. First, adding new opcodes or features such as OP_CAT could increase Bitcoin’s complexity, making it more difficult to understand and securely use, thus increasing risks. Secondly, the security concerns when introducing new functionalities cannot be ignored. Features that haven’t been thoroughly tested may contain vulnerabilities, compromising the overall security of Bitcoin. Moreover, if a soft fork upgrade is not adopted by all nodes, it might lead to network fragmentation, with different versions of the Bitcoin network coexisting, making consensus even more complicated.

New features might bring compatibility issues, especially if they don’t support legacy nodes, potentially excluding some nodes from the network, negatively impacting Bitcoin’s ecosystem. Particularly, those users who haven’t upgraded might find themselves unable to continue participating in the network. Furthermore, some may consider the introduction of new functionalities to be hasty decisions, not prioritizing resolving pressing issues in the core Bitcoin protocol. Hasty changes could introduce unnecessary risks and instability.

Besides concerns about security and risks, two significant reasons for the potential failure of OP_CAT are: the Bitcoin community’s fear of smart contracts and the perceived lack of ‘legitimacy’ of smart contracts on Bitcoin.

Fear of smart contracts

Fear of smart contracts on Bitcoin might be another significant obstacle for the implementation of OP_CAT. As a core component of blockchain technology, smart contracts play a crucial role in many blockchain projects, especially on platforms like Ethereum.

Fear of smart contracts on Bitcoin might be another significant obstacle for the implementation of OP_CAT. As a core component of blockchain technology, smart contracts play a crucial role in many blockchain projects, especially on platforms like Ethereum.

One primary concern about smart contracts is that they might 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 severe security issues and potentially massive financial losses, as has occurred in some blockchain projects in the past. Furthermore, the introduction of smart contracts might make the entire system harder to understand and audit, thereby increasing the likelihood of errors.

Additionally, the Bitcoin community has always placed great emphasis on maintaining the stability and security of the network. Bitcoin’s design philosophy tends toward simplicity and conservatism, prioritizing the network’s security and decentralization. Therefore, any significant change that could threaten network stability will be subject to rigorous scrutiny and widespread debate. The introduction of OP_CAT and smart contracts, although they could bring new features and possibilities to Bitcoin, might also be seen as contradictory to Bitcoin’s original vision and design philosophy.

Did Satoshi Nakamoto “Err”?

The restoration of the OP_CAT opcode has sparked profound discussions in the community, partly because it touches on a sensitive issue: does this imply that Satoshi Nakamoto was wrong?

As the founder of Bitcoin, Satoshi Nakamoto’s decisions and original design are revered by many as sacrosanct, and his original vision is considered the core guide for Bitcoin’s development. Therefore, any form of challenge or modification to Nakamoto’s decisions might be perceived as disrespect for his legacy or a deviation from Bitcoin’s core principles. After all, in the blockchain industry, legitimacy is always a topic that can’t be circumvented.

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

The field of technology is always advancing and changing, and Bitcoin, as a technological innovation, cannot entirely escape this rule. Clearly, the Taproot Wizards team supporting the restoration of OP_CAT thinks this way. After all, they intentionally designed one of the larger Bitcoin blocks ever, slightly below the 4MB Bitcoin limit, to release the NFT Taproot Wizards.

Udi Wertheimer, the founder of Taproot Wizard, expressed his understanding that 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 completely solidified and notes that the governance process is somewhat broken. Although the technical community generally agrees that Bitcoin will have more upgrades, it is indeed hard to determine exactly what those upgrades will be. Nonetheless, Wertheimer emphasizes that change is necessary because the current Bitcoin is still unable to serve billions of people.

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

It is foreseeable that, next, 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 address issues without affecting the main network.

At the same time, to truly realize the “reboot” of OP_CAT, the entire process will take a considerable amount of time, even in terms of years, as it involves multifaceted considerations and balances, including technical details, community consensus, considerations of Bitcoin network security and stability, and very importantly, widespread community support and recognition.

Disclaimer：

1. This article is reprinted from [theblockbeats]. All copyrights belong to the original author [Jaleel]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.