Summary of new technological developments that led to Bitcoin’s …

Summary of new technological developments that led to Bitcoin’s resurgence

MiYou

0xBa5B

September 19th, 2024

Author: Fu Shaoqing, SatoshiLab, ThreeDAO BTC Studio

1. The main exploration and conflicts of Bitcoin's original technology

1.1. Bitcoin's script language and several deleted instructions
1.2. Bitcoin fork history, reasons and significance
1.3. Several typical explorations in Bitcoin development
1.4. Bitcoin's imperfections and layered protocols

2. Important new technologies in Bitcoin development (block expansion and capabilities expansion)

2.1. OP_RETURN, Segwit, Taproot
2.2. Schnorr, MAST, Taproot Scripts
2.3. Ordinals, Inscriptions, BRC20 and other protocols

3. How to use new technologies and future development needs

3.1. How to use new technologies
3.2. Future development needs

References

1. The main exploration and conflicts of Bitcoin's original technology

The original technology of Bitcoin has always had a conflict between large-scale applications and the capabilities that Bitcoin should have. Do large-scale applications and transaction scale mean more complex transaction instructions and larger transaction space? Does it mean that all functions must be implemented on a single Bitcoin system? In the early days, when the Bitcoin ecosystem technology was not well developed, these phenomena seemed to be problems of Bitcoin itself. With the development of technology, many problems will get clearer answers.

This article lists some related issues, as well as the process of generating and solving these issues. Through this article, you can see the correlation between these issues and technology, as well as the change process of the Bitcoin main chain and related "test chains". Bitcoin technology has been explored by different projects and teams (including Ethereum, which is an exploration of the imperfections of Bitcoin), but the changes on the Bitcoin main network have not been obvious enough until the emergence of technologies such as Taproot, which promoted the emergence of protocols such as the Ordinals protocol, and re-entered a new development climax.

Looking at these development processes and the related technologies produced as a whole, we can see the connection between them and infer more development directions and overall architecture.

1.1. Bitcoin's script language and several deleted instructions

The programming language of Bitcoin is a scripting language in reverse Polish paradigm, without loop statements and conditional control statements (see Taproot & Taproot Script for expansion of this capability later). Therefore, people often say that the Bitcoin scripting language is not Turing complete, which leads to certain limitations of the Bitcoin scripting language.

Of course, due to these limitations, hackers cannot use this scripting language to write some dead loops (which will cause network paralysis) or some malicious code that can cause DOS attacks, thus avoiding DOS attacks on the Bitcoin network. Bitcoin developers also believe that the core blockchain should not have Turing completeness to avoid some attacks and network congestion.

However, it is precisely because of these limitations that the Bitcoin network cannot run other complex programs and cannot complete some "useful" functions. Some blockchain systems developed later directly changed this in order to solve specific problems and meet user needs. For example, the language used by Ethereum is 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 is HASHed with SHA-1 algorithm.), OP_CHECKSIG()
8. Pseudo keywords
9. Reserved keywords

Common types of Bitcoin script instructions:

Script:

1. Standard transaction paid to 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 on the webpage: https://en.bitcoin.it/wiki/Script

Deleting instructions supported by Bitcoin

Bitcoin has had many instances of deleting instructions in its history. In the chart below, the red part is the removed instructions.

(1) String operations

(2) Bit operations related instructions

(3) Arithmetic operations

Why do Satoshi need to remove instructions? Security is only one aspect of the consideration. If we view the removal of instructions from the perspective of layered design, we will understand its rationality. Doing so will make the underlying protocol more basic and stable. Perhaps Satoshi Nakamoto was aware of this problem from the beginning, otherwise he would not have taken the initiative to remove instructions. Our ordinary thinking is to build a small system that directly meets user needs and has complete instructions and system functions, rather than a large protocol that requires collaboration.

This has led to the fact that only Bitcoin is suitable as a layer one network. I have analyzed this phenomenon in the article "The high price of Bitcoin will lead to the emergence of a new alternative chain". From the perspective of economics and technology, there is a possibility of the emergence of a Bitcoin alternative chain. However, from the perspective of Bitcoin's basic characteristics and layered design, almost only Bitcoin can serve as a layer one network infrastructure. Even if there is an alternative chain, it is a 1.5 layer product. At the level of the layer one network, the only authentic product is Bitcoin, and the chains that can have some alternative functions are at most A-grade counterfeit.

1.2. Bitcoin fork history, reasons and significance

In the history of Bitcoin development, in addition to the issue of deleting instructions, there is also the dispute over block size, which often causes Bitcoin hard forks.

When BTC was first created, there was no limit on the block size so that the number of transactions could be processed at the same time. But when the price of BTC was very low in the early days, the cost of malicious transactions was also very low. In order to solve this problem, Satoshi Nakamoto hosted a soft fork on September 12, 2010, adding a limit that the block size must not exceed 1MB. Satoshi Nakamoto pointed out that this restriction is temporary, and the block limit can be increased in a controllable and gradual manner in the future to meet the needs of expansion.

The following figure shows the history of Bitcoin forks:

As Bitcoin becomes more popular, the problems of network transaction congestion and confirmation time growth become more serious. In 2015, Gavin Andresen and Mike Hearn announced that they would implement the BIP-101 proposal in the new version of BitcoinXT, hoping to increase the block limit to 8MB. However, core developers such as Greg Maxell, Luke Jr, and Pieter Wuille opposed it, believing that this approach would raise the threshold for running a full node and bring uncontrollable impacts. The debate eventually expanded in terms of topics and participation.

From the above content, we can see that Satoshi Nakamoto also expressed that "the block size limit is temporary, and the block limit can be increased in a controllable and gradual manner in the future to meet the needs of capacity expansion." But when will the fork support larger blocks, and can a separate chain to support large blocks solve the problem? In the constant controversy, many cases have also been generated. For example, the BCH block size is 8M, and later increased to 32M. The BSV block size is 128M. In addition to BCH (and BSV later), many other BTC forks also appeared during this period. According to BitMEXResearch, at least 50 new forks appeared within a year after the BCH fork.

We will see later that Segwit and Taproot on the Bitcoin mainnet also increased the block space from 1M to 4M to a certain extent.

Bitcoin forks are a development exploration, trying to support more needs through their own changes. Among them are user needs, miner needs, investor needs, developer needs, etc.

1.3. Several typical explorations in Bitcoin development

After Satoshi Nakamoto left, his successor Gavin Andresen led the establishment of Bitcoin Core and the Bitcoin Foundation. During this period, exploration of BTC's scalability has always existed, especially in the field of asset issuance.

(1) Colored Coins

eToro CEO Yoni Assia first proposed colored coins in an article published on March 27, 2012. The idea continued to develop, and the concept of colored coins began to take shape and gain attention on forums such as Bitcointalk. Finally, Meni Rosenfeld released a white paper detailing colored currencies on December 4, 2012.

The idea of colored coins is to represent a wider range of assets and values by adding special annotations (i.e., coloring) to specific parts of Bitcoin. There are a series of entities in the implementation of colored coins, which can be roughly divided into two categories:

1）Based on OP_RETURN: For example, Open Assets proposed by Flavien Charlon in 2013 uses OP_RETURN (proposed in Bitcoin v0.9.0, which can be used to store a small amount of data on Bitcoin, with an initial limit of 40 bytes and later increased to 80 bytes). The opcode is stored in the script and the "coloring" and transaction are completed by external reading. (This mode is similar to Ordinals relying on external indexes to determine the legitimacy of assets).
2）Not based on OP_RETURN: A typical representative is the EPOBC Protocol proposed by ChromaWay in 2014. The additional information of EPOBC assets is stored in the nSequence field in Bitcoin transactions. The category and legitimacy of each EPOBC asset need to be traced back to the genesis transaction to determine.

(2) MasterCoin (OMNI)

JR Willett published the concept of MasterCoin on January 6, 2012, and named it "The Second Bitcoin White Paper". In July 2013, the project was officially launched through ICO, and 5,120 BTC (worth $500,000 at the time) were eventually raised. The difference between MasterCoin and Colored Coins is that it establishes a complete node layer, which maintains the state model database by scanning Bitcoin blocks. The database resides in nodes outside the blockchain. This design can provide more complex functions than Colored Coins, such as creating new assets, decentralized exchanges, and automated price feedback. In 2014, Tether also launched a stablecoin on Bitcoin through the Mastercoin protocol, which is the well-known Tether USD (OMNI).

(3) Counterparty

Counterparty was officially launched in 2014. Counterparty also uses OP_RETURN to store data in the BTC network. However, unlike colored coins, assets in Counterparty do not exist in the form of UTXO, but rather load information through OP_RETURN to indicate the transfer of assets. When an asset holder signs a transaction with special data using the holding address, the asset is transferred. In this way, Counterparty can realize the issuance and trading of assets and a platform compatible with Ethereum smart contracts.

In addition, there is also a view that Ethereum, Ripple and BitShares also belong to the broader "Bitcoin 2.0".

1.4. Bitcoin's imperfections and layered protocols

The imperfections (or limitations) of the Bitcoin system are mainly manifested in several aspects (the imperfections in this article are based on the summary in the Ethereum white paper, not real imperfections.):

1. Bitcoin's accountless system UTXO

In current blockchain projects, there are two main ways to keep records, one is the account/balance model and the other is the UTXO model. Bitcoin adopts the UTXO model, while Ethereum, EOS, etc. adopt the account/balance model.

In Bitcoin wallets, we can usually see account balances, but in the Bitcoin system designed by Satoshi Nakamoto, there is no concept of balance. "Bitcoin balance" is a product derived from the Bitcoin wallet application. UTXO is an unspent transaction output, which is a core concept in the generation and verification of Bitcoin transactions. Transactions constitute a set of chain structures. All legal Bitcoin transactions can be traced back to the output of one or more transactions in the past. The source of these chains is mining rewards, and the end is the current unspent transaction output.

So there is no Bitcoin in the real world, only UTXO. Bitcoin transactions consist of transaction inputs and transaction outputs. Each transaction requires spending an input and generating an output, and the output generated is the "unspent transaction output", or UTXO.

If you want to implement smart contracts, the UTXO accountless model has a very big problem. Gavin Wood, the designer of the Ethereum Yellow Paper, has a deep understanding of UTXO. The biggest new feature of Ethereum is smart contracts. Because of the consideration of smart contracts, it is difficult for Gavin Wood to implement Turing-complete smart contracts based on UTXO. The account model is naturally object-oriented, and each transaction will be recorded on the corresponding account (nonce++). In order to facilitate account management, a global state is introduced, and each transaction will change this global state. This is corresponding to the real world. Every tiny change will change the world. Therefore, Ethereum uses an account system, and later public chains are basically implemented based on various types of account systems.

Another serious flaw of UTXO is that it cannot provide fine control over the withdrawal amount of an account. This is explained in the Ethereum white paper.

2. Bitcoin's scripting language is not Turing complete

Although Bitcoin's scripting language can support a variety of calculations, it cannot support all calculations. The main missing part is that Bitcoin's scripting language does not have loop statements and conditional control statements. Therefore, we say: Bitcoin's scripting language is not Turing complete. This leads to certain limitations in Bitcoin's scripting language. Of course, due to these limitations, hackers cannot use this scripting language to write some dead loops (which will cause network paralysis) or some malicious code that can cause DOS attacks, thus avoiding DOS attacks on the Bitcoin network. Bitcoin developers also believe that the core blockchain should not have Turing completeness to avoid some attacks and network congestion. However, it is precisely because of these limitations that the Bitcoin network has no way to run its complex programs. The purpose of not supporting loop statements is to avoid infinite loops when confirming transactions.

For security reasons, the reason for not supporting Turing completeness is insufficient. And non-Turing complete languages do very limited things.

3. Other imperfections of Bitcoin, security, scalability

The problem of centralization of mining. The Bitcoin mining algorithm basically allows miners to slightly modify the block header thousands of times until the hash of the modified version of a certain node is less than the target value. However, this mining algorithm is vulnerable to two forms of centralized attacks. First, the mining ecosystem is controlled by ASICs (application-specific integrated circuits) and computer chips that are specially designed and thus thousands of times more efficient in the specific task of Bitcoin mining. This means that Bitcoin mining is no longer highly decentralized and egalitarian, but requires the effective participation of huge capital. Second, most Bitcoin miners no longer actually complete block verification locally; instead, they rely on centralized mining pools to provide block headers. This problem can be said to be serious: currently, the top three mining pools indirectly control about 50% of the processing power in the Bitcoin network.

The scalability problem is an important issue for Bitcoin. With Bitcoin, it grows by about 1 MB per hour. If the Bitcoin network processes 2,000 Visa transactions per second, it will grow by 1 MB every three seconds (1 GB per hour, 8 TB per year). The low number of transactions has also caused controversy in the Bitcoin community. Although a large blockchain can improve performance, the problem is the risk of centralization.

From the perspective of the product life cycle, some minor imperfections of Bitcoin can be improved in its own system, and the improvement methods are limited by the current system. However, if these problems can be solved in a new system, the limitations of the old system can be completely ignored. Since a new blockchain system is to be built, these small functional improvements should also be designed and upgraded when designing the new system.

Layered design

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 function between each layer, the modularity, maintainability and scalability of the system can be achieved, thereby improving the design efficiency and reliability of the system.

For a wide and large protocol system, the use of layers will have obvious benefits. Doing so makes it easier for people to understand, easy to implement by division of labor and easy to improve by modules. For example, the seven-layer model design of ISO/OSI in computer networks, but in specific implementations, some layers can be merged. For example, the specific network protocol TCP/IP is a four-layer protocol. Specifically, the advantages of protocol layering are: each layer is independent, flexible, structurally separable, easy to implement and maintain, and can promote standardization.

From the perspective of layered protocols, because Bitcoin is at the most basic bottom layer, its UTXO, non-Turing completeness, long block time, small block capacity, disappearance of the founder, etc., are not disadvantages, but rather characteristics that a layer network should have.

Note: The author has a more detailed explanation of protocol layering in "Summarizes the basic knowledge system of Bitcoin Layer2 construction".

2. Important new technologies in Bitcoin development (block expansion and capabilities expansion)

In the previous section, we discussed the main conflicts and exploration cases of Bitcoin's original technology, but many of them led to hard forks or the creation of new heterogeneous chains. On the Bitcoin blockchain itself, this exploration has also produced many results, which are essentially the expansion of blocks and capabilities. They are mainly manifested in the following aspects.

2.1. OP_RETURN, Segwit, Taproot

Bitcoin developers have always wanted to expand Bitcoin's capabilities, which is reflected in several aspects:

(1) Use of OP_RETURN

OP_RETURN is a script opcode that terminates the script and returns the value at the top of the stack. This opcode is similar to the return function in a programming language. In the history of Bitcoin, the function of the OP_RETURN opcode has been modified many times, and it is now mainly used as a method of storing data on the ledger. The function of the OP_RETURN opcode has undergone major changes in the past, and now it is an important mechanism that allows us to store arbitrary data on the chain.

OP_RETURN was originally used to return to terminate the script execution prematurely, and the execution result will be presented as the top item on the stack. This opcode originally had an easily exploitable vulnerability, but Satoshi Nakamoto quickly patched the vulnerability.

Further changes to the OP_RETURN function

In the Bitcoin Core v0.9.0 upgrade, the "OP_RETURN output" script was made into a standard output type, allowing users to attach data to "unspendable transaction outputs". The maximum amount of data that can be used in such scripts was initially limited to 40 bytes, then raised to 80 bytes.

Storing Data on the Blockchain

Changing OP_RETURN to always return false had interesting consequences. Since no opcodes or data are evaluated after OP_RETURN, network users began using this opcode to store data in any format.

During the Bitcoin Cash (BCH) period, from August 1, 2017 to November 15, 2018, the length of data that could be attached to OP_RETURN outputs was expanded to 220 bytes, which enabled innovative applications on the blockchain, such as posting content on blockchain social media.

On BSV, the 220-byte limit remained for a short time. Then, in January 2019, because the OP_RETURN opcode terminates the script in a way that nodes do not validate any subsequent opcodes, nodes no longer check whether the script is within the maximum script size limit of 520 bytes. As a result, the node operators on the network decided to increase the maximum transaction size to 100KB, giving developers more freedom to innovate applications and allowing new applications to put larger and more complex data into the Bitcoin ledger. At that time, there was an application example where someone put the entire website into the BSV ledger.

Although OP_RETURN has certain functional extensions, its overall capabilities are still limited. So the technology of segregated witness was born.

(2) Segwit Segregated Witness

Segregated Witness(SegWit for short) was first proposed by Pieter Wuile (Bitcoin core developer and Blockstream co-founder) in December 2015, and later formed Bitcoin BIP141. Segregated Witness slightly modifies the data structure of transactions in Bitcoin blocks to solve the following problems:

1）Transaction malleability problem.
2）The signature of the transaction transmitted in the SPV proof becomes optional, which can reduce the amount of data transmitted by the Merkle proof.
3）Increase the block capacity in disguise.

The first two items are mainly to increase security and performance, and the third item has the greatest impact on new technologies. Cashing out increases the capacity of blocks (see the concept of Block weight below), thus laying the foundation for the expansion of Bitcoin's capacity, so that Taproot (the second version of Segregated Witness) can be further strengthened.

Although cashing out expands the block capacity, Segregated Witness is also subject to block size restrictions. Bitcoin's block size is limited to 1M bytes. Since witness data is not included in this limit, in order to prevent witness data from being abused, the total block size is still limited. A new concept called Block weight is introduced

Block weight = Base size * 3 + Total size
Base size is the block size without witness data
Total size is the block size (in bytes) of serialized transactions as described in BIP144, including base data and witness data.
Segregated Witness limits Block weight <= 4M.

Segregated Witness also technically enables Bitcoin's expansion to use the Lightning Network, which is not introduced in detail here.

(3) Taproot (Segregated Witness V2)

If the word Taproot is used directly, many people think it is a new concept, but if tell you that this is the second version of Segregated Witness, most people will understand the relevance. The BIPs related to Taproot are 340, 341, and 342, and their names are: BIP340 (Schnorr Signatures for secp256k1), BIP341 (Taproot: SegWit version 1 spending rules), and BIP342 (Validation of Taproot Scripts).

In November 2021, Taproot officially took effect in the form of a soft fork. This upgrade is a combination of BIP340, BIP341, and BIP342. 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 deficiencies of Bitcoin's native capabilities.

The expansion of the space of Segregated Witness Segwit and Taproot has led to the emergence of Schnorr, MAST tree and Taproot Scripts, and their mission is to expand the functions of the Bitcoin mainnet.

2.2. Schnorr, MAST, Taproot Scripts

Through Section 2.1, we have seen Bitcoin's continuous exploration of capacity expansion and capabilities expansion. It was not until the emergence of Taproot technology and several related important technologies Schnorr, MAST, and Taproot Scripts that Bitcoin's capabilities were truly opened up.

(1) Schnorr Signature

The development of Taproot, while expanding its capabilities, has certain requirements for signature algorithms, so Schnorr signatures began to appear and were used to replace the Elliptic Curve Digital Signature Algorithm (ECDSA). Schnorr signature is a digital signature scheme that can sign transactions and messages efficiently and securely. It was first described by Claus Schnorr in a 1991 paper. Schnorr is praised for its simplicity, provable security, and linearity.

Advantages of Schnorr Signature:

1）Schnorr signature has multiple advantages, including efficiency and enhanced privacy, while retaining all the functions and security assumptions of ECDSA. Schnorr signatures can achieve smaller signature sizes, faster verification times, and improved resistance to certain types of attacks.
2）The most significant advantage of Schnorr signatures is key aggregation, which aggregates multiple signatures into a single signature that is valid for the sum of their keys. In other words, Schnorr enables multiple parties to generate a signature that is valid for the sum of their public keys. Signature aggregation allows signatures from multiple signers to be combined into a single signature.

Key aggregation can reduce transaction fees and improve underlying scalability because electronic signatures from multi-signature settings take up the same space in the block as signatures from single-party transactions. This feature of Schnorr can be used to reduce the size of multi-signature payments and other multi-signature-related transactions, such as lightning network channel transactions.
3）Another important feature of Schnorr signatures is immutability.
4）Schnorr also provides many privacy advantages. It can make multi-signature schemes indistinguishable from traditional single public keys from the outside, and Schnorr makes it more difficult for observers to distinguish between multi-signature spending and single-signature spending in on-chain activities. Additionally, in an n-of-m multi-signature setup, Schnorr makes it more difficult for an outside observer to determine which participants signed a transaction and which did not by looking at on-chain information.

Schnorr signatures were implemented in BIP-340 as part of the Taproot soft fork upgrade and activated at block height 709,632 on November 14, 2021. Schnorr makes BTC's digital signatures faster, more secure, and easier to process. Notably, Schnorr signatures are backwards compatible with BTC's cryptographic algorithm, so they can be introduced through a soft fork upgrade.

(2) MAST Abstract Syntax Tree

The abbreviations of MAST are a little ambiguous. The official BIP (BIP114) and some articles use the abbreviation of MAST: Merklized Abstract Syntax Tree. Some other materials use Merklized Alternative Script Trees (MAST) . In the book "Mastering Bitcoin", and in an article, this abbreviation is used:

https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade.

The Merklized Abstract Syntax Tree and the Merklized Alternative Script Tree (MAST) look the same in terms of function. I personally feel that the usage in the official Bitcoin BIP protocol should be maintained.

The concept behind MAST comes from two concepts, the abstract semantic tree and the Merkle tree.

The abstract semantic tree (AST) belongs to the knowledge field of compiler theory and formal linguistics in computer science. The abstract semantic tree is an intermediate representation in the compilation process, which is used to represent the semantic structure of the source code. It converts the source code into a tree structure, where each node represents a semantic unit and the edges represent the relationship between them. The abstract semantic tree plays an important role in the lexical analysis and syntax analysis stages of the compiler, helping the compiler understand the meaning of the source code and perform subsequent optimization and target code generation. In layman's terms, the abstract semantic tree (AST) is a method of describing a program by splitting it into independent small pieces, which makes the program easier to analyze and optimize. In order to generate an AST, all equations and their premises need to be connected with arrows until all premises are found. The figure below is the AST of a script.

On the other hand, the Merkle tree can be used to verify whether an element belongs to a set without knowing the entire set. For example, Bitcoin's Simplified Payment Verification Wallet (SPV wallet) uses the Merkle tree to verify whether a transaction exists in a block, so that there is no need to download the entire block, which can save bandwidth.

To generate a Merkle tree, each element must be hashed once to generate its own unique identifier; then these identifiers are paired and hashed again to generate the identifier of this pair of identifiers; this is repeated until only one identifier is left, called the "Merkle root", which is a short and powerful identifier that marks the entire set.

When verifying whether an element belongs to a set, the person who owns the entire set can provide you with all the identifiers on the path from that element to the Merkle root. This proves that the element is indeed in the set.

In short, the technology behind AST allows you to divide a program into multiple small pieces, and the Merkle tree allows us to verify that these small pieces are indeed part of a complete program without exposing the entire program. This is the basic principle of MAST, which allows spenders to replace conditions that are not used in a single transaction with a Merkle proof. The advantages are: reducing transaction volume, improving privacy, and supporting larger contracts.

There are many specific MAST tree cases on the Internet. People who understand program development can understand the relevant logic by sorting out the process of a MAST.

Now that we have the MAST abstract syntax tree, we need to expand the capabilities of Bitcoin's native syntax, so Taproot Scripts came into being.

(3) Taproot Scripts

The Tapscript script was added to the BIP342 protocol. Taprootscript is an upgraded version of the original Bitcoin script. It can also be called a language, but it is actually a collection of opcodes with commands. These commands help implement the other two BIPs. Taprootscript also removes the 10,000-byte script size limit, providing a better environment for creating smart contracts on the Bitcoin network. (This upgrade also laid the foundation for the birth of Oridnals, because the Ordinals protocol uses Taproot's script-path spend scripts to implement additional data). For detailed information, please refer to the official website:

The current capabilities of TaprootScript have not been fully utilized, and more construction in the future will reflect its power. For example, the connection technology between the first layer and second layer of Bitcoin network should make more use of Taproot, MAST and TaprootScripits.

2.3. Ordinals, Inscriptions, BRC20 and other protocols

With the basic tools such as Segwit, Taproot, Schnorr, MAST, and Taproot Scripts, new applications have begun to emerge in the Bitcoin ecosystem. The applications in the initial stage are lightweight and simple applications.

(1) Ordinals protocol, inscriptions, and BRC20

The birth of the Ordinals protocol is highly related to the concept of sats. The protocol proposes the concepts of ordinals and inscriptions. Ordinals refers to a numbering scheme that assigns a number to each Satoshi (Satoshi) on the Bitcoin network in the order of mining. In the protocol, no matter how sats are transferred between different wallets, their ordinal identifiers remain unchanged. Bitcoin full nodes running the Rodarmor open source software ORD can track these numbered Satoshis. This provides a mechanism for people to accurately track each Satoshi and conduct independent verification.

Inscriptions are information burned on Satoshis. By combining SegWit and Taproot, the Ordinals protocol can burn a file of less than 4MB, i.e., inscriptions, for each Satoshi on the Bitcoin block. Inscriptions can contain information in various forms, such as text, pictures, videos, etc. The following is a screenshot of a sample inscription.

Simply put, the ordinal numbering scheme provides each satoshi with a unique traceable number, which makes satoshi non-homogeneous. Inscriptions can add indivisible data information to the ordinal, similar to creating art on a blank piece of paper. The combination of the two gives Bitcoin a new NFT standard. The essence of Ordinals is actually very simple. It is more like an NFT protocol. However, unlike ETH or other public chains, where NFT metadata (MetaData) is mostly stored in IPFS or centralized servers, Ordinals' metadata is embedded in the witness field (Witness Data) of the transaction, just like being "engraved" on a specific satoshi. This is also the origin of the word inscription.

BRC-20: Inspired by the Ordinals protocol, Twitter user @domodata created Bitcoin's experimental alternative token standard BRC-20 on March 8, 2023. The Ordinals protocol creates NFTs on the BTC network by giving different "attributes" to each satoshi, while BRC-20 creates FTs on BTC by giving a unified "format" and "attributes", that is, homogeneous tokens.

BRC-20 uses the Ordinals protocol to write a JSON text into the BTC inscription to deploy token contracts, mint and transfer tokens (Depoly, Mint, Transfer). The key to deployment lies in the token name, total supply, and maximum single minting amount. For transfers or buy/sell transactions, additional NFTs will be engraved to track the off-chain balance. The "first come, first served" minting mechanism brings fair issuance and participation opportunities; at the same time, due to the relatively imperfect BTC ecological infrastructure, there is a certain learning threshold, and low liquidity makes BRC-20 tokens easily pulled up, ordi, sats, rats and other BRC20 tokens have opened a wave of wealth creation myths.

(2) Other protocols - Atomicals, ARC20

The birth of the Atomicals protocol was quite dramatic. When the Ordinals protocol was first released, founder Arthur wanted to develop a DID project on it. However, during the development process, he found that the Ordinals protocol had many limitations and was not conducive to supporting some of the features he wanted to achieve. Therefore, on May 29, 2023, Arthur posted the first tweet on Twitter about the conception of the Atomicals protocol. After several months of development, the Atomicals protocol was launched on September 17, 2023. Later, the Atomicals protocol derived four major concepts, including Dmint, Bitwork, ARC-20, and RNS. In the future, AVM and split plans will also be launched.

Similar to Ordinals and BRC20, deploying homogeneous tokens on Atomicals formed ARC20. Readers interested in ARC20 can read further.

(3) Other protocols - Rune

As the development progressed, Casey Rodarmor, the founder of Ordinals, published an article pointing out that BRC-20 tokens have the "adverse consequences of UTXO proliferation" and suggested that Runes be used as an alternative based on UTXO. Existing protocols generally have problems such as complex protocol implementation, poor user experience, garbage unspent transaction outputs (UTXO), and operations requiring native tokens.

The transfer of Runes uses OP_RETURN. The first data output in the protocol message is decoded into a sequence of integers, which are interpreted as a sequence of (ID, OUTPUT, AMOUNT) tuples. If the number of decoded integers is not a multiple of three, the protocol message is invalid. ID is the token ID to be transferred, OUTPUT is the output index to be assigned (that is, the output to which it is assigned), and AMOUNT is the amount of runes to be assigned. After all tuple assignments are processed, any unassigned Runes Tokens are assigned to the first non-OP_RETURN output, and the rest can be burned by assigning the Runes protocol to the OP_RETURN output containing the protocol message.

Runes issuance: Homogenous token tracking based on UTXO. If the protocol message has a second data push, it is an issuance transaction. The second data push is decoded into two integers, SYMBOL, DECIMALS. If there are any remaining integers, the protocol message is invalid. SYMBOL is a base 26-bit readable symbol similar to the symbols used in the names of Ordinals, and the only valid characters are currently A to Z. DECIMALS is the number of digits after the decimal point that should be used to show when issuing Runes. If SYMBOL has not been assigned, the Runes Token will be assigned an ID value (starting at 1). If SYMBOL has already been assigned, or is BITCOIN, BTC, or XBT, no new runes will be created. This is the special feature of the Runes protocol. Instead of linking the balance record to the wallet address, it puts the record in the UTXO itself.

The new Runes Token starts with an issuance transaction, specifies the supply, symbol, and number of decimal places, and assigns that supply to a specific UTXO. A UTXO can contain any number of Rune tokens, regardless of their size. UTXOs are used only to track balances. The transfer function then uses that UTXO, splits it into multiple new UTXOs of any size, containing different numbers of Runes, and sends the record to others. Compared to BRC-20, Runes reduces one layer of server consensus and becomes simpler, while not relying on off-chain data and having no native tokens, making it a good fit for Bitcoin's native UTXO model.

(4) Other protocols - BTC stamps, SRC20, SRC721

The Bitcoin Stamps system was released by Mike In Space in March 2023 and was originally a proof-of-concept project on Counterparty (a Bitcoin L2 that has existed since 2014). Due to an update to its underlying protocol, Stamps has completely switched to Bitcoin last summer and is now known as SRC-20. Founder Mike originally envisioned Stamps as a way to mint permanent Bitcoin NFTs. However, the protocol has expanded to replicate BRC-20, a mass fungible token that has flourished on Bitcoin due to the rise of the inscription craze since Casey Rodarmor launched Ordinals in January 2023.

The main difference between Stamps and Ordinals is the architecture. This is because Stamps store their metadata in a multi-signature unspent transaction output (UTXO), while Ordinals store their metadata in the "witness" portion of a Bitcoin transaction. This difference in design reveals the trade-offs made by the developers. That is, the UTXO method of Stamps makes them non-prunable and therefore seemingly permanent, even though they are more expensive to produce than Ordinals. Conversely, the way Ordinals use witness data ultimately makes them prunable, and they are cheaper to produce than Stamps.

So while Ordinals may offer the best permanence-to-cost ratio for NFTs in the crypto space today (on-chain NFTs can also be obtained on Ethereum, but they are relatively more expensive to build than Ordinals), Stamps currently appear to offer the best direct permanence guarantee.

After BTC stamps were created, SRC20 and SRC721 began to be created, and their principles are similar to BRC20. BRC-20 is based on the Ordinals protocol, while SRC-20 is based on BTC STAMPS. Interested readers can read more about SRC20 and SRC721.

So far, all the important new technologies of Bitcoin on the first layer network have been introduced. In terms of subsequent capacity expansion and capabilities expansion, Bitcoin's upper-layer facilities, such as Bitcoin's Layer2 or higher layers such as RGB implemented with the help of lightning networks, etc., are used. For articles in this regard, it is recommended to read "Summarizes the basic knowledge system of Bitcoin Layer2 construction" and "Observing Bitcoin's Second Layer from the Perspective of the State Machine, You Can See the Architecture and Construction Path of Future Web3.0 Applications", or other articles on Bitcoin's second-layer construction or architectural design.

3. How to use new technologies and future development needs

Through the content of Section 2, we can see that the technological development of the Bitcoin ecosystem has laid the foundation for larger-scale applications. However, because development requires a process and some related technologies are immature, there is still a big difference between the current popular applications and the final common applications.

3.1. How to use new technologies

From the previous two sections, we can see that the development of Bitcoin technology is essentially the expansion of blocks and capabilities.

In terms of block expansion, segregated witness has led to de facto block expansion. Although there are various proposals to cut out the witness part, the probability of this happening is not high, especially after the witness part is given more meaning.

In terms of expansion capabilities, Taproot, Schnorr, MAST, Taproot Scripts, and other technologies have given Bitcoin more capabilities. In particular, MAST+Taproot Scripts will expand the capabilities of Bitcoin's native scripting language, and several other technologies will expand the ability of Bitcoin language to handle complex scenarios. However, these capacity expansions will also increase the difficulty of Bitcoin development and understanding, after all, these Scripts development is not a high-level language. And this part of the capacity expansion will lag behind the user's understanding and learning speed of block capacity expansion.

Because using block expansion is simple and using capabilities expansion is complex, this is the reason why users first write those small picture NFTs into the Bitcoin mainnet and generate applications such as BRC20. Currently, many applications on the Bitcoin mainnet are almost all exploring applications after block expansion. A small number of applications have begun to explore capacity expansion. For example, the connection between the first and second layers of BEVM is representative, and more functions built with the above basic elements are used. Its Shnorr signature + MAST contract + Bitcoin light node network BTC L2 solution is a good case for learning to connect the first and second layers. There will be more cases of capacity expansion in the future.

Where should the boundary of capabilities expansion be? We can judge from the perspective of layered design. If these capacity expansions are more of a connection technology between the first and second layers of Bitcoin, then the capabilities expansion should not be made too complicated. But based on our rich creativity and the strong appeal of asset issuance and management, some teams or individuals will explore more cases of capacity expansion scenarios.

3.2. Future development needs

The most direct reason for the emergence of blockchain technology is digital currency, so applications such as issuing assets and managing assets are the most direct needs in the field of Bitcoin or blockchain. Whether it is from the exploration of colored coins to applications such as BRC20, ARC20, or ICO, IDO and other applications on Ethereum, they are all exploring asset issuance. Like Uniswap, Lending, AMM, they are all asset management applications. This part of the application has been maturely developed on networks such as Ethereum. With the development of Bitcoin ecological technology, these asset management applications will be transferred to the Bitcoin ecosystem, and more should be carried out on the second layer of Bitcoin.

Only when the needs of issuing assets and managing assets are met, there will be energy and time to develop large-scale applications belonging to the Web3.0 era (also known as the value era). The system architecture of large-scale applications in the future Web3.0 era, I have a relevant description in "Observing the second layer of Bitcoin from the perspective of the state machine, we can see the architecture and construction path of future Web3.0 applications".

The construction path is a process of continuously meeting needs, which can be divided into three stages: short-term, medium-term and long-term. In the short term, the applications generated by the new technology on the Bitcoin main network and the simple stage of the second-layer construction based on the chain will complete the main capabilities expansion of the applications and meet various financial applications. In the medium term, the second-layer construction based on the chain in the middle and late stages and the second-layer construction based on the distributed system will meet various financial applications and trust applications. In the long term, the large-scale construction based on the Bitcoin ecosystem will complete the construction of the real Web3.0 era.