On the eve of the outbreak again, 10,000 words summarized the new technology development of Bitcoin

Original author: Fu Shaoqing, SatoshiLab, Wanwudao BTC Studio

1 The main explorations and conflicts of Bitcoin’s original technology

Bitcoin’s original technology has always had the problem of conflict between large-scale application and the capabilities that Bitcoin should have. Does large-scale adoption and transaction size mean more complex trading instructions and larger trading shorts? Does it mean that all functions must be implemented on a single Bitcoin system? In the early days, when the Bitcoin ecosystem was not perfect, these phenomena seemed to be the problems of Bitcoin itself. As technology evolves, long questions will be answered more clearly.

In this article, we list some of the relevant issues, as well as the process of creating and resolving them. Through this article, you can see the correlation between these issues and the technology, as well as the process of changing the Bitcoin mainchain and related “test chains”. Bitcoin technologies have been explored by different projects and teams (including Ethereum are all an exploration of Bitcoin imperfections), but the changes in the Bitcoin Mainnet have not been obvious until the emergence of technologies such as Taproot has promoted the emergence of protocol such as Ordinals protocol, and re-entered a new climax of development.

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

1.1 Bitcoin scripting language with several deletion instructions

Bitcoin’s programming language is a scripting language that goes against the Polish paradigm, without loop statements and conditional control statements (see Taproot & Taproot to expand this later). Therefore, it is often said that the Bitcoin scripting language is not Turing complete, which leads to the Bitcoin scripting language, which has certain limitations.

Of course, because of these limitations, Hacker can’t use this scripting language to write some endless loops (which can paralyze the network) 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 integrity to avoid some attacks and network congestion.

However, it is precisely because of these limitations that the Bitcoin network has no way to run other complex programs and complete some “useful” functions. Some Blockchain systems developed later, in order to solve specific problems and meet the needs of users, directly changed this. For example, the language used by Ethereum has Turing Complete.

Common types of Bitcoin Script instructions:

Keywords:

1. Constants. For example: OP_ 0 , OP_FALSE

2. Process control. Such as: OP_IF, OP_NOTIF, OP_ELSE,…

3. Stacks. For example: OP_TOALTSTACK (press the input into the item part of the secondary stack, remove it from the main stack),…

4. Strings. For example: OP_CAT (concatenate two strings, disabled), OP_SIZE (press the string length of the top element into the stack (no need to pop up the element))

5. Bitwise logic. For example: OP_AND, OP_OR, OP_XOR

6. Arithmetic logic. For example: OP_ 1 ADD (input value plus 1), OP_ 1 SUB (input value minus 1)

7. Encryption. For example: OP_SHA 1 (SHA-1 Algorithm HASH. for input), OP_CHECKSIG()

8. Pseudokeywords

9. Reserve keywords

Common types of Bitcoin Script instructions:

Script:

1. Pay-to-Bitcoin Address standard transaction (pay-to-pubkey-hash)

2. Standard Bitcoin generates transactions (pay-to-pubkey)

3. Provably unspent/deletable output

4. Anyone-Can-Spend output

5. Guess the trade

The five standard types of transaction scripts are: Pay-to-Public Key hash (P2P KH), Pay-to-Public Key, multisignature (limited to long 15 Secret Key), Pay-to-Script hash (P2SH), and Data Output (OP_RETURN).

There are detailed instructions on the web page.

Delete Bitcoin supported instructions

Bitcoin has had longest deletions in its history. In the chart below, the red part is the instruction that has been cut.

String Operations

Security is only one aspect of the consideration, if we look at the deletion instruction with the idea of hierarchical design, we will understand its rationality, which can make the underlying protocol more basic and stable. Perhaps Satoshi Nakamoto was aware of this problem at the beginning, otherwise he would not have taken the initiative to delete the instruction. Our ordinary thinking is to build a small system that directly meets the needs of users, with perfect instructions and system functions, rather than a large protocol that requires collaboration.

This creates the fact that only Bitcoin is suitable as a layer 1 network. I analyzed this phenomenon in the article “Bitcoin price too high will promote the creation of a new alternative chain”, and from an economic and technical perspective, there is a possibility of generating a Bitcoin alternative chain. But from the perspective of Bitcoin’s basic characteristics and layered design, almost only Bitcoin can be used as a layer of network infrastructure, and even if there is an alternative chain, it is a product of layer 1.5. At the level of the first-layer network, the real product is only Bitcoin, and the chain that can have some alternative role is longest A goods.

1.2 Bitcoin fork History, Causes and Significance

In the history of Bitcoin development, in addition to the issue of deletion instructions, on the other hand, there is a dispute between the size of the Block, which often causes Bitcoin Hard Fork.

BTC was founded without a block size limit so that it could process the number of transactions at the same time. But when the price of early BTC was very low and the cost of malicious transactions was very low, Satoshi Nakamoto hosted a Soft Fork on September 12, 2010, adding a limit of 1 MB in Block size. Satoshi Nakamoto pointed out that this limit is temporary, and the block limit can be increased in a controlled and gradual manner in the future to meet the needs of scaling.

The following chart shows the fork history of Bitcoin:

With the popularity of Bitcoin, the problem of network transaction congestion and rising confirmation time has become more serious. In 2015 Gavin Andresen and Mike Hearn announced that they would implement the BIP-101 proposal in a new version of BitcoinXT, hoping to increase the block limit to 8 MB. Core developers such as Greg Maxell, Luke Jr, and Pieter Wuille oppose it, arguing that this approach raises the threshold for running full nodes and has uncontrollable impacts. The debate eventually broadened both in terms of topics and participation.

From the above content, we see that Satoshi Nakamoto also expressed that “the Block size limit is temporary, and the Block limit can be increased in a controlled and gradual manner in the future to meet the needs of scaling.” "But when will fork support greater Block, and can a separate chain support Block solve the problem long? For example, the size of the BCH Block is 8 m and later increased by 32 m. BSV Block size is 128 M. In addition to the BCH (and the BSV that followed), there were many other BTC Forked Coin long this period, with at least 50 new Forked Coin appearing in just one year after the BCH fork, according to BitMEXResearch.

As we’ll see later, Segwit and Taproot have also increased the short of Block from 1 M to 4 M to a certain extent on the Bitcoin Mainnet.

Bitcoin fork is a kind of development exploration, trying to complete the support of more long needs through its own changes. Among them, there are user needs, Miner needs, investor needs, and developer needs、…。

1.3 Several typical explorations in the development of Bitcoin

After the departure of Satoshi Nakamoto, heir Gavin Andresen led the establishment of Bitcoin Core and the Bitcoin Foundation. During this period, long wick candles have been exploring the scalability of BTC, especially in the field of asset issuance.

Colored Coins (dyed coin)

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

Dyed coins are conceived to represent a wider range of assets and values by adding special annotations (i.e., dyeing) to specific parts of Bitcoin. Dyeed coins appear in the implementation of a series of entities, broadly divided into two categories:

1. Based on OP_RETURN: For example, Open Assets, proposed by Flavien Charlon in 2013, leverages OP_RETURN (proposed in Bitcoin v 0.9.0, which can be used to store small amounts of data on Bitcoin, initially limited to 40 bytes, later increased to 80 bytes). The Operation Code is stored in the script and read by the outside world to complete the “dyeing” and transaction. (This pattern is similar to Ordinals’ reliance on external indexes to determine asset legitimacy).

2. Based on OP_RETURN: The typical representative is the EPOBC Protocol proposed by ChromaWay in 2014, and the additional information of EPOBC assets is stored in the nSequence field in the Bitcoin transaction, and the class and legitimacy of each EPOBC asset need to be traced back to the genesis transaction to determine.

MasterCoin（OMNI)

JR Willett released the idea for MasterCoin on January 6, 2012, named “Bitcoin’s Second White Paper”, and officially launched the project through an ICO in July 2013, eventually raising 5,120 BTC (worth $500,000 at the time). The difference between MasterCoin and Colored Coins is that it establishes an entire Node layer that maintains a state model database by scanning the Bitcoin Block, which resides in Node outside of the Blockchain. This design can provide more complex features than Colored Coins, such as creating new assets, DEX exchanges, automated price feeds, and more. In 2014, Tether also launched its stablecoin on the Bitcoin through the Mastercoin protocol, better known as 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 dyed coin, assets do not exist in the form of UTXOs in Counterparty, but are loaded with information through OP_RETURN to indicate the transfer of assets, and when an asset holder uses the holding Address to sign a transaction with special data, the asset is transferred. In this way, Counterparty enables the issuance and trading of assets, as well as a Ethereum smart contracts-compatible platform.

In addition, there is also an argument that Ethereum, Ripple, and BitShares also fall under the broader term “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 the real imperfections).

1. Bitcoin’s account 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 uses the UTXO model, while Ethereum, EOS, etc. use the account/balance model.

In Bitcoin Wallet, we can usually see account balance, but in the Bitcoin system designed by Satoshi Nakamoto, there is no such thing as a balance. A “Bitcoin balance” is a product derived from Bitcoin Wallet application. UTXO (Unspent Transaction Outputs) is Unspent Transaction Output, which is a core concept of Bitcoin transaction generation and verification. Transactions form a chain structure where all legitimate Bitcoin transactions can be traced back to the output of one or longer transactions forward, with mining rewards at the source and current unspent transaction output at the end.

So there is no Bitcoin in the real world, only UTXO. Bitcoin transactions consist of transaction inputs and transaction outputs, and each transaction spends an input to produce an output, and the resulting output is the “unspent transaction output”, that is, UTXO.

If you want to implement smart contracts, the UTXO account model has a very big problem. Gavin Wood, the designer of the Ethereum Yellow Book, has a deep understanding of UTXOs. The biggest new feature of Ethereum is smart contracts, because 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 for each transaction, the corresponding account is recorded (nonce++). In order to make it easier to manage the accounts, a global state is introduced, which changes with each transaction. This corresponds to the real world, where every small change changes the world. Therefore, Ethereum uses an account system, and the later public chains are basically based on various types of account systems.

Another serious drawback of UTXOs is that they don’t provide granular control over the amount of withdrawals on accounts. This is explained in Ethereum’s White Paper.

2. Bitcoin’s scripting language, non-Turing complete

Although the Bitcoin scripting language can support longest computations, it cannot support all computations. The main missing thing is Bitcoin’s scripting language, which has no loop statements and conditional control statements. Therefore, we say: the Bitcoin scripting language is not Turing complete. This leads to the Bitcoin scripting language, which has certain limitations. Of course, because of these limitations, Hacker can’t use this scripting language to write some endless loops (which can cause network crashes) 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 integrity 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 an infinite loop when a transaction is confirmed.

For the sake of security, the argument not to support Turing Complete is insufficient. And non-Turing Complete languages do very little.

3. Other imperfections of Bitcoin, security, scalability

The centralization problem of Mining Bitcoin Mining Algorithm is basically Block Header Miner k 10,000 minor changes until the hash of the changed version of a Node is less than the target value. However, this Mining Algorithm is susceptible to two forms of centralized attacks. First, the Mining ecosystem is specifically designed to be controlled by ASICs (Application-Specific Integrated Circuit) and computer chips that are k times more efficient for the specific task of Bitcoin Mining. This means that Bitcoin Mining is no longer highly Decentralization and egalitarian, but requires the effective participation of huge capital. Second, most Bitcoin Miner no longer validate Block locally, but instead rely on centralized Mining Pool to provide Block Header. The problem is arguably serious: currently, the top three mining pools indirectly control about 50% of the processing power in the Bitcoin network.

The issue of scalability is an important issue for Bitcoin. With Bitcoin, it rises by about 1 MB per hour. If the Bitcoin network processes 2000 transactions per second for Visa, it will rise by 1 MB every three seconds (1 GB per hour, 8 TB per year). The lower number of transactions has also caused controversy in the Bitcoin community, and although large Blockchain can improve performance, the problem is centralization risk.

From the perspective of the product life cycle, some small imperfections of Bitcoin can be improved in its own system, and the method of improvement is limited by the current system. But if these problems can be solved in a new system, the limitations of the old system can be ignored altogether. Since we want to build a new Blockchain system, when designing a new system, these small functional improvements are also designed and upgraded.

Layered Design

Hierarchical design is a means and methodology for human beings to deal with complex systems, by dividing the system into longest hierarchies and defining the relationships and functions of each layer, so as to achieve the modularity, maintainability and scalability of the system, so as to improve the design efficiency and reliability of the system.

For a broad and large system of protocols, there are clear benefits to using layering. This makes it easy for people to understand, easy to implement and easy to improve in modules. For example, the seven-layer model design of ISO/OSI in computer networks, but in the specific implementation, some layers can be combined, for example, the specific network protocol TCP/IP is a four-layer protocol. Specifically protocol advantages of stratification: each level is independent, flexible, structurally play people for suckers separable, easy to implement and maintain, and can promote standardization.

From the perspective of hierarchical protocol, Bitcoin because he wants to be at the most basic bottom, then his UTXO, non-Turing Complete, long block time, small Block Size, and the disappearance of the founder、… , which is not a disadvantage, but a feature that should be possessed as a first-layer network.

Note: The author has a more detailed explanation of the protocol stratification in “Sorting out the Basic Knowledge System of Bitcoin Layer 2 (Layer 2) Construction V1.5 in One Article”.

2 Important new technologies in the development of Bitcoin (Block scaling and capacity scaling)

In the previous section, we explored the main conflicts and some examples of exploration of Bitcoin legacy technologies, but long led to Hard Fork or entirely new heterogeneous chains. On the Blockchain of Bitcoin itself, this kind of exploration has also produced long results, which is essentially the expansion of Block and capabilities. They are mainly manifested in the following aspects.

2.1 OP_RETURN

Bitcoin developers have always wanted to expand Bitcoin’s capabilities in several ways:

Use of OP_RETURN

OP_RETURN is a script Operation Code that terminates the script and returns the value at the top of the stack. This Operation Code is similar to the return function in a programming language. The functionality of the OP_RETURN Operation Code has been modified long times in the history of the Bitcoin, and it is now primarily used as a method of storing data on the ledger. The functionality of OP_RETURN Operation Code has changed significantly in the past, and it is now an important mechanism that allows us to store arbitrary data on-chain.

OP_RETURN is originally a return operation used to end the script execution early, and the result of the execution will be presented as a top-of-the-stack item. This Operation Code initially had an easily exploitable vulnerability, but Satoshi Nakamoto quickly patched the vulnerability.

Further changes to the OP_RETURN feature

In the Bitcoin Core v0.9.0 upgrade, the “OP_RETURN Output” script was made to a standard output type, allowing users to append data to an “unspendable transaction output”. The maximum amount of data available in these scripts was initially limited to 40 bytes, then increased to 80 bytes.

Store data on the Blockchain:

Changing OP_RETURN to always return false has an interesting result. Since no Operation Code or data is evaluated after OP_RETURN, network users are starting to use this Operation Code to store data in any format.

During the period of Bitcoin cash (BCH), i.e., August 1, 2017 - November 15, 2018, the length of data that can be attached to the output of OP_RETURN has been extended to 220 bytes, and larger data can facilitate innovative applications on Blockchain, such as posting content on Blockchain social media.

On BSV, the 220-byte limit remained in place for a short period of time. Subsequently, in January 2019, the Node also did not check if the script was within the maximum script size limit of 520 bytes because OP_RETURN Operation Code terminated the script in a way that Node did not validate any subsequent Operation Code. As a result, Node operators on the network decided to increase the maximum transaction size to 100 KB, giving developers the freedom to innovate longer applications, allowing new applications to put larger and more complex data into the Bitcoin ledger. There was an example of an application where someone would put an entire website into the BSV ledger.

OP_RETURN Although there is a certain expansion of functions, in general, the capabilities are still limited. This led to the creation of SegWit technology.

Segwit SegWit

SegWit, or Segregated Witness (SegWit for short), was first proposed by Pieter wuile (Bitcoin core developer and co-founder of Blockstream) in December 2015 and later formed Bitcoin BIP 141. SegWit slightly modify the data structure of the transactions in the Bitcoin Block to solve the following problems:

1. Transaction malleability issues.

2. The signature of the transmitted transaction in the SPV proof becomes optional, which can reduce the amount of data transmitted by the Merkle proof.

3. Increase the block size in disguise.

The first two items are mainly to increase security and performance, and the third item has the long impact on the new technology, where monetization increases the capacity of Block (see the concept of block weight below), thus laying the foundation for the Bitcoin to expand its capabilities, so that the later Taproot (the second version of the SegWit) is further strengthened.

While monetization increases block size, SegWit is also limited by Block size. Bitcoin has a Block size limit of 1 M bytes, and since witness data is not included in this limit, the total Block size is still limited to prevent witness data from being abused. A new concept called block weight has been introduced.

Block weight = Base size * 3 + Total size

The base size is the block size that does not contain witness data

The total size total size is the block size (in bytes) of the serialization transaction as described in BIP 144, including the underlying and witness data.

SegWit limit Block weight <= 4 M.

SegWit also technically enables Bitcoin to scale using the Lighting Network, which is not detailed here.

Taproot SegWit V2 Version

If you use the word Taproot directly, long people think it’s a new concept, but if you tell you that this is the second version of SegWit, most people will understand the relevance. The BIPs associated with Taproot are 340 , 341 , 342 and their names are: BIP 340 (Schnorr Signatures for secp 256 k 1), BIP 341 (Taproot: SegWit version 1 spending rules), BIP 342 (Validation of Taproot).

In November 2021, Taproot officially took effect in the form of a soft fork. This upgrade is a combination of BIP 340, BIP 341, and BIP 342. BIP 340 replaces Elliptic Curve Digital Signature Algorithm (ECDSA) by introducing Schnorr signatures that can verify long transactions at the same time, once again expanding network capacity and speeding up batch transactions, opening up the possibility of deploying complex smart contracts, BIP 341 implements a Merkelized Abstract Syntax Tree (MAST) to optimize transaction data storage on Blockchain, and BIP 342 (Tap) Insufficient ability to use Bitcoin’s scripting and coding language to augment Bitcoin’s native footsteps.

The expansion of the short between SegWit Segwit and Taproot led to the creation of Schnorr, MAST trees, and Taproot s, whose mission was to expand the functionality of Bitcoin Mainnet.

2.2 Schnorr、MAT、Taproot s

Through section 2.1, we have seen the continuous exploration of Bitcoin in scaling and capacity expansion, until the emergence of Taproot technology, as well as several related important technologies Schnorr, MAST, Taproot s, Bitcoin’s ability pattern has really been opened.

Schnorr Signature

The development of Taproot expanded its capabilities with certain requirements for Signature Algorithm, and Schnorr signatures began to appear as an alternative to elliptic curve Digital Signature Algorithm (ECDSA). Schnorr signature is a Digital Signature scheme that efficiently and securely signs transactions and messages. It was first described by Claus Schnorr in a 1991 paper. Schnorr has been praised for its simplicity, provable security, and linearity.

Advantages of Schnorr signatures:

1. Schnorr signatures offer longest benefits, including high efficiency, enhanced privacy, while retaining all the functionality and security assumptions of ECDSA. Schnorr signatures allow for smaller signature sizes, faster verification times, and improved resistance to certain types of attacks.

2. The most significant advantage of Schnorr signing is Secret Key aggregation, which aggregates longest signatures into a single signature that is valid for the sum of their secret keys. In other words, Schnorr enables longest partners to generate a signature that is valid for the sum of their public keys. Signature aggregation enables signatures from longest signers to be combined into a single signature.

Secret Key aggregation drop Money Laundering and improves the underlying scalability because electronic signatures from long signature settings occupy the same short in the Block as signatures from unilateral transactions. This feature of Schnorr can be used to reduce the size of multisignature payments and other multisignature-related transactions, such as Lighting Network channel transactions.

3. Another important feature of Schnorr signatures is their immutability.

4. Schnorr also offers longest privacy advantages. By making multisignature schemes externally indistinguishable from traditional single public keys, Schnorr makes it harder for observers to distinguish between multisignature spending and single-signature spending in on-chain activity. In addition, in an n-of-m multisignature setup, Schnorr makes it more difficult for outside observers to determine which participants signed and which did not sign the transaction by looking at on-chain information.

The Schnorr signature was implemented in BIP-340 as part of the Taproot Soft Fork upgrade and was activated on Block Height 709, 632 on November 14, 2021. Schnorr makes BTC’s Digital Signature faster, safer, and easier to process. It’s worth noting that Schnorr signs Cryptography Algorithm backward compatibility with BTC so that they can be introduced through Soft Fork upgrades.

MAST Abstract Syntax Tree

There is a slight ambiguity in the abbreviation of MAST in both Chinese and English. The official BIP (BIP 114) and some articles use the abbreviation MAST as: Merklized Abstract Syntax Tree. Some other materials are translated into Chinese Merklized Alternative Script Trees (MAST) using Merklized Alternative Trees (MAST). In the book “Mastering Bitcoin”, and an article is this abbreviation:

The Merkel Abstract Syntax Tree and the Merklized Alternative Script Tree (MAST) look identical in function. From a translation point of view, I personally feel like keeping Bitcoin usage in the official BIP protocol.

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

Abstract Semantic Tree (AST) belongs to the knowledge field of compilation principles and formal linguistics in computer science. An abstract semantic tree is an intermediate representation in the compilation process that represents the semantic structure of Source Code. It converts the Source Code into a tree-like structure where each Node represents a semantic unit and edges represent the relationships between them. Abstract semantic trees play an important role in the lexical and syntactic analysis stages of the compiler, helping the compiler understand the meaning of the Source Code and perform subsequent optimization and the process of generating object code. In layman’s terms, an abstract semantic tree (AST) is a method of describing a program by playing people for suckers into separate chunks, which makes it easier to analyze and optimize. IN ORDER TO GENERATE AN AST, ALL EQUATIONS NEED TO BE CONNECTED WITH THEIR PREMISES WITH ARROWS UNTIL ALL PREMISES ARE FOUND. THE FOLLOWING FIGURE IS AN AST FOR A PIECE OF SCRIPT.

A Merkle tree, on the other hand, can be used to verify that an element belongs to a collection without having to know the full picture of the entire set. For example, Bitcoin’s simplified payment verification Wallet (SPV wallet) uses Merkle Tree to verify that a transaction exists in a certain Block, which saves bandwidth without having to download the full Block.

To generate a Merkle Tree, each element is hashed once to generate its own unique identifier, and then these identifiers are paired and hashed again to generate an identifier for this pair of identifiers; and so on and so forth, until only one identifier remains, called the “Merkle Root”, which is a short, concise identifier that marks the entire set.

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

In short, the technology behind AST allows you to divide a program into longest chunks, and the Merkle Tree allows us to verify that these chunks 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, with the advantages of reduced transaction size, increased privacy, and support for larger contracts.

There are longest cases of specific MAST trees on the Internet, and people who understand program development can clarify the relevant logic by sorting out the process of a MAST.

Now that there is a MAST abstract syntax tree, the ability to extend Bitcoin’s native syntax needs to be extended, so Taproot s is created.

Taproot s

Tap scripts are included in BIP 342 protocol, Taproot is an upgraded version of the original Bitcoin script, which can also be referred to as a language, but it is actually a collection of Operation Code with commands that power the implementation of the other two BIPs. Taproot also removes the 10,000-byte script size cap, providing a better environment for creating smart contracts on the Bitcoin network. (This upgrade also laid the groundwork for the later birth of Oridnals, because Ordinals protocol is the additional data implemented using Taproot’s -path spend s script.) For more information, please refer to the official website:

At present, the capabilities of the Taproot have not been fully utilized, and the later long construction will reflect its power. For example, the connection technology between Bitcoin L1 and L2 should use Taproot, MAST and TaprootScripits longest.

2.3 Ordinals, Inions, BRC 20 and other protocols

In the Bitcoin ecosystem, with Segwit, Taproot, Schnorr, MAST, Taproot, these basic tools, new applications began to emerge. The apps that start are those that are lightweight, simple.

Ordinals ordinal number protocol, inscription, BRC 20

The birth of the Ordinals protocol is highly related to the concept of sat, protocol the concept of ordinals and inscription (Incriptions) was proposed. Ordinals refer to the numbering scheme that assigns a number to each Satoshi (Satoshi) on the Bitcoin network in the order in which it is mined. Protocol, the ordinal identifier of the SAT remains the same regardless of how it is transferred between different wallets. These numbered Satoshi can be tracked by Bitcoin Full Node running the Rodarmor Open Source software ORD. This provides a mechanism for people to accurately track each Satoshi and verify it independently.

Inscriptions (Inions) are information by burning information on Satoshi. By combining SegWit and Taproot, Ordinals protocol can burn files smaller than 4 MB per Satoshi on the Bitcoin Block, which is inscription. Inscriptions can contain various forms of information, such as text, pictures, videos, etc. The image below is a screenshot of the sample inscription.

To put it simply, the numbering scheme of ordinal numbers provides a unique traceability number for each Satoshi, making Satoshi have the characteristics of non-homogeneity. inscription can add indivisible data information to the ordinal number, similar to creating art on a blank piece play people for suckers 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 a NFT protocol, but unlike the NFT Metadata (MetaData) of ETH or other public chains long which are stored in FIL or centralized servers, the Metadata of Ordinals is embedded in the Witness Data field of the transaction, as if it is “inscribed” to a specific Satoshi, which is where the word inscription comes from.

BRC-20: Inspired by the Ordinals protocol, Twitter user @domodata created Bitcoin experimental alternative token standards BRC-20 on March 8, 2023. Ordinals protocol creates BTC network NFT by assigning different “attributes” to each Satoshi, while BRC-20 creates FT on BTC, or Fungible Token, by assigning a uniform “format” and “attributes”.

BRC-20 deploys Token contracts, minting coin, and transfer Token (Depoly, Mint, Transfer) by writing a piece of JSON text to a BTC inscription through Ordinals protocol, and the key to deployment is the Token name, total supply, maximum minting at a time, etc. For transfers or buy/sell transactions, additional NFTs are engraved to track off-chain balances. At the same time, due to the relatively imperfect ecological infrastructure of the BTC, there is a certain learning threshold, and the low Liquidity makes the BRC-20 Token easily promoted, and the BRC 20 Token such as ordi, sats, rats, etc., has opened a wave of wealth creation myths.issuance coin

Other protocols - Atomicals, ARC 20

The birth of the Atomicals protocol was quite dramatic, and founder Arthur wanted to develop a DID project on top of the Ordinals protocol when it was first released, but during the development process, he found that the Ordinals protocol had longer limitations to support some of the features he wanted to implement. So, on May 29, 2023, Arthur tweeted the first tweet about the idea of the Atomicals protocol, and after several months of development, the Atomicals protocol went live on September 17, 2023. Later, the Atomicals protocol derived four major concepts such as Dmint, Bitwork, ARC-20, RNS, etc., and AVM and splitting protocols will be launched in the future.

Similar to Ordinals and BRC 20, deploying Fungible Tokens on top of Atomicals forms ARC 20. For those interested in ARC 20, you can read further.

Other protocols - Rune

As it developed, Casey Rodarmor, the founder of Ordinals, published an article stating that the BRC-20 Token has “undesirable consequences of UTXO proliferation” and suggested Runes as a UTXO-based alternative. The existing protocol generally have problems such as complex protocol implementation, poor user experience, garbage unspent transaction output (UTXO), and the need for native Token for operations.

Runes’ transition uses OP_RETURN, protocol the first data output in the message is decoded into a sequence of integers that are interpreted as a (ID, OUTPUT, AMOUNT) tuple sequence. 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 allocated to (i.e., to the first few outputs), and AMOUNT is the amount of runs to be allocated. Once all tuple allocations have been processed, any unallocated Runes Tokens will be allocated to the first non-OP_RETURN output, and the rest can be burned by assigning Runes protocol to the OP_RETURN output containing protocol messages.

Issuance of Runes: UTXO-based fungible Token tracking. If there is a second data push for protocol message, it is a issuance transaction. THE SECOND DATA PUSH IS DECODED INTO TWO INTEGERS, SYMBOL, DECIMALS. If there are other remaining integers, the protocol message is invalid. SYMBOL is a basic 26-bit readable symbol, similar to the one used in Ordinals names, with the only valid characters currently being A to Z. DECIMALS is the number of digits after the decimal point that should be used when displaying issuance Runes. If the SYMBOL has not already been assigned, the Runes Token will be assigned an ID value (starting at 1). If the SYMBOL has already been assigned, or is BITCOIN, BTC, or XBT, no new runes will be created. This is what makes the Runes protocol special. 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 allocates that supply to a specific UTXO. Any number of rune Tokens can be included in a UTXO, regardless of their size. UTXOs are only used to track balances. The transfer function then uses that UTXO, plays people for suckers into longest 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 no native Token, which is a good fit for Bitcoin’s native UTXO model.

Other protocols - BTC stamps, SRC 20, SRC 721

Released in March 2023 by Mike In Space, the Bitcoin Stamps system began as a proof-of-concept project on Counterparty (a Bitcoin L2 that has been around since 2014). Due to an update to its underlying protocol, Stamps has fully switched to Bitcoin, which last summer, now known as SRC-20. Founder Mike originally envisioned Stamps as a way to minting permanent Bitcoin NFT. However, the protocol has expanded to replicate the BRC-20, a bulk alternative Token that has flourished on Bitcoin since Casey Rodarmor launched Ordinals in January 2023 due Token to the rise of the inscription craze.

The main difference between Stamps and Ordinals is the architecture. This is because Stamps store their Metadata in Multisignature Unspent Transaction Output (UTXO), while Ordinals store their Metadata in the “Witness” section of Bitcoin transactions. This design distinction shows the trade-offs of developers. That said, Stamps’ UTXO method makes them untrimmed and therefore appear permanent, although they are more expensive to manufacture than Ordinals minting. Instead, Ordinals uses witness data in a way that ultimately makes them prunable, and they’re cheaper to manufacture than Stamps.

So, while Ordinals may offer the best durability-to-cost ratio for NFT in today’s encryption space (which can also be on-chain NFT on Ethereum, but they are comparatively more expensive to build than Ordinals), Stamps currently seem to offer the best direct permanence guarantee.

After the generation of BTC stamps, SRC 20 and SRC 721 began to be produced, similar in principle to BRC 20. BRC-20 is built on the Ordinals protocol, while SRC-20 is built on BTC STAMPS. Interested readers can read more about SRC 20 and SRC 721.

At this point, the important new technologies of Bitcoin on the first-layer network have been introduced. In terms of subsequent expansion and capacity expansion, it began to use Bitcoin’s upper facilities, such as Bitcoin’s Layer 2 or higher layers such as RGB with the help of the Lighting Network. Articles in this regard recommend reading “An article sorting out the basic knowledge system of Layer 2 construction of Bitcoin V1.5” and “Looking at Bitcoin layer 2 from the perspective of state machines, you can see the architecture and construction path of future Web3.0 applications”, or other articles on Bitcoin layer 2 construction or architecture design.

3 How new technologies are used and what needs to be developed in the future

Through the content of the second section, we see that the technological development of the Bitcoin ecosystem has laid the foundation for large-scale adoption. However, because the development requires a process and the immaturity of some related technologies, there is still a big difference between the current popular applications and the final common applications.

3.1 How to use new technology

As we can see from the previous two sections, the development of Bitcoin technology is essentially the expansion of Block and capabilities.

In terms of Block expansion, SegWit has led to de facto Block expansion, and although there are various proposals to cut out the testimonial part, it is unlikely that this kind of thing will happen, especially after the testimonial part has been given a more long meaning.

In terms of expansion capabilities, technologies such as Taproot, Schnorr, MAST, and Taproot S give Bitcoin more long capabilities. In particular, MAST+Taproot s will extend the capabilities of Bitcoin’s native scripting language, plus several other technologies will extend the Bitcoin language’s ability to handle complex scenarios. But these capacity expansions will also make Bitcoin development and understanding more difficult, after all, these s 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 the Block Size expansion.

Because it is easy to expand the capacity of the Block and complex to expand the capacity of the capacity, this is the reason why users will write those small picture NFT to the Bitcoin Mainnet in the first place, and applications such as BRC 20 will be produced. Almost all of the long applications on the current Bitcoin Mainnet are exploring Block scaled applications. A small number of applications have begun to explore capacity expansion, for example, the connection of BEVM Layer 1 and Layer 2 is representative, and the functions built by the above basic elements are more long. Its Shnorr signature + MAST contract + Bitcoin light node network BTC L2 solution is a good example of learning to connect Layer 1 to Layer 2. In the future, there will be more cases of capacity expansion.

Where should the boundaries of capacity expansion be? We can judge from the perspective of hierarchical design, if these capacity expansions are more long as Bitcoin layer 1 and layer 2 connection technology, then capacity expansion should not be overly complicated. However, based on the rich creativity of our human beings and the strong attraction of asset issuance and management, some teams or individuals will explore more long cases of capability expansion scenarios.

3.2 Requirements for future development

The most direct reason for the generation of Blockchain technology is digital money, so the issuance of assets, asset management and other applications are one of the most direct needs in the field of Bitcoin or Blockchain. Whether it is from the exploration of colored coins to applications such as BRC 20 and ARC 20, or ICOs and IDOs on Ethereum, they are all exploring asset issuance. Ethereum With the development of Bitcoin ecosystem technology, these asset management applications will be transferred to the Bitcoin ecosystem, and more long should be carried out on the second layer of Bitcoin.

After meeting the needs of issuance assets and managing assets, we will have the energy and time to develop large-scale applications that belong to the Web3.0 era (which can also be called 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 state machines, you can see the architecture and construction path of future Web3.0 applications”.

The path of construction is the process of continuously meeting demand, which can be divided into three stages: short-term, medium-term and long-term. In the short term, the applications generated by Bitcoin Mainnet above new technologies and the simple stage of chain-based layer 2 construction will complete the main capacity expansion to meet various financial applications. The mid-to-late stage of the chain-based Layer 2 construction and the Layer 2 construction based on the distributed system meet the needs of various financial applications and trust applications. The long-term is based on the large-scale construction of the Bitcoin ecology to complete the construction of the real Web3.0 era.

References

ABCDE Research Report[ABCDELabs]The Past, Present and Future of Bitcoin

Segregated_Witness

Taproot_activation_proposals

Super Detailed SegWit (Segregation witness),

Explaining: What is a Merkelized Abstract Syntax Tree for Bitcoin?,