13 lines of code to help Bitcoin implement smart contracts? Understanding OP_CAT soft fork
Written by Jaleel, BlockBeats
In the Bitcoin code base, an operation code "OP_CAT" that was once deleted by Satoshi Nakamoto and has been forgotten by history for a long time may be "resurrected".
Around the OP_CAT opcode, the Bitcoin NFT project Taproot Wizards launched a new series of NFT Quantum Cats, which caused a stir.CommunityAlthough the name OP_CAT does not refer to the "cat" we are familiar with, Taproot WiXiaobai NavigationHowever, zard used the image of a cat to release a new NFT called Quantum Cats, using meme culture to help build momentum for OP_CAT.
OP_CAT, an opcode that was once removed from the Bitcoin script language by Satoshi Nakamoto, has now been brought back to the table for discussion. Some Bitcoin developers want to "revive" this opcode and implement smart contract for Bitcoin through a soft fork of 13 lines of code.contractUnder the promotion of Bitcoin developers and the promotion of cat memes, the popularity and discussion about OP_CAT reached new heights.
"Resurrection" the opcode deleted by Satoshi Nakamoto
Opcodes, also known as instructions or functions, are the basic elements of the Bitcoin scripting language. Historically, some opcodes were removed from early versions of Bitcoin due to concerns about possible vulnerabilities in client implementations, and the OP_CAT opcode was one of them.
OP_CAT was originally part of the official Bitcoin command set, allowing string concatenation operations to join two elements into one. However, due to serious vulnerabilities found in opcodes such as OP_LSHIFT that could cause any Bitcoin node to crash, and concerns that the OP_CAT opcode could cause the stack elements to grow exponentially, which could cause memory usage to grow exponentially with the 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 because they are completely removed from the protocol, making them unusable by anyone using Bitcoin.
In October 2023, Bitcoin Core developer Ethan Heilman and Botanix Labs chief software engineer Armin Sabouri jointly released a draft Bitcoin Improvement Proposal (BIP) called "OP_CAT", which brought the discussion to a new level.
This draft, containing only 13 concise lines of code, yet carrying a clear and intuitive functional nature, defines a new tapscript opcode that allows concatenation of two values on the stack. This code implementation is clearly inspired by the original deleted OP_CAT.
The conditions for resurrection have been met
As for why an opcode deleted by Nakamoto is now wanted by developers to be restored, the motivation section of this BIP draft provides some detailed explanations: This is mainly based on considerations of memory usage. OP_CAT makes the memory usage of script construction likely to grow exponentially with the size of the script itself. Specifically, a simple script, by only pushing a 1-byte value into the stack, then duplicating it using the OP_DUP opcode, and then concatenating it 40 times using the OP_CAT opcode, can cause the stack value to swell to a huge size of over 1TB.
However, with the advancement of time and technology, this problem is no longer an obstacle. Under the architecture of tapscript, a clear rule is established that the size of stack elements is strictly limited to 520 bytes. This change effectively solves the memory usage problem that OP_CAT may cause, and provides the possibility of its "resurrection" and integration.
It can be seen that OP_CAT has been discussed again and considered for restoration, mainly because of its potential value in building more complex and powerful scripts. In addition, some reasons and changes have met the conditions for "resurrection", including:
1. The need for advanced smart contracts and protocols: As the Bitcoin ecosystem grows, the need for more advanced and complex smart contracts and protocols increases. 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, supporting tree signatures, post-quantum Lamport signatures, non-repudiation contracts, vaults, and other functions.
2. Successful cases on other chains: Some Bitcoin forks, such as Bitcoin Cash and the sidechain Liquid, have re-enabled OP_CAT and used it to implementTokenCreation and management of payment channels andBlockchainThis shows that under the right circumstances and constraints, OP_CAT canSafetyUse effectively.
3. QuantumSafetyExploration of the potential: Some studies have suggested that if operations such as OP_CAT can be used, combined with technologies such as Lamport signatures, quantumSafetyBitcoin transactions and protocols. This exploration is important for improving the future of the Bitcoin system.SafetySex has potential value.
4. Community和技术发展：比特币社区和技术的持续发展促使人们重新考虑和评估以前的决定。随着对比特币协议更深入的了解和新技术的出现，之前被认为有问题或不适用的功能可能会在新的上下文中找到安全和有用的应用场景。
Soft fork, easier said than done
On a technical level, few other Bitcoin proposals are as easy to interpret and understand as OP_CAT. But the OP_CAT opcode will be activated via a soft fork that redefines the opcode OP_SUCCESS126, which is obviously not an easy task.
Looking back at Bitcoin’s most recent soft fork, which occurred three years ago, the activation of Taproot paved the way for the birth of Ordinals.
The Bitcoin community highly values 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 Bitcoin codebase, it must go through a rigorous and detailed process that ensures the quality of the proposal and the consensus of the community. The following are the main steps of this process:
1. Write a proposal and code: First, developers need to write a detailed proposal document. This document should clearly describe the motivation, technical details, impact assessment, and any potential problems or challenges of the proposal.
2. Community Discussion: After a code proposal is submitted to the Bitcoin community, community members (including developers, miners, investors, and users) will discuss and review it. This stage is key to ensuring the feasibility of the proposal and collecting feedback.
3. Modifications and improvements: Based on community feedback, the author of the code may need to modify and improve the proposal.
4. Voting and reaching consensus: For some important improvements (especially those involving changes to the Bitcoin protocol itself), a certain degree of consensus among community members is required. This usually involves the support of miners, who need to indicate their support for the proposal by including specific signals in the blocks they mine.
5. Code Implementation: Once consensus is reached, the code will be reviewed by the Bitcoin Core developer team. This step is required to ensure the quality and security of the code.
6. Merge into the code base: After passing the review, the code will be merged into the official Bitcoin code base.
7. Deployment and Activation: The new code needs to be deployed to their systems by miners and node operators. For protocol-level changes, there is usually an activation threshold, and improvements will only take effect when enough network participants upgrade to the new version.
Obviously, the implementation of the OP_CAT soft fork is still in a very early stage. It has been less than four months since the BIP draft was written. The BIP number has not yet been determined. It is still in the first stage of writing proposals and codes and the second stage of community discussions including developers and users.
What Bitcoin Developers Say
Let’s first pay special attention to the discussions on OP_CAT among Bitcoin developers in recent years.
Despite the removal of the OP_CAT opcode, the potential utility of OP_CAT in facilitating advanced contracts and enhancing the Bitcoin scripting language has been discussed repeatedly among developers. For example, its ability to concatenate stack values has been cited as an obstacle to the development of certain Bitcoin protocols, such as TumbleBit, whose transaction size could be greatly reduced if OP_CAT was supported.
After scouring the Optech newsletter and various related content, I have compiled some of the discussions of the OP_CAT opcode among Bitcoin developers in chronological order.
2019
Ethan Heilman, one of the initiators of the draft "OP_CAT" Bitcoin Improvement Proposal (BIP), said in an email in October 2019 that he understood why it was removed - because the situation faced by the script was extremely serious at the time, but he also emphasized that OP_CAT, as an opcode, should not be ignored: "Most protocols that want to be built on Bitcoin currently encounter a limitation: stack values cannot be connected. As a researcher, if I encounter this limitation, it is likely to hinder the progress of others. If I could wave a magic wand to re-enable one of the disabled opcodes, 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."
Andrew Poelstra is a person who can never be avoided in the discussion about OP_CAT. He wrote an article titled "CAT and Schnorr Tricks I" on January 30, 2021, which sparked a discussion about OP_CAT. Andrew Poelstra is the director of research at Blockstream and a senior Bitcoin cryptography script developer. His influence in the industry is self-evident.
In the article, Andrew Poelstra introduced: "OP_CAT helps combine two elements in the stack and push the combined result back to the stack. This function can be used to assemble multiple small elements into a large element, or decompose a large element into multiple small elements. CHECKSIGFROMSTACK (CSFS) is an opcode that has never been seen in Bitcoin. It allows users to verify the signature of arbitrary data, which is different from the CHECKSIG opcode that can only verify the transaction signature."
More importantly, he points out that combining OP_CAT with CHECKSIGFROMSTACK can provide a clever way to introspect transactions.
Note: Transaction introspection refers to the ability to inspect and analyze the various components of a transaction itself in a Bitcoin script. In simple terms, it allows the script to "understand" and process the details of the transaction it is processing, such as checking the output content, amount, or specific signature of the transaction. In this way, the script can respond more intelligently and carefully based on the specific content of the transaction.
In this way, the user provides the data of the entire transaction on the stack, and the script uses OP_CAT to package this data into a single item, hash it, and then pass 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 real transaction data. In this way, the script can directly use this data to perform any checks required by the contract.
Andrew Poelstra’s influence, and the idea for this article, caught the attention of Bitcoin developers, and at meetings that week, there was a lot of discussion about this combination of opcodes and how making minor changes to the scripting language after taproot was activated would increase contract flexibility.
About two weeks after the release of "CAT and Schnorr Tricks I", Andrew Poelstra published the second article "CAT and Schnorr Tricks II". In this article, Andrew Poelstra described more details and his ideas:
In May 2019, Bitcoin developer Jeremy Rubin proposed Bitcoin's CHECKOUTPUTSHASHVERIFY opcode, with the goal of implementing a basic but limited smart contract that avoids the technical and social risks in previous smart contract designs. This opcode was later replaced by SECURETHEBAG, and then by CHECKTEMPLATEVERIFY, which officially became the Bitcoin Improvement Proposal BIP 0119 in January 2020.
Meanwhile, Russell O'Connor suggested adding CHECKSIGFROMSTACK and OP_CAT opcodes directly to Bitcoin to support smart contracts that are not restricted by Rubin's proposal. Although the proposal was met with some opposition and discussion gradually waned, mainly due to the inefficiency of CAT+CHECKSIG type smart contracts and the long-standing negative impression people had on comprehensive general smart contracts.
Andrew Poelstra was also reluctant to support the so-called Bitcoin smart contract feature at first. However, in the fall of 2019, a private conversation with Ethan Heilman changed his mind. Ethan Heilman pointed out that despite the concerns, smart contracts that are considered harmful can actually be implemented through CHECKMULTISIG, and such contracts are not actually used due to lack of recognition and availability.walletand user acceptance. To prove this, Ethan Heilman launched a challenge on social media, encouraging people to come up with viable "dark" smart contracts, but no one has succeeded so far.
So Andrew Poelstra turned to thinking that everyone's fear of smart contracts may be exaggerated. The article also suggested that even if there are concerns, smart contracts are inevitable in the development of Bitcoin, and encouraged to continue exploring the possibility of creating smart contracts using non-dedicated opcodes OP_CAT.
2021
Next is an article by Jeremy Rubin on July 6, 2021, which explains OP_CAT from the perspective of Bitcoin quantum security. Jeremy Rubin is not only a Bitcoin developer, but also the founder of Judica, a Bitcoin R&D organization focused on developing Sapio, Bitcoin's smart contract programming language.
In an email and blog post, Jeremy Rubin discusses how to use the OP_CAT opcode and Lamport signatures to quantum-proof Bitcoin. The author first reviews a previous blog post that describes a method for registering 5-byte values using Bitcoin script arithmetic and Lamport signatures. Although this method is neat, it has its limitations. Jeremy Rubin proposed an idea: what if we could sign longer messages? In particular, if we can sign up to 20 bytes, we can sign a HASH160 digest that may be quantum-safe.
Jeremy Rubin further explored the meaning of signing with HASH160 digests in the article, and explained that even if a quantum computer cracks ECDSA, it will only leak the private key without changing the actual signature content. For this, the author consulted cryptographer Madars Virza and got a positive answer.
Jeremy Rubin pointed out that if we require ECDSA signatures to be signed with a quantum-proof signature algorithm, we can have quantum-proof Bitcoin. And the 5-byte signature scheme discussed earlier is actually a quantum-safe Lamport signature. But unfortunately, this method requires at least 20 consecutive bytes.
Therefore, Jeremy Rubin proposed that some kind of OP_CAT-like operation is needed. The article explains that OP_CAT cannot be directly soft-forked to Segwit v0 because it would modify the stack. Therefore, to simplify, the author shows 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, as speakers, discussed a proposal to re-enable the opcode OP_CAT. They believed that OP_CAT was important in the context of Bitcoin and emphasized its potential, especially in terms of quantum security and making complex smart contracts. For example, combining CAT and Schnorr signature verification opcodes, non-recursive smart contracts can theoretically be implemented. Such smart contracts are able to put the SHA2 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 reintroducing CAT could complicate Bitcoin in some ways, while also introducing new features and possibilities. Restarting OP_CAT needs to be carefully considered to avoid problems that have occurred in the past, such as memory explosion issues.
2022
In a discussion on the Bitcoin developer mailing list on May 18, 2022 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 a contract can only be spent on the same contract.
Recursive smart contracts rely on transaction introspection, i.e., an opcode can analyze a portion of the transaction in which it is executed. Existing opcodes provide limited introspection. In order to create a recursive smart contract, it is necessary to ensure that the previous output and the next output are the same. Therefore, either the previous output, the next output, or both must be dynamically constructed from their constituent elements, which is why CAT or similar structures are needed to implement recursive smart contracts.
Nadav Ivgi pointed out that CAT is still needed to solve the hash problem when creating recursive smart contracts, but this means that functions such as CTV and APO, which focus on output introspection, can also be combined with CAT to create recursive smart contracts. Ivgi believes that when combined with the functionality of taproot, verifying 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 pointed out in a follow-up post that recursive smart contracts may be safe because they are not actually Turing complete. Russell O’Connor cited Andrew Poelstra’s article, describing how CAT itself, combined with existing Bitcoin functionality, is sufficient to create non-recursive smart contracts, and in theory, if added back to Bitcoin, it may also be able to create recursive smart contracts on its own.
2023
In January, Anthony Towns launched Bitcoin Inquisition, a fork 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 multiple proposals, and PRs (pull requests) for OP_CAT, OP_VAULT, and limiting 64-byte transactions have been submitted to its codebase, which is expected to further expand the functionality of this test platform.
On August 23, 2023, in the Lightning-Dev mailing list, Thomas Voegtlin proposed an idea for fraud proofs for expired backup states. Voegtlin pointed out that if OP_CHECKSIGFROMSTACK (CSFS) and OP_CAT opcodes were added to Bitcoin as a soft fork, it would be possible to use such fraud proofs on-chain. The proposal sparked a lot of discussion, with Peter Todd noting that the basic mechanism is general, not limited to LN, and may be useful in various protocols, but he also proposed a simpler mechanism that will not be discussed here.
In October, Rusty Russell conducted research on general smart contracts for the Bitcoin Script language that made changes. At the same time and very importantly, Ethan Heilman and Armin Sabouri jointly published 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
Now it is January 2024, and Quantum Cats has indeed succeeded in bringing the discussion about OP_CAT’s BIP and Bitcoin progress to a new level.
In an interaction with the community, Bitcoin Core developer Ava Chow once 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 haven’t been following the discussion closely.”
Sorted by number of submissions, Ava Chow (@achow101) is currently ranked fifth among Bitcoin Core code contributors, with 1,292 code submissions. She is also one of the few people who has the right to merge Bitcoin code. Therefore, she has a great influence in the development community.
“I’m not suggesting that we activate OP_CAT. I support OP_CAT because it’s an opcode that has a very high probability of reaching consensus. If you don’t know what’s going on with OP_CAT, I summarized the situation in this picture,” said Eric Wall (@ercwl), co-founder of Taproot Wizard.
However, Ava Chow did not seem to express absolute approval of the implementation of OP_CAT: "As I have said, I don't think any smart contract proposal is close to or has reached a rough consensus. I don't think we should try to activate any of them."
Ten lines of code to make Bitcoin a smart contract
As Taproot Wizard co-founder Eric Wall (@ercwl) said: “People don’t realize this, but OP_CAT is actually one of the building blocks for zkrollups on Bitcoin.”
The reintroduction of OP_CAT provides Bitcoin with a powerful tool that can support projects like BitVM, whose recently launched concept of verifying arbitrary computations on Bitcoin will become much simpler and more efficient with OP_CAT. The Bitcoin ecosystem is able to create more general and expressive smart contracts.
OP_CAT makes it possible to implement so-called smart contracts, which set pre-defined conditions for specific Bitcoin outputs. This not only opens the door to new extension methods, such as Blockstream's Ark, but also supports many other innovative methods that rely on smart contracts. In addition, this marks that Bitcoin is not just a payment network, but can also become a versatile and scalable computing platform.
Although Taproot Wizard co-founder Eric Wall is excited about the concept behind BitVM, he believes that the proposal may be a "technical dead end" for Bitcoin because of its huge cost and long implementation cycle. He is worried that BitVM may distract the community and hinder real development. Nevertheless, the proposal of BitVM still shows thatBlockchainActive exploration and innovation in the field of technology and smart contracts.
In fact, the Taproot Wizard project team is also working on implementing a second-layer solution on Bitcoin. In a previous Space, they also stated that the $7.5 million in financing they have completed will be used to study Bitcoin expansion solutions.
Therefore, the soft fork of OP_CAT will also be an important step for them. Eric Wall was once a member of the board of directors of the StarkNet Foundation. He has a great interest in building decentralized finance on a permissionless settlement layer, so when Ethereum began to emerge in 2019, he was naturally attracted to the DeFi field on Ethereum.
When it became clear in 2019 that Ethereum and otherBlockchainBitcoin’s exploration of DeFi has been almost completely abandoned when it can be expanded through the use of zk-Rollups or optimistic fraud proofs. With research on issues such as “the feasibility of zk-Rollup expansion applied to Bitcoin”, Wall turned to supporting DeFi on Ethereum. But in the end, he is working hard to introduce this system and these technical advantages to Bitcoin.
Additionally, in a discussion thread on the bitcointalk forum about OP_CAT, Carter Feldman (@cmpeq), founder of the QED project, was asked how he intends to utilize this opcode in Bitcoin Script and if he had calculated the average size of the witness stack in bytes and the fees that might be incurred.
Carter Feldman acknowledged that this might be a bit expensive, but explained that Merkle proofs are primarily used in his project to build a trustless locking script or hook system as part of the second layer of zk on Bitcoin. This system aims to prove that a given withdrawal tree root (asZero knowledge proofA certain amount of Bitcoin can be withdrawn to a specific address under the condition of a public input.
In order to solve the cost problem, he mentioned that this would be a means. He envisioned that ordinary users could get their Bitcoins wrapped by sellers at L2 Lock them onTokenA period of time to buy wrapped BTC on the second layer, during which time the buyer must prove that they have paid the seller on Bitcoin L1. They know that they can always trustlessly exchange back to Bitcoin if they want. At the same time, a few large liquidity providers will become the actual exchange between wBTC and BTC, and may charge small fees to small users who want to buy wBTC from them or bridge it back to Bitcoin.
So in general, OP_CAT's BIP proposal can help build smart contracts on Bitcoin with only 13 lines of code, but as for the specific details of each project, there will still be a lot of discussion and trial solutions.
Meme culture promotes technology advancement
Rijndael (@rot13maxi), a member of the TaprootWizards team, shared on social media the various complex mechanisms they used to create artworks. To achieve this goal, they relied on a variety of techniques, including ordinal recursion, pre-signed transactions, symmetric cryptography, and client load management. In the process of art creation, they specifically chose to use pre-signed transactions to perform operations, showing how to use smart contracts such as OP_CAT or CTV to pre-submit the hash of the transaction.
But Armin Sabouri made a cynical comment: “The code and technical effort invested in creating an evolving collection of NFTs is probably 100 times the amount of work required to re-enable an opcode.”
OP_CAT is considered a simple and easy-to-understand opcode, and there is a view that it can make Bitcoin "quantum safe" by signing ECDSA signatures. This view has been supported by some people and inspired Taproot Wizard to launch the Quantum Cats quantum cat NFT promotional activities to raise awareness of OP_CAT through these activities.
However, OP_CAT is not the only one using meme culture to promote technological advancement.
Inspired by Quantum Cats and its selling price of 0.1BTC, and perhaps with some dissatisfaction 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 out as a humorous response to Quantum Cat and his memes. However, it actually works really well because, like CTV, it adds layers, 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 fun and can be used to show support for something, but it is also important to understand the meaning behind it. #rubinsreubens aims to increase people's understanding of op_ctv, lnhance, and the soft fork proposal for new BTC opcodes and smart contract-enabled.
Potential reasons for OP_CAT failure
Coming back to OP_CAT, people may oppose the introduction of features like OP_CAT for a number of reasons. First, adding new opcodes or features like OP_CAT may increase the complexity of Bitcoin, making it more difficult to understand and use safely, increasing the risk. Secondly, the security issues when introducing new features cannot be ignored. Features that have not been fully tested may contain vulnerabilities that undermine 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 it more complicated to reach consensus.
New features may bring compatibility issues, especially if they do not support older versions of nodes, which may exclude some nodes from the network and have a negative impact on the Bitcoin ecosystem. Especially for those users who have not upgraded, they may find themselves unable to continue participating in the network. In addition, some people may think that the introduction of new features is a hasty decision without giving priority to solving urgent problems in the Bitcoin core protocol. Hasty changes may introduce unnecessary risks and instability.
In addition to security and risk considerations, two major reasons why OP_CAT will fail are: the Bitcoin community’s fear of smart contracts and the lack of “legitimacy” of Bitcoin smart contracts.
Fear of smart contracts
Fear of Bitcoin smart contracts may be another important obstacle to implementing OP_CAT.BlockchainA core component of the technology, it plays a vital role in many blockchain projects, especially on platforms such as Ethereum.
However, in the Bitcoin community, smart contracts have relatively low acceptance, partly due to concerns about the risks and challenges that smart contracts may bring. Smart contracts may affect the core values of Bitcoin, such as peer-to-peer, decentralization, and security. The Bitcoin community takes maintaining these core values very seriously, and any changes that are considered to threaten these values are likely to be opposed.
A major concern about 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 errors or vulnerabilities may lead to serious security issues and may even lead to large-scale financial losses, 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, thereby increasing the possibility of errors.
In addition, the Bitcoin community has always attached great importance to maintaining the stability and security of the network. Bitcoin's design philosophy tends to be simple and conservative, prioritizing the security and decentralization of the network. Therefore, any major changes that may pose a threat to the stability of the network will be subject to strict scrutiny and extensive debate. The introduction of OP_CAT and smart contracts, although it can bring new features and possibilities to Bitcoin, may also be seen as running counter to Bitcoin's original vision and design philosophy.
Was Satoshi Nakamoto "wrong"?
The restoration of the OP_CAT opcode has sparked deep discussion in the community, in part because it touches on a sensitive topic: Does this mean Satoshi Nakamoto was wrong?
As the founder of Bitcoin, Satoshi Nakamoto's decisions and original designs are regarded as the Bible by many people, and his original vision is considered the core guide for the development of Bitcoin. Therefore, any form of challenge or modification to Satoshi Nakamoto's decisions may be regarded as disrespect for his legacy or a deviation from the core principles of Bitcoin. After all, in the blockchain industry, orthodoxy is always a topic that cannot be avoided.
The proposal to reinstate OP_CAT therefore touches on a broader question: Should Bitcoin be a static entity, or should it adapt to changing technological circumstances and user needs?
However, the technology field is always in constant progress and change. As a technological innovation, Bitcoin cannot completely escape this rule. Apparently, the Taproot Wizard team that supports the restoration of OP_CAT thinks so. After all, they have intentionally designed the largest Bitcoin block ever, slightly below the Bitcoin 4MB limit, to release NFT Taproot Wizards.
Udi Wertheimer, founder of Taproot Wizard, said he understands that many people think Bitcoin should not change. He believes that changes to Bitcoin should be slow, cautious, and thoughtful. He believes that Bitcoin is too young to be fully solidified, and pointed out that the governance process is broken to some extent. Although the technical community generally agrees that Bitcoin will have more upgrades, it is indeed difficult to determine which specific upgrades will be. Nevertheless, Wertheimer emphasized that change is necessary because the current Bitcoin cannot provide services for billions of people.
Of course, such changes are also accompanied by risks and challenges, such as security issues, network split risks, compatibility issues, etc., which all need to be carefully considered and resolved.
It is foreseeable that, in order to ensure that the proposed improvements are safe and effective, deploying OP_CAT in a test network environment is a crucial step, allowing developers to discover and solve problems without affecting the main network.
At the same time, if we want to truly realize the "restart" of OP_CAT, the whole process will take quite a long time, even years, because it involves many considerations and balances, including technical details, community consensus, and considerations of the security and stability of the Bitcoin network, as well as, most importantly, broad community support and recognition.
The article comes from the Internet:13 lines of code to help Bitcoin implement smart contracts? Understanding OP_CAT soft fork
Based on the future macro environment and market conditions, the Bitcoin ecosystem will have a good development prospect. Written by: Bitget Research Institute Abstract Entering 2023, the Bitcoin wealth effect is obvious, rising from $16,500 at the beginning of the year to $42,000. In addition to Bitcoin itself, market funds have also overflowed into its ecosystem. The most obvious case is Or…
相关文章
