BTC Asia Conference Topic Discussion: Should OP_CAT be restored on Bitcoin?

Original author: Fu Shaoqing, SatoshiLab, Wanwudao BTC Studio

Article summary:

"Restoring OP_CAT" is a serious misunderstanding, as evidenced by an important passage in the proposal: This implementation is inspired by the original implementation of OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes" 4bd188c which disabled it:

A technical topic was discussed at the Bitcoin Asia Conference: Should the OP_CAT operation instruction be restored in the Bitcoin script language? Later, in a closed-door meeting of Wanwudao BTC Studio in Shanghai, Teacher Dashan also discussed related issues and encouraged the students of our studio to write a systematic summary article.

Why is the restoration of an instruction discussed at an industry conference? Is it so important? What issues are involved in this matter? I believe many people will have related questions.

1. Basic knowledge of OP_CAT

To understand the problem of restoring OP_CAT, we first need to understand some basic knowledge related to OP_CAT. In development languages, opcodes are also called instructions or functions, and are the basic components of development languages. In this article, we call them instructions.

1.1. What is the function of OP_CAT?

In many development languages, concat is generally used to connect two strings, so the abbreviation of OP_CAT should also come from the word concat, forming the instruction of OP_CAT.

Example 1: concat in java development language

String str1 = "Hello";

String str2 = " world"; //Note the space

String str3 = str1.concat(str2);

System.out.println(str3);

The output is Hello world

Example 2: concat in mysql

select CONCAT ("My", "SQL") from Result; the result of the execution is the display of the characters "MySQL".

In high-level development languages, concat (string concatenation) is used very frequently and is also very important in many cases. For example, some scenarios:

Data display and output:In many scenarios, we need to display or output data in the form of strings, such as connecting different data items into a complete sentence, formatting data into a specific string form, etc., at this time, we need to use string concatenation operations.

Data processing and operation:In data processing and operation, sometimes you need to concatenate multiple strings to generate a new string, such as concatenating multiple file paths into a complete path, concatenating multiple URL parameters into a complete URL, etc., which is also an important application of string concatenation operations.

If the language of Bitcoin is a high-level language, there will undoubtedly be this character connection function, but the development language of Bitcoin has some special features, so there is a dispute over whether to include this instruction. The language of Bitcoin is a scripting language in reverse Polish form, which is not Turing complete. Common types of Bitcoin script instructions:

Keywords:

1. Constants. Such as: OP_0, OP_FALSE    

2. Flow control. Such as: OP_IF, OP_NOTIF, OP_ELSE, ...

3. Stack. Such as: OP_TOALTSTACK (push the input into the item of the auxiliary stack and delete it from the main stack), ...

4. String. Such as: OP_CAT (connect two strings, disabled), OP_SIZE (push the string length of the top element of the stack into the stack (no need to pop the element))

5. Bit logic. Such as: OP_AND, OP_OR, OP_XOR

6. Arithmetic logic. Such as: OP_1ADD (input value plus 1), OP_1SUB (input value minus 1)

7. Encryption. Such as: OP_SHA1 (input uses SHA-1 algorithm HASH.), OP_CHECKSIG()

8. Pseudo keywords

9. Reserved keywords

Common types of Bitcoin script instructions:

Scripts:

1. Standard transaction that pays to a Bitcoin address (pay-to-pubkey-hash)

2. Standard Bitcoin generation transaction (pay-to-pubkey)

3. Provably unspendable/deletable output

4. Anyone-Can-Spend output

5. Guessing transaction

Five standard types of transaction scripts include: Pay to Public Key Hash (P2PKH), Pay to Public Key, Multi-Signature (limited to 15 keys), Pay to Script Hash (P2SH), and Data Output (OP_RETURN).

Detailed description at: https://en.bitcoin.it/wiki/Script

1.2. OP_CAT and other instructions deleted from Bitcoin language

In fact, the early Bitcoin script language also had the function of character connection, that is, the "OP_CAT" opcode existed at the beginning, but was deleted later. In the Bitcoin script language, OP_CAT can realize the combined connection processing of multiple UTXO unlocking script byte strings, which can improve the programmability and computational complexity of the BTC main network. However, due to Satoshi Nakamoto's consideration of security (and possibly stability), this opcode was removed from the Bitcoin protocol in August 2010.

In the Bitcoin script language, there were many instructions related to character operations at the beginning, and most of them were deleted later, including OP_CAT, OP_SUBSTR, OP_LEFT, and OP_RIGHT, and only OP_SIZE was retained. As shown in the figure below.

Not only string operation instructions were deleted, but also many other instructions.

(1) Bit operation related instructions

(2) Arithmetic operations

Why did we delete so many instructions? For details about the development and changes of Bitcoin technology, readers can read "Summary of New Technology Developments that Led to the Re-Explosion of Bitcoin".

2. Why do some people want to "restore OP_CAT"?

Many people on the Internet are saying that Bitcoin needs to "restore OP_CAT", which is a serious misunderstanding of this matter. But we do need a character concatenation function like OP_CAT, and we need to add a similar function to Tapscript, so we need to "restore OP_CAT".

2.1. The proposal to "restore OP_CAT" and the misunderstanding of the public

Before introducing the relevant content, we need to understand BIP first. BIP is the abbreviation of Bitcoin Improvement Proposal, which is directly translated as: Bitcoin Improvement Proposal. It contains the following states, and the state transitions between them are shown in the figure below:

In October 2023, Bitcoin Core developer Ethan Heilman and Botanix Labs Chief Software Engineer Armin Sabouri jointly launched a draft Bitcoin Improvement Proposal (BIP) called "OP_CAT", which brought this discussion to a new level. Detailed proposal content, please visit: https://github.com/bip420/bip420

The new script (12 lines) of the Tapscript proposal is as follows

There is also an important sentence in the proposal: This implementation is inspired by the original implementation of OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes" 4bd188c which disabled it:

The referenced original Bitcoin script code (13 lines) is as follows:

The BIP420 draft contains only 12 concise lines of program code (very similar to the original BTCscript), but carries clear and intuitive functional properties, defins a new Tapscript opcode that allows two values to be concatenated on the stack. This opcode implementation is clearly inspired by the original deleted OP_CAT. This text is marked by me in different colors to emphasize that it is not to restore the relevant instructions in Bitcoin's original instructions, but to re-implement a similar instruction in Tapscript, an extension of Taproot.

Restoring certain instructions in Bitcoin's instructions and generating new instructions in Tapscript are different concepts with different scopes of influence.

2.2. Which functions or applications need to restore OP_CAT

To fully understand this problem, two parts of knowledge are required:

(1) In Section 1.1, we already know that concatenation is a very common and important function in programming languages. This function is required in high-level development languages or programming languages with richer functions. With this consensus, and knowing the changes in Bitcoin, we will understand the fundamental reason for restoring OP_CAT.

Currently, some teams and project owners who want to develop functions on the Bitcoin mainnet are very eager to restore this instruction. With this instruction, more powerful smart contracts can be implemented (Bitcoin has smart contracts, but they are not Turing complete). The addition of this function will support many other innovative methods that rely on smart contracts, and can also develop Bitcoin from a network that only provides payment services to a more functional and scalable computing platform.

(2) Bitcoin is ready for expanded functions through Taproot. Here we need to understand some knowledge in detail: Taproot, MAST, Taproot Scripts. It is best to read "Summary of New Technology Developments that Caused Bitcoin to Explode Again" to understand the underlying changes in Bitcoin technology.

Bitcoin technology expands the function of Bitcoin's OP_RETURN through Segregated Witness Segwit, which directly expands the actual storage space of Bitcoin, and the maximum block size can reach 4M. These expanded spaces are currently used by people in large quantities to store text or pictures, but the designer's purpose is to expand the function of Bitcoin. Because in order to expand the functions, several BIP protocols BIP340, BIP341 and BIP342 were generated. Among them, BIP340 introduced Schnorr signatures that can verify multiple transactions at the same time, replacing the elliptic curve digital signature algorithm (ECDSA), once again expanding the network capacity and speeding up the processing of batch transactions, providing the possibility of deploying complex smart contracts; BIP341 implemented the Merkle Abstract Syntax Tree (MAST) to optimize the storage of transaction data on the blockchain; BIP342 (Tapscript) uses Bitcoin's script coding language to expand the insufficiency of Bitcoin's native script capabilities.

The expansion of the space of Segregated Witness Segwit and Taproot led to the generation of Schnorr, MAST tree and TapScripts, and their mission is to expand the functions of the Bitcoin main network. 4M storage space can store a large amount of program code. As long as the functions of Tapscript are powerful enough, a lot of applications can be developed. However, Tapscript has just been born, and many instructions are not perfect enough, and there will be a situation where the functions of Tapscript instructions are gradually expanded.

3. The status and role of Bitcoin protocol in Web3.0

Even if we understand the content and reasons of the proposal to restore OP_CAT in Section 2, how do we judge such events? Because not only OP_CAT needs to be added, Tapscript will also add other instructions. What are the basic principles for mastering this addition? We also need to look at Bitcoin from a more macro perspective.

3.1. Application architecture and layered protocol design ideas of Web3.0

In the article "Observing Bitcoin Layer 2 from the perspective of state machine, we can see the architecture and construction path of future Web3.0 applications", we have roughly outlined the application architecture of Web3.0, as shown in the following figure:

We can see that blockchain is an important infrastructure in Web3.0, and only the Bitcoin network is suitable as the bottom infrastructure in the layered structure. This is why it is said that blockchain "starts with Bitcoin and ends with Bitcoin ecology", and all other blockchain systems are generalized second-layer or testing technologies of Bitcoin.

After understanding the application architecture of Web3.0, we also need to understand some layered design ideas (especially the characteristics that the bottom layer should have). Layered design is a means and methodology for humans to deal with complex systems. By dividing the system into multiple hierarchical structures and defining the relationship and functions between each layer, the modularity, maintainability and scalability of the system can be achieved, thereby improving the design efficiency and reliability of the system. We use existing cases to illustrate, such as the TCP/IP protocol in the figure below:

At the bottom layer of the protocol, the TCP protocol and the IP protocol only need to implement the simplest and most basic functions. Those application layer protocols, such as FTP, SMTP, IMAP, HTTP, etc., are implemented at a high level and will be encapsulated in the TCP protocol and the IP protocol.

If Bitcoin is the lowest-level protocol similar to the TCP/IP protocol, then the Bitcoin mainnet should also maintain the simplest and most basic functions in principle. Those rich functions, especially the application layer functions, need to be implemented on the second or third layer protocol of Bitcoin. With this principle, we will have an accurate judgment on the clear bottom-level protocol and upper-level protocol, so how should we judge the extended functions implemented on the Bitcoin mainnet like Tapscript?

3.2. Two philosophies of doing things: over-design and just enough

In order to increase the accuracy of our judgment, we first understand two philosophies of doing things: overdesign and just enough. (Perhaps it is useless for us to know this, because the development decision of Bitcoin is determined by many factors. Bitcoin's decentralized culture makes its development determined by many factors, or by the collective thinking of human beings.)

Overdesign and just enough are two different philosophies of doing things, and they each have different advantages and disadvantages. The following are their advantages and disadvantages and some examples:

(1) Overdesign

Advantages of overdesign:

Strong scalability:Overdesign usually takes into account future changes in demand and can cope with various expansions and changes.

More flexible:Overdesigned systems can adapt to various situations and needs and have higher flexibility.

Improve long-term efficiency:Many functions can be developed by calling the underlying system in the later stage, and efficiency is improved in the long run.

Disadvantages of over-design:

Time-consuming:Over-design requires more time and resources to complete, which may cause project delays.

Resource waste:Over-design may introduce redundant functions or complex structures, wasting resources.

Possible over-complexity:Over-design may cause the system structure to be too complex, increasing the difficulty of system maintenance and understanding.

Over-design applicable scenarios (some of my personal experience summary and reference to some of ChatGPT):

Over-design is usually applicable to non-new projects, there are examples to refer to, and the initial requirements of new cases are relatively few or not clear enough, but it is expected that the requirements may change frequently, so we can draw on existing experience and use the principle of over-design to a certain extent. For example, the bottom layer of a large software system or platform can consider over-design.

(2) Just enough

Advantages of Just enough:

Simple and clear:The idea of just enough focuses on solving current needs, keeping the system simple and easy to understand.

Resource conservation:The idea of just enough avoids over-design and unnecessary functions, saving time and resources.

Fast delivery:The idea of just enough can quickly deliver usable products or systems to meet the basic needs of users.

Disadvantages of "just enough":

Unable to adapt to changes:The idea of "just enough" may not be able to adapt to future changes in demand and requires major modifications and adjustments.

Poor scalability:The idea of "just enough" may lead to a lack of scalability in the system and difficulty in adding new functions and components.

Applicable scenarios of "just enough": There are no examples to refer to for the project to be implemented, or there are very few examples to refer to, and the direction and destination of development are unknown. You can adopt the "just enough" approach. There are also small projects that are completely applicable to the idea of "just enough". For innovative projects, this principle is often adopted because the future is completely unclear.

Overdesign and "just enough" are not opposing concepts, but different orientations of a way of thinking. Most of the native scripts of Bitcoin, BTCscript, adopt the "just enough" principle, but Tapscript is an extension of the native script, which can refer to some programming scenarios and be slightly overdesigned. We also need to consider the use of Taproot and Tapscript. They are only the connection technology between the first layer and the second layer. They should not be overused, and should even be limited to the functions on Tapscript. In this way, we have found the lower and upper limits of Tapscript design.

3.3. The brilliant future of Web3.0 (next generation Internet)

In Section 3.2, we expressed that the instruction design of Tapscript can be appropriately over-designed, but the upper limit is to meet the needs of connecting Bitcoin's first and second layers. However, in the early days, especially when the price of Bitcoin was not too high (each simple transaction execution did not exceed $100, which was considered not too high) and the second or third layers of the distributed system were not mature, many people would still develop too many functions, which may cause Tapscript to contain too many instructions.

On the other hand, as the infrastructure of the entire Web3.0, blockchain technology and related layered construction should not develop too many functions for Bitcoin's Tapscript technology. Refer to the application architecture diagram of Web3.0 in Section 3.1.

In "Observing Bitcoin Layer 2 from the perspective of the state machine, we can see the architecture and construction path of future Web3.0 applications" we learned about the rich applications of Web2.0 through the statistical report on the development of China's Internet. In the statistical report, we can see that the applications in Web2.0 are already very rich and have a huge user base. These applications include: instant messaging, online video, short video, online payment, online shopping, search engines, online news, online music, online live broadcast, online games, online food delivery, online literature, online car-hailing, online office, online travel reservations, online education, online medical care, etc., covering almost all areas of people's lives. In addition to these consumer Internet contents, there are also many applications in the industrial Internet.

User scale and usage rate of various Internet applications

These mainstream applications have not yet entered the Web3.0 world. When these applications enter the Web3.0 era, the user scale and performance requirements will be higher. Therefore, the task undertaken by the Bitcoin main network in the future is very heavy, so it is necessary to use a layered structure to establish a real Web3.0 world. Then the functions on the Bitcoin main network are mainly simple and stable, and mainly serve the connection technology between the first layer and the second layer. I personally advocate not to overuse the connection technology between the first layer and the second layer of Bitcoin, and give Tapscript an expansion space, but not too many functions.

4. Who has the right to decide whether to restore OP_CAT

Through the previous content, we know the real content of this proposal, which is to generate a command function similar to OP_CAT in Tapscript, rather than restore the original OP_CAT in the Bitcoin script. Who has the decision-making power for this proposal? Bitcoin Core development team? Miners? Ecosystem developers? Community?

If we analyze from the perspective of interests, the OP_CAT instruction generated in Tapscript will increase the programmability of the Bitcoin mainnet, and will generate more Bitcoin mainnet programs and applications, which will increase the handling fees on the mainnet. Miners will be the most active supporters, and ecosystem developers will also support it because it increases the possibility of development.

What does the Bitcoin Core team think? The Core team has always been conservative. Will they agree? There is a lot of uncertainty. In fact, this incident also involves a larger problem. For the development of Tapscript, a set of rules needs to be formulated. It is different from the BTCScript of the Bitcoin mainnet. Should the decision-making be appropriately relaxed? Bitcoin's BIP protocol refers to Ethereum's EIP protocol. It may be a good way to classify the proposals. Different review standards are used for each proposal.

Through the arrangement of this article, I personally judge that this proposal will eventually be passed, otherwise the function of Tapscript will be too weak, and the process may be a bit tortuous.

In the world of Bitcoin, because there is no authority, power is not a direct influencing factor in the world of Bitcoin. Only economic factors will be the decisive influencing factors. What will be passed is ultimately driven by the interests of the majority. Even if Tapscript is over-designed, it will be corrected by economic factors during use.

References

1. BIP Draft 420: OP_CAT, https://github.com/bip420/bip420.

2. https://en.bitcoin.it/wiki/Script

3. "Summary of New Technology Developments Leading to Bitcoin's Re-Explosion"

This article is from a contribution and does not represent the views of BlockBeats.

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia