Original Author: Jaleel, BlockBeats
In the Bitcoin codebase, an opcode "OP_CAT" that was once deleted by Satoshi Nakamoto and has been sealed in history for a long time may be "resurrected".
Surrounding the OP_CAT opcode, the Bitcoin NFT project Taproot Wizards has launched a new series of NFT Quantum Cats, causing a hot community discussion. 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 NFT called Quantum Cats, using meme culture to promote OP_CAT. Related reading: "Bitcoin 'Quantum Cats': How does the inscription achieve dynamic changes without smart contracts?"
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 "resurrect" this opcode and lay the groundwork for implementing smart contracts in Bitcoin through a soft fork of 13 lines of code. With the promotion by Bitcoin developers and the meme image of a cat, the popularity and discussion of OP_CAT have reached new heights.
"Resurrected" opcode deleted by Satoshi Nakamoto
Opcodes, also known as instructions or functions, are the basic elements of the Bitcoin script language. Historically, due to concerns about potential vulnerabilities in client implementations, some opcodes in early versions of Bitcoin were removed, and OP_CAT is one of them.
OP_CAT was originally part of the official Bitcoin command set, allowing for string concatenation, combining two elements into one. However, due to serious vulnerabilities found in other opcodes such as OP_LSHIFT that could cause any Bitcoin node to crash, and concerns that OP_CAT could lead to exponential growth of stack elements, which could lead to exponential growth in memory usage and 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 is not accurate, as they were completely removed from the protocol, making it impossible for anyone using Bitcoin to use these opcodes.
In October 2023, Bitcoin Core developers Ethan Heilman and Armin Sabouri, Chief Software Engineer at Botanix Labs, jointly released a Bitcoin Improvement Proposal (BIP) draft called "OP_CAT", bringing 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 tapscript opcode that allows concatenating two values on the stack. This code is clearly inspired by the original deleted OP_CAT.
The conditions for "resurrection" have been met
As for why a deleted opcode by Satoshi Nakamoto is now being considered for restoration, the motivation section of this BIP draft provides some detailed explanations: this is mainly based on considerations of memory usage, as OP_CAT could lead to exponential growth in memory usage in script construction. Specifically, a simple script that pushes a 1-byte value onto the stack, then duplicates it using the OP_DUP opcode, and then concatenates it 40 times using the OP_CAT opcode, could lead to stack values expanding to over 1TB in size.
However, as time has passed and technology has developed, this issue is no longer a barrier. Under the architecture of tapscript, a clear rule has been established, namely that the maximum stack element size is strictly limited to 520 bytes. This change effectively addresses the memory usage issues that OP_CAT could cause, providing the possibility for its "resurrection" and integration.
It can be seen that OP_CAT is being discussed and considered for restoration because it has potential value in building more complex and powerful scripts. In addition, some reasons and changes have met the conditions for "resurrection", including:
Demand 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 the combination of objects 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-repudiation contracts, custody libraries, and other functions.
Success cases on other chains: Some Bitcoin forks, such as Bitcoin Cash and the Liquid sidechain, have re-enabled OP_CAT and used it to implement token creation and management, payment channels, and methods for embedding and retrieving data on the blockchain. This indicates that under appropriate conditions and restrictions, OP_CAT can be used safely and effectively.
Exploration of quantum security: Research has suggested that by using operations like OP_CAT combined with technologies such as Lamport signatures, it is possible to build quantum-secure Bitcoin transactions and protocols. This exploration has potential value in improving the future security of the Bitcoin system.
Community and technological development: The continuous development of the Bitcoin community and technology has led people to reconsider and re-evaluate previous decisions. With a deeper understanding of the Bitcoin protocol and the emergence of new technologies, features that were previously considered problematic or inapplicable may find secure and useful applications in new contexts.
Soft fork, easier said than done
From a technical perspective, there are few other Bitcoin proposals as easy to read and understand as OP_CAT. However, activating the OP_CAT opcode through redefining the opcode OP_SUCCESS126 in a soft fork is clearly not an easy task.
The most recent soft fork in Bitcoin occurred three years ago, paving the way for the birth of Taproot by activating it.
The Bitcoin community places great emphasis on consensus and transparency, and any major code changes are widely discussed and reviewed in the community, including soft forks. For a piece of code to be merged into the official Bitcoin codebase, it needs to go through a strict and detailed process, ensuring the quality of the proposal and the consensus of the community. The following are the main steps of this process:
Write proposal and code: First, developers need to write a detailed proposal document. This document should clearly describe the motivation for the proposal, technical details, impact assessment, and any potential issues or challenges.
Community discussion: After the code proposal is submitted to the Bitcoin community, community members (including developers, miners, investors, and users) will discuss and review it. This stage is crucial for ensuring the feasibility of the proposal and collecting feedback.
Modification and improvement: Based on community feedback, the authors of the code may need to modify and improve the proposal.
Voting, consensus reached: For some important improvements (especially those involving changes to the Bitcoin protocol itself), community members need to reach a certain level of consensus. This usually involves miner support, as they need to signal their support for the proposal by including a specific signal in the blocks they mine.
Code implementation: Once consensus is reached, the code will be reviewed by the Bitcoin Core development team. This step ensures the quality and security of the code.
Merge into the codebase: After passing the review, the code will be merged into the official Bitcoin codebase.
Deployment and Activation: Finally, the new code needs to be deployed to the systems of miners and node operators. 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.
Obviously, the implementation of the OP_CAT soft fork is still in a very early stage. It has been less than four months since the BIP draft was written, and the BIP number has not been determined yet. It is still in the first stage of writing the proposal and code, and the second stage of community discussion, including developers and users.
What Bitcoin Developers Say
Let's first focus on the discussions of Bitcoin developers on OP_CAT in recent years.
Although the OP_CAT opcode was deleted, its potential utility in promoting advanced contracts and enhancing the Bitcoin script language has been repeatedly discussed among developers. For example, its ability to concatenate stack values is considered to be a hindrance to the development of certain Bitcoin protocols, such as TumbleBit, which could greatly reduce transaction size if it supported OP_CAT.
After collecting Optech newsletters and various related content, the following is a chronological compilation of some discussions of Bitcoin developers on OP_CAT.
2019
One of the initiators of the "OP_CAT" Bitcoin Improvement Proposal (BIP) draft, Ethan Heilman, expressed his understanding of why it was removed in an email in October 2019, emphasizing the value of OP_CAT as an opcode: "Most protocols that people want to build on top of Bitcoin currently run into a limitation: stack values cannot be concatenated. As a researcher, if I run into this limitation, it's likely also impeding others. If I could wave a magic wand and 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."
Regarding the discussion of OP_CAT, Andrew Poelstra is an unavoidable figure. His article titled "CAT and Schnorr Tricks I" in January 30, 2021, sparked a discussion on OP_CAT. Andrew Poelstra is the Research Director at Blockstream and a senior Bitcoin cryptographic script developer, with significant influence in the industry.
In the article, Andrew Poelstra explains: "OP_CAT helps to combine two elements in the stack and push the merged result back onto the stack. This functionality can be used to assemble multiple small elements into a large element, or to break down a large element into multiple small elements. CHECKSIGFROMSTACK (CSFS) is an opcode in Bitcoin that has never existed before, allowing users to verify signatures on arbitrary data, unlike the CHECKSIG opcode, which can only verify transaction signatures."
More importantly, he points out that using OP_CAT in combination with CHECKSIGFROMSTACK can provide a clever method for transaction introspection.
Note: Transaction introspection refers to the ability to inspect and analyze various components of the transaction itself in the Bitcoin script. In simple terms, it allows the script to "understand" and process detailed information about the transaction it is processing, such as checking the transaction's output content, amount, or specific signatures. This allows the script to make more intelligent and detailed responses based on the specific content of the transaction.
By providing the entire transaction data on the stack, the script uses OP_CAT to package this data into a single item, performs a hash operation, and then passes it to CHECKSIGFROMSTACK to verify the signature on the data. Then, 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 authentic transaction data. This allows the script to directly perform any checks required for the contract using this data.
Andrew Poelstra's influence and the concept of this article caught the attention of Bitcoin developers, and there were many discussions at the meeting that week on the combination of this opcode and how minor changes to the script language after activating taproot could improve contract flexibility.
About two weeks after the release of "CAT and Schnorr Tricks I", Andrew Poelstra posted a second article "CAT and Schnorr Tricks II", in which he narrates more details and his thoughts:
In May 2019, Bitcoin developer Jeremy Rubin proposed the CHECKOUTPUTSHASHVERIFY opcode for Bitcoin, aiming to implement a basic and restricted smart contract to avoid the technical and social risks in previous smart contract designs. This opcode was later replaced by SECURETHEBAG, and then by CHECKTEMPLATEVERIFY, which officially became Bitcoin Improvement Proposal BIP 0119 in January 2020.
At the same time, Russell O'Connor suggested directly adding the CHECKSIGFROMSTACK and OP_CAT opcodes to Bitcoin to support smart contracts not limited by the Rubin proposal. Although this proposal faced some opposition and the discussion eventually diminished, mainly due to the inefficiency of CAT+CHECKSIG type smart contracts and the long-term negative impression people held 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 contracts, due to lack of recognition and usability, were not actually accepted by wallets and users. To prove this point, Ethan Heilman initiated a challenge on social media, encouraging people to propose viable "dark" smart contracts, but no one has succeeded to this day.
So Andrew Poelstra began to consider that people's fears of smart contracts may have been exaggerated. The article also suggests that even with concerns, smart contracts are inevitable in the development of Bitcoin, and encourages further exploration of the possibility of creating smart contracts using the non-specialized opcode OP_CAT.
2021
Next is an article by Jeremy Rubin on July 6, 2021, which discusses OP_CAT from the perspective of Bitcoin quantum security. Jeremy Rubin is not only a Bitcoin developer but also the founder of Judica, a Bitcoin research organization focused on developing the Bitcoin smart contract programming language Sapio.
In an email and a blog post, Jeremy Rubin discusses how to use the OP_CAT opcode and Lamport signatures for quantum verification of Bitcoin. The author first reviews a previous blog post on 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 proposes an idea: what if we could sign longer messages? Especially, if we could sign up to 20 bytes, we could sign a HASH160 digest that might be quantum-secure.
In the article, Jeremy Rubin further explores the implications of signing a HASH160 digest and explains the ability to reveal the private key without changing the actual signature content even if a quantum computer cracks ECDSA. For this, the author consulted cryptographer Madars Virza and received a positive response.
Jeremy Rubin points 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 actually a quantum-secure Lamport signature. Unfortunately, this method requires at least 20 consecutive bytes.
Therefore, Jeremy Rubin proposes the need for an operation similar to OP_CAT. The article explains that OP_CAT cannot directly soft fork into Segwit v0 because it would modify the stack. Therefore, to simplify, the author demonstrates how to use a new opcode, OP_SUBSTRINGEQUALVERIFY, which checks if a part of a string is equal by verifying 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 believe that OP_CAT is important in the context of Bitcoin and emphasize its potential, especially in terms of quantum security and creating complex smart contracts. For example, theoretically, combining CAT and Schnorr signature verification opcodes could enable non-recursive smart contracts. These smart contracts could directly place the SHA2 hash of transaction data onto the stack, allowing some level of restriction on various parts of the transaction.
The discussion also mentioned that reintroducing CAT could make Bitcoin more complex in some ways but could also introduce new features and possibilities. Restarting OP_CAT needs to be carefully considered to avoid past issues such as memory explosions.
2022
In the Bitcoin developer mailing list on May 18, 2022, in the discussion about reintroducing the OP_CAT opcode 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 and 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, where an opcode can analyze a part of the transaction in which it is executed. 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 a similar structure is needed to implement recursive smart contracts.
Nadav Ivgi pointed out that CAT is still needed to solve the hashing problem when creating recursive smart contracts. However, this means that features focused on output introspection, such as CTV and APO, can also be combined with CAT to create recursive smart contracts. Ivgi believes that when used in conjunction with taproot features, verifying the previous output by 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 pointed out in subsequent posts that recursive smart contracts may be secure because they are not actually Turing complete. Russell O'Connor cited Andrew Poelstra's article, describing how CAT itself can be combined with existing Bitcoin features to create non-recursive smart contracts and theoretically, if added back to Bitcoin, could also be used to create recursive smart contracts.
2023
In January, Anthony Towns launched Bitcoin Inquisition, a software that replicates Bitcoin Core and is 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 multiple proposals. Additionally, PRs for adding OP_CAT, OP_VAULT, and limiting 64-byte transactions have been submitted to its codebase, with plans to further expand the functionality of this testing platform.
On August 23, 2023, in the Lightning-Dev mailing list, Thomas Voegtlin proposed the idea of fraud proofs for outdated backup states. Voegtlin pointed out that if OP_CHECKSIGFROMSTACK (CSFS) and OP_CAT opcodes were added to Bitcoin in a soft fork, it would be possible to use such fraud proofs on-chain. The proposal sparked extensive discussion, with Peter Todd noting that the basic mechanism is general and not limited to LN, and may be useful in various protocols. However, he also proposed a simpler mechanism, which is not discussed here.
By October, Rusty Russell was researching general smart contracts with minimal changes to the Bitcoin script language. At the same time, Ethan Heilman and Armin Sabouri jointly released a BIP draft proposing to add the OP_CAT opcode, which is used to concatenate two elements on the stack. Discussions on these two topics continued into November.
2024
The time has come to January 2024, and Quantum Cats has indeed elevated the discussion of BIP and the Bitcoin process regarding OP_CAT to a new level.
In interaction with the community, Bitcoin Core developer Ava Chow once stated, "I don't think CTV is a rough consensus. I think other more general smart contract proposals are closer, such as txhash or CAT. However, I have not closely followed the discussion."
In terms of commit counts, Ava Chow (@achow101) ranks 5th in the Bitcoin Core code contributors ranking with 1292 commits, and is one of the few with merge rights to the Bitcoin code. Therefore, her influence in the development community is significant.
"I'm not suggesting we activate OP_CAT. I support OP_CAT because it is the opcode most likely to achieve consensus. If you are not familiar with the situation of OP_CAT, I have summarized it in this picture," said Eric Wall, co-founder of Taproot Wizard, @ercwl.
However, Ava Chow does not seem to express absolute approval of the implementation of OP_CAT: "As I have said before, I don't think any smart contract proposal is close to or achieves rough consensus. I don't think we should try to activate any of them."
Ten lines of code make Bitcoin smart contracts possible
As co-founder Eric Wall (@ercwl) of Taproot Wizard said, "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 a powerful tool for Bitcoin, supporting projects like BitVM, which recently introduced the concept of verifying arbitrary computations on Bitcoin, made simpler and more efficient by OP_CAT. The Bitcoin ecosystem can create more universal and expressive smart contracts.
Related reading: "How do senior developers view BitVM, which calculates anything on Bitcoin?"
Through OP_CAT, so-called smart contracts can be implemented, setting predetermined 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. Additionally, this signifies that Bitcoin is not just a payment network but can also become a versatile, scalable computing platform.
Although Taproot Wizard co-founder Eric Wall is excited about the concept behind BitVM, he believes the proposal may be a "technical dead end" for Bitcoin due to its high cost and long implementation cycle. He is concerned that BitVM may distract the community's attention and hinder real development. Nevertheless, the proposal for BitVM demonstrates the active exploration and innovation in blockchain technology and smart contract fields.
In fact, the Taproot Wizard project team is also working on implementing second-layer solutions on Bitcoin. In a previous Space session, they mentioned securing a $7.5 million funding for researching Bitcoin scaling solutions.
Therefore, the soft fork of OP_CAT is also an important step for them. Eric Wall was previously a board member of the StarkNet Foundation and has a keen interest in building decentralized finance on an unpermissioned settlement layer. When Ethereum began to emerge in 2019, he was naturally drawn to the DeFi space on Ethereum.
When it became apparent in 2019 that Ethereum and other blockchains could scale using zk-Rollups or optimistic fraud proofs, exploration of DeFi on Bitcoin was almost completely abandoned. With research questions such as "feasibility of zk-Rollup scaling applications on Bitcoin," Wall turned to supporting DeFi on Ethereum. However, he is now working to introduce these systems and technological advantages to Bitcoin.
In a bitcointalk forum discussion about OP_CAT, Carter Feldman, founder of the QED project (@cmpeq), was asked how he intends to utilize this opcode in Bitcoin scripts and whether he has calculated the average byte size of the witness stack and the potential costs.
Carter Feldman acknowledged that this could be somewhat expensive but explained that Merkle proofs in his project are primarily used to build a trustless locking 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 a zero-knowledge proof).
To address the cost issue, he mentioned that this would be a last resort. He envisioned that regular users could purchase wrapped BTC on L2 by having the seller of wrapped BTC lock their tokens on L2 for a period, during which the buyer must prove that they have paid the seller on Bitcoin L1. They know that if they wish, they can always trustlessly swap back to Bitcoin. Meanwhile, several large liquidity providers would be the main entities actually exchanging between wBTC and BTC and might charge small fees to small users who want to buy wBTC from them or bridge it back to Bitcoin.
Overall, the BIP proposal for OP_CAT, with just 13 lines of code, can help build smart contracts on Bitcoin. However, there will still be a lot of discussion and trial and error in handling the details for each project.
The TaprootWizards team member Rijndael (@rot13maxi) shared on social media the various complex mechanisms they use to create art. To achieve this, they rely on various technologies including ordinal recursion, presigned transactions, symmetric cryptography, and client-side load management. In the process of art creation, they specifically choose to use presigned transactions to execute operations, demonstrating how to pre-submit the hash value of transactions using smart contracts such as OP_CAT or CTV.
However, Armin Sabouri made a sarcastic comment: "The code and technical effort invested in creating a constantly evolving NFT collection may be 100 times the work required to re-enable a certain opcode."
OP_CAT is considered a simple and understandable opcode, with some views suggesting that it can make Bitcoin "quantum-secure" through ECDSA signature. This view has garnered some support and inspired the Taproot Wizard to launch the Quantum Cats NFT campaign to raise awareness of OP_CAT.
However, using meme culture to promote technology advancement is not limited to just OP_CAT.
Inspired by Quantum Cats and its 0.1BTC price, and perhaps with some dissatisfaction with its high price, the OP_CTV community also launched a meme called #rubinsreubens to promote OP_CTV technology.
The sandwich meme was initially a humorous response to Quantum Cats and its meme. However, it turned out to be very effective, as it, like CTV, added a hierarchy, allowing for any number of layers to be created on the "sammich" as needed.
This sandwich meme has attracted a lot of attention. 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 people's understanding of op_ctv, lnhance, and the new BTC opcode and the proposed soft fork for enabling smart contracts.
Potential Reasons for the Failure of OP_CAT
Returning to OP_CAT, there may be various reasons for opposing the introduction of features like OP_CAT. Firstly, adding new opcodes or features like OP_CAT may increase the complexity of Bitcoin, making it more difficult to understand and use securely, thus increasing risk. Secondly, security issues when introducing new features cannot be ignored, as untested features may contain vulnerabilities that compromise the overall security of Bitcoin. Additionally, an upgrade through a soft fork that is not adopted by all nodes may lead to network splits, resulting in different versions of the Bitcoin network coexisting, making consensus more complex.
New features may bring compatibility issues, especially if they do not support older nodes, potentially excluding some nodes from the network, negatively impacting the Bitcoin ecosystem. In particular, for users who have not upgraded, they may find themselves unable to continue participating in the network. Additionally, some may view the introduction of new features as a hasty decision without prioritizing addressing urgent issues in the Bitcoin core protocol. Hasty changes may introduce unnecessary risks and instability.
In addition to security and risk considerations, two major reasons for the potential failure of OP_CAT are: the Bitcoin community's fear of smart contracts and the lack of "orthodoxy" in Bitcoin smart contracts.
Fear of Smart Contracts
Fear of Bitcoin smart contracts may be another significant obstacle to the implementation of features like OP_CAT. Smart contracts play a crucial role in many blockchain projects, especially on platforms like Ethereum, but their acceptance in the Bitcoin community is relatively low. This is partly due to concerns about the risks and challenges that smart contracts may bring. Smart contracts may impact the core values of Bitcoin, such as peer-to-peer, decentralization, and security. The Bitcoin community places great importance on maintaining these core values, and any changes perceived to threaten these values may face opposition.
A major concern with smart contracts is that they may 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 fund losses, as seen in some past blockchain projects. Furthermore, the introduction of smart contracts may make the entire system more difficult to understand and audit, increasing the likelihood of errors.
Additionally, the Bitcoin community has always placed a strong emphasis on maintaining the stability and security of the network. Bitcoin's design philosophy leans towards simplicity and conservatism, prioritizing network security and decentralization. Therefore, any significant changes that may threaten network stability will undergo strict scrutiny and extensive debate. While the introduction of OP_CAT and smart contracts may bring new functionality and possibilities to Bitcoin, it may also be seen as contrary to the original vision and design philosophy of Bitcoin.
Was Satoshi Nakamoto "Wrong"?
The proposal to restore OP_CAT has sparked deep discussions in the community, partly because it touches on a sensitive issue: does this mean that Satoshi Nakamoto was wrong?
As the founder of Bitcoin, Satoshi Nakamoto's decisions and original design are revered by many as gospel, and his original vision is considered the core guide for Bitcoin's development. Therefore, any form of challenge or modification to Nakamoto's decisions may be seen as disrespectful to his legacy or a deviation from the core principles of Bitcoin. After all, orthodoxy is always an unavoidable topic in the blockchain industry.
The proposal to restore OP_CAT also touches on a broader question: should Bitcoin be a static entity or should it adapt to the constantly changing technological environment and user needs?
However, the technology field is always in a state of progress and change, and as a technological innovation, Bitcoin cannot completely escape this rule. Clearly, the Taproot Wizard team supporting the restoration of OP_CAT thinks so. After all, they intentionally designed the largest Bitcoin block in history, slightly below the 4MB limit, to release NFT Taproot Wizards.
Taproot Wizard founder Udi Wertheimer acknowledges that many people believe that Bitcoin should not change. He believes that changes to Bitcoin should be slow, cautious, and deliberate. He thinks that Bitcoin is still too young to be completely solidified and points out that the governance process is somewhat broken. While the technology community generally agrees that Bitcoin will have more upgrades, it is indeed difficult to determine specific upgrades. Nevertheless, Wertheimer emphasizes that change is necessary because the current Bitcoin cannot yet 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 is a crucial step, allowing developers to discover and resolve issues without affecting the main network.
At the same time, for the "reboot" of OP_CAT to truly happen, the entire process will take quite a long time, possibly even in years, as it involves various considerations and balances, including technical details, community consensus, considerations for the security and stability of the Bitcoin network, and most importantly, gaining widespread community support and recognition.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
