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

Main Explorations and Conflicts of Bitcoin’s Original Technology

Bitcoin’s original technology has always faced conflicts between its capability for mass adoption and the functionality it ought to possess. Does scaling and transaction volume imply more complex transaction commands and greater transaction space? Does it mean that all functions must be implemented on a single Bitcoin system? In the early days, when the development of Bitcoin’s ecosystem technology was incomplete, these issues seemed inherent to Bitcoin itself. However, as technology has advanced, many of these issues have become clearer.

This article lists some of the related issues, along with the processes through which they arose and were addressed. Through this article, one can see the connection between these issues and the technology, as well as the changes in Bitcoin’s main chain and related “test chains.” Bitcoin’s technology has been continuously explored by various projects and teams (including Ethereum, which is an exploration of Bitcoin’s imperfections). However, changes on Bitcoin’s mainnet were not very apparent until the advent of technologies like Taproot, which spurred the development of protocols such as Ordinals, leading to a new surge in development.

From a broader perspective, looking at these developments and the technologies they’ve produced, we can see their connections and infer more directions for development and the overall architecture.

1.1 Bitcoin’s Scripting Language and Several Instruction Reductions

Bitcoin’s programming language is a stack-based scripting language using Reverse Polish Notation, lacking loop and conditional control statements (later expansions like Taproot & Taproot Script have enhanced this capability). Therefore, it is often said that Bitcoin’s scripting language is not Turing-complete, limiting its capabilities.

Because of these limitations, hackers cannot use this scripting language to write infinite loops (which would cripple the network) or code that could lead to DOS attacks, thereby safeguarding the Bitcoin network from DOS attacks. Bitcoin developers also believe that the core blockchain should not have Turing completeness to avoid certain attacks and network congestion.

However, these limitations mean that the Bitcoin network cannot run other complex programs or perform some “useful” functions. Subsequent blockchain systems developed to solve specific problems and meet user needs have changed this aspect. For example, the language used by Ethereum is Turing-complete.

Common types of Bitcoin script instructions include:

Keywords:

1. Constants. e.g., OP_0, OP_FALSE

2. Flow control. e.g., OP_IF, OP_NOTIF, OP_ELSE, etc.

3. Stack operations. e.g., OP_TOALTSTACK (pushes input to the auxiliary stack, removing it from the main stack), etc.

4. String operations. e.g., OP_CAT (concatenates two strings, disabled), OP_SIZE (pushes the length of the top stack element’s string onto the stack without popping the element)

5. Bitwise logic. e.g., OP_AND, OP_OR, OP_XOR

6. Arithmetic logic. e.g., OP_1ADD (adds 1 to input), OP_1SUB (subtracts 1 from input)

7. Cryptography. e.g., OP_SHA1 (hashes input with SHA-1 algorithm), OP_CHECKSIG

8. Pseudo keywords

9. Reserved keywords

Common types of Bitcoin script:

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

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

3. Provable unspendable / prunable outputs

4. Anyone-Can-Spend outputs

5. Puzzle transaction

The five standard types of transaction scripts include: payments to public key hash (P2PKH), payments to public key, multisig (limited to 15 keys max), payments to script hash (P2SH), and data outputs (OP_RETURN).

For more detailed information on Bitcoin scripting, you can visit: Bitcoin Wiki - Script.

Reduction of Supported Instructions in Bitcoin

Historically, Bitcoin has undergone several reductions in supported instructions. In the following chart, the red parts are instructions that have been removed.

• String operations

（2）

(3) Arithmetic operations

Why reduce instructions? Security is only one aspect to consider. If we view the reduction of instructions through the lens of layered design, we can understand its rationality, allowing the base protocol to be more fundamental and stable. Perhaps Satoshi Nakamoto was aware of this issue from the beginning, which is why he actively reduced instructions. Ordinary thinking is to build a small system that directly satisfies user needs with complete commands and system features, rather than a large protocol that requires collaboration.

This also leads to a fact: only Bitcoin is suitable as a first-layer network. I analyzed this phenomenon in the article “High Bitcoin Prices May Foster the Emergence of a New Alternative Chain”, considering both economic and technical perspectives, and the possibility of the emergence of a Bitcoin alternative chain. However, from the fundamental characteristics of Bitcoin and the perspective of layered design, almost only Bitcoin can serve as a first-layer network infrastructure; even if there are alternative chains, they would be a 1.5-layer product. At the first-layer level, the genuine article is only Bitcoin, and at most, other chains can serve as alternative goods of lesser quality.

1.2. Bitcoin Fork History, Reasons, and Significance

In the history of Bitcoin’s development, apart from the issue of reducing instructions, another aspect is the block size debate, which often leads to hard forks of Bitcoin.

When BTC was established, there was no block size limit to allow a certain number of transactions to be processed within the same timeframe. However, when the early BTC prices were very low, the cost of malicious transactions was also very low. To address this issue, Satoshi Nakamoto led a soft fork on September 12, 2010, introducing a limit that blocks could not exceed 1 MB in size. Satoshi noted that this restriction was temporary, and that in the future, the block limit could be increased in a controlled and gradual manner to meet the needs for expansion.

With the popularity of Bitcoin, the problem of network transaction congestion and increased confirmation times has become increasingly 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 size limit to 8 MB. However, core developers like Greg Maxell, Luke Jr, and Pieter Wuille opposed this, arguing that it would raise the barrier to running a full node and could have uncontrollable impacts. This debate eventually expanded in both scope and participation.

From the content above, we see that Satoshi Nakamoto also expressed that “the block size limit is a temporary constraint that can be increased in a controlled and gradual manner in the future to meet the needs for expansion.” But when will a fork support larger blocks, and can splitting off a separate chain to support large blocks solve the problem? Amid ongoing controversies, numerous cases have emerged. For example, the BCH block size is 8 MB, later increased to 32 MB. BSV has a block size of 128 MB. Apart from BCH (and later BSV), this period also saw many other BTC forks; according to BitMEXResearch, at least 50 new forked coins appeared in the year following the BCH fork alone.

Later content will show that on the Bitcoin mainnet, Segwit and Taproot also increased the block space from 1 MB to 4 MB to some extent.

Bitcoin’s forks are a form of developmental exploration, attempting to meet a wider range of needs through changes within itself, including the needs of users, miners, investors, developers, and more.

1.3. Several Typical Explorations in the Development of Bitcoin

After Satoshi Nakamoto left, his successor Gavin Andresen took the lead in establishing Bitcoin Core and the Bitcoin Foundation. During this period, explorations into the scalability of BTC, particularly in the area of asset issuance, persisted.

(1) Colored Coins (染色币)

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

The idea behind colored coins is to represent a wider range of assets and values by adding special markings (i.e., coloring) to specific parts of Bitcoin. In implementation, colored coins have emerged in several entities, broadly divided into two categories:

1) Based on OP_RETURN: As proposed by Flavien Charlon in 2013, using Open Assets, which utilizes OP_RETURN (introduced in Bitcoin v0.9.0 to store a small amount of data on Bitcoin, originally limited to 40 bytes, later increased to 80 bytes). The opcode is stored in the script and “coloring” and transactions are completed by external reading (This model is similar to Ordinals, which rely on an external index to determine the legality of assets).

2) Based on OP_RETURN: A typical example is the EPOBC Protocol proposed by ChromaWay in 2014, where additional information of EPOBC assets is stored in the nSequence field of Bitcoin transactions, and the category and legality of each EPOBC asset must be traced back to the genesis transaction to determine.

(2) MasterCoin (OMNI)

JR Willett released the concept of MasterCoin on January 6, 2012, naming it “the second Bitcoin white paper”, and officially launched the project through an ICO in July 2013, eventually raising 5120 BTC (valued at $500,000 at the time). The distinction between MasterCoin and Colored Coins lies in that it established a complete node layer, which maintains a state model database by scanning Bitcoin blocks, residing in nodes outside of the blockchain. This design provides more complex functionalities than Colored Coins, such as creating new assets, decentralized exchanges, and automated price feedback mechanisms. In 2014, Tether also launched the stablecoin known as Tether USD (OMNI) on Bitcoin through the Mastercoin protocol.

(3) CounterParty

Counterparty was officially launched in 2014. Like Colored Coins, 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 UTXOs, but instead, information is loaded through OP_RETURN to indicate asset transfers. When an asset holder signs a transaction containing special data using the holding address, the asset is transferred. Through this method, Counterparty can implement asset issuance, trading, and a platform compatible with Ethereum smart contracts.

Additionally, some views also consider Ethereum, Ripple, and BitShares as part of a broader “Bitcoin 2.0”.

1.4 Imperfections of Bitcoin and Layered Protocols

Bitcoin’s imperfections (or limitations) are primarily manifested in several aspects (the imperfections mentioned in this article are based on the summary in the Ethereum whitepaper and are not necessarily true flaws).

1. Bitcoin’s UTXO Account System

In current blockchain projects, there are mainly two types of record-keeping methods: the account/balance model and the UTXO model. Bitcoin uses the UTXO model, while Ethereum, EOS, and others use the account/balance model.

In a Bitcoin wallet, we can usually see the account balance; however, in Satoshi Nakamoto’s original design of the Bitcoin system, there was no concept of a “balance.” The “Bitcoin balance” is a derivative of Bitcoin wallet applications. UTXO (Unspent Transaction Outputs) represents unspent transaction outputs, and it is a core concept in the generation and verification of Bitcoin transactions. Transactions form a chain-like structure where all legitimate Bitcoin transactions can be traced back to outputs from one or more previous transactions. These chains start with mining rewards and end with current unspent transaction outputs.

Therefore, in the real world, there are no bitcoins, only UTXOs. Bitcoin transactions consist of transaction inputs and outputs; each transaction spends an input to produce an output, which then becomes the “unspent transaction output,” or UTXO.

Implementing smart contracts presents significant challenges with the UTXO model. Gavin Wood, the designer of the Ethereum Yellow Paper, has a deep understanding of UTXO. Ethereum’s most significant new feature 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, which is inherently object-oriented, records each transaction on the corresponding account (nonce++). To facilitate account management, a global state is introduced where each transaction alters this global state, analogous to how every small change affects the real world. Thus, Ethereum and subsequent public blockchains are generally based on various types of account systems.

Another severe flaw of UTXO is its inability to provide fine control over account withdrawal limits, which is discussed in the Ethereum white paper.

1. Bitcoin’s Script Language, Not Turing-Complete

While Bitcoin’s script language can support various computations, it cannot support all computations. The main omission is that Bitcoin’s script language lacks looping statements and conditional control statements. Hence, Bitcoin’s script language is not Turing-complete, limiting its capabilities. However, these limitations prevent hackers from using this script language to create infinite loops (which could paralyze the network) or malicious code that could lead to DOS attacks, thus protecting the Bitcoin network from DOS attacks. Bitcoin developers also believe that the core blockchain should not be Turing-complete to prevent attacks and network congestion. However, the reason that a non-Turing-complete language is safer is insufficient, and such a language can only perform limited functions.

1. Other Imperfections of Bitcoin: Security, Scalability

The centralization of mining is a problem, where Bitcoin’s mining algorithm essentially allows miners to make minor modifications to the block header millions of times until a node’s modified version’s hash is less than the target value. This mining algorithm is susceptible to two forms of centralization attacks. First, the mining ecosystem is controlled by ASICs (Application-Specific Integrated Circuits) and computer chips designed specifically for Bitcoin mining, which are thousands of times more efficient at this task. This means that Bitcoin mining is no longer highly decentralized and egalitarian but requires substantial capital for effective participation. Second, most Bitcoin miners no longer complete block validation locally; instead, they rely on centralized mining pools to provide the block headers. This issue is significant: currently, the top three mining pools indirectly control about 50% of the processing power in the Bitcoin network.

Scalability is an important issue for Bitcoin. Using Bitcoin, the data grows by about 1 MB per hour. If the Bitcoin network processed 2000 transactions per second like Visa, it would grow by 1 MB every three seconds (1 GB per hour, 8 TB per year). Lower transaction numbers have also sparked controversy within the Bitcoin community, as larger blockchains can improve performance, but at the risk of centralization.

From a product lifecycle perspective, some of Bitcoin’s minor imperfections can be improved within its own system, constrained by the current system. However, these problems can be resolved without considering the constraints of the old system if they are addressed in a new system. If a new blockchain system is being developed, then these minor functional improvements should also be designed and upgraded.

Layered Design

Layered design is a methodology and approach used by humans to handle complex systems by dividing a system into multiple hierarchical structures and defining the relationships and functions between these layers to achieve system modularity, maintainability, and scalability, thereby improving the system’s design efficiency and reliability.

For a broad and extensive protocol system, using layers has clear benefits. This approach makes it easier for people to understand

, implement, and improve modules. For example, in computer networks, the ISO/OSI model is a seven-layer design, but in practice, some layers can be combined, such as the four-layer TCP/IP protocol. Specific advantages of protocol layering include the independence and flexibility of each layer, structural divisibility, ease of implementation and maintenance, and facilitation of standardization efforts.

From the perspective of layered protocols, Bitcoin’s position as the foundational layer means that its characteristics like UTXO, non-Turing completeness, long block times, small block capacity, and the disappearance of its founder are not flaws but rather traits that a base network layer should have.

Note: The author provides more detailed explanations on protocol layering in “An Overview of Bitcoin Layer 2 (Layer 2) Construction Basic Knowledge System V1.5.”

2. Important New Technologies in Bitcoin Development (Block Expansion and Capability Enhancement)

In the previous section, we explored the main conflicts of the original Bitcoin technology and some exploratory cases, many of which led to hard forks or the creation of entirely new heterogeneous chains. However, within Bitcoin’s own blockchain, these explorations have also yielded many results, fundamentally in the form of block expansion and capability enhancement. These are mainly manifested in the following aspects:

2.1. OP_RETURN

Bitcoin developers have always sought to expand Bitcoin’s capabilities, manifested in several ways:

(1) Use of OP_RETURN

OP_RETURN is a script opcode used to terminate a script and return the top value of the stack. This opcode is similar to the return function in programming languages. Throughout Bitcoin’s history, the functionality of the OP_RETURN opcode has been modified multiple times, and it is now primarily used as a method to store data on the ledger. The functionality of the OP_RETURN opcode has undergone significant changes in the past, and it is now an important mechanism for storing arbitrary data on-chain.

Initially, OP_RETURN was used for prematurely ending script execution, with the execution result presented as the top stack item. This opcode initially had a vulnerability that was easily exploited, but Satoshi Nakamoto quickly patched it.

Further Changes to OP_RETURN Functionality

In the upgrade to Bitcoin Core v 0.9.0, “OP_RETURN output” scripts were made into a standard output type, allowing users to append data to “unspendable transaction outputs.” The data volume available in such scripts was initially capped at 40 bytes, then increased to 80 bytes.

Storing Data on the Blockchain:

Changing OP_RETURN to always return false had interesting results. Since no other opcodes or data are evaluated after OP_RETURN, network users began using this opcode to store data in arbitrary formats.

During the Bitcoin Cash (BCH) era, from August 1, 2017, to November 15, 2018, the data length that could be attached to OP_RETURN outputs was extended to 220 bytes, allowing more significant data to foster innovative applications on the blockchain, such as posting content on blockchain social media.

On BSV, the 220-byte limit was still retained for a short period. Later, in January 2019, because the OP_RETURN opcode terminates the script in a manner that nodes do not verify any subsequent opcodes, nodes also did not check whether the script was within the maximum script size limit of 520 bytes. Consequently, network node operators decided to increase the maximum transaction volume to 100 KB, thereby granting developers more freedom for application innovation, allowing new applications to place larger and more complex data into the Bitcoin ledger. At that time, there was an application example where someone put an entire website into the BSV ledger.

Although OP_RETURN has some functional expansions, its overall capabilities are still limited. This led to the technology of Segregated Witness.

(2) SegWit (Segregated Witness)

Segregated Witness, or SegWit, was first proposed by Pieter Wuille (Bitcoin core developer and co-founder of Blockstream) in December 2015 and later became Bitcoin BIP 141. SegWit slightly modifies the data structure of transactions in Bitcoin blocks to address the following issues:

1) Transaction malleability issue.

2) In SPV proofs, transferring transaction signatures becomes optional, reducing the data volume of Merkle proofs.

3) Indirectly increasing block capacity.

The first two items primarily increase security and performance, with the most impact on new technologies being the third item, which indirectly increased block capacity (see the concept of Block weight below), laying the foundation for the capability enhancement of Bitcoin, and leading to further enhancements in Taproot (the second version of Segregated Witness).

Although the realization increased block capacity, SegWit is still subject to block size limits. Bitcoin’s block size limit is 1 M bytes, and since witness data is not included in this limit, there is still a restriction on the total block size to prevent abuse of witness data. A new concept called Block weight was introduced:

Block weight = Base size * 3 + Total size

Base size is the block size excluding witness data

Total size is the total block size serialized according to BIP 144, including both base data and witness data.

SegWit restricts Block weight <= 4 M.

SegWit also technically enables Bitcoin’s expansion to use the Lightning Network, which is not detailed here.

(3) Taproot (Segregated Witness V2)

If you directly use the word Taproot, many people might think it’s a new concept, but if you understand that it’s the second version of Segregated Witness, most will grasp the connection. Taproot is associated with BIPs 340, 341, and 342, named: BIP 340 (Schnorr Signatures for secp256k1), BIP 341 (Taproot: SegWit version 1 spending rules),

BIP 342 (Validation of Taproot Scripts).

In November 2021, Taproot was officially activated as a soft fork. This upgrade combines BIP 340, BIP 341, and BIP 342. Among them, BIP 340 introduces Schnorr signatures that can simultaneously validate multiple transactions, replacing the Elliptic Curve Digital Signature Algorithm (ECDSA), once again expanding network capacity and speeding up the processing of batch transactions, providing possibilities for deploying complex smart contracts; BIP 341 implements Merklized Abstract Syntax Trees (MAST) to optimize transaction data storage on the blockchain; BIP 342 (Tapscript) uses Bitcoin’s script encoding language to enhance the native script capabilities of Bitcoin.

The space expansion caused by Segwit and Taproot led to the creation of Schnorr signatures, MAST trees, and Taproot Scripts, whose mission is to expand the functionalities of the Bitcoin mainnet.

2.2 Schnorr Signatures, MAST, and Taproot Scripts

From Section 2.1, we observed Bitcoin’s ongoing exploration in scaling and capability enhancement, culminating in the development of Taproot technology, along with several crucial technologies such as Schnorr, MAST, and Taproot Scripts, which have truly expanded the capabilities of Bitcoin.

(1) Schnorr Signatures

The evolution of Taproot, while expanding capabilities, required specific demands from the signature algorithm, thus introducing Schnorr signatures to replace the Elliptic Curve Digital Signature Algorithm (ECDSA). Schnorr signatures are a digital signing scheme that can efficiently and securely sign transactions and messages. They were first described by Claus Schnorr in a 1991 paper. Schnorr is acclaimed for its simplicity, provable security, and linearity.

Advantages of Schnorr Signatures:

1) Schnorr signatures offer several benefits, including efficiency and enhanced privacy while retaining all the functionalities and security assumptions of ECDSA. They enable smaller signature sizes, faster verification times, and improved resistance to certain types of attacks.

2) A notable advantage of Schnorr signatures is key aggregation, which aggregates multiple signatures into a single one that is valid for the sum of their keys. In other words, Schnorr allows multiple cooperating parties to generate a single signature that is valid for the total of their public keys. Signature aggregation allows the signatures of multiple signers to be combined into a single signature.

Key aggregation can reduce transaction fees and improve underlying scalability since electronic signatures from multisig setups occupy the same space in a block as those from single-party transactions. This feature of Schnorr can be used to reduce the size of multisig payments and other transactions related to multisig, such as Lightning Network channel transactions.

3) Another important feature of Schnorr signatures is their non-malleability.

4) Schnorr also offers numerous privacy advantages. It makes multisig schemes indistinguishable from traditional single-key ones to external observers, making it harder to differentiate multisig spending from single signature spending on-chain. Additionally, in n-of-m multisig setups, Schnorr makes it more difficult for external observers to determine which participants signed in a transaction and which did not.

Schnorr signatures are implemented in BIP-340 as part of the Taproot soft fork upgrade and were activated on November 14, 2021, at block height 709,632. Schnorr makes BTC’s digital signatures faster, more secure, and easier to handle. Notably, Schnorr signatures are backward compatible with BTC’s cryptographic algorithms, allowing them to be introduced through a soft fork upgrade.

(2) MAST Abstract Syntax Trees

There is a slight ambiguity in the abbreviation of MAST in Chinese and English. Officially, BIP (BIP 114) and some articles use the abbreviation MAST for: Merklized Abstract Syntax Tree. Other sources translate Merklized Alternative Script Trees (MAST) into Chinese as Merklized Replacement Script Trees (MAST). In the book “Mastering Bitcoin” and an article, this abbreviation is used: https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade.

Merklized Abstract Syntax Trees and Merklized Alternative Script Trees (MAST) appear to have the same function. From a translation perspective, I personally feel it is best to maintain the usage found in the official Bitcoin BIP protocol.

The concept behind MAST comes from two ideas: Abstract Syntax Trees and Merkle Trees.

Abstract Syntax Trees (AST) belong to the realm of compiler principles and formal linguistics in computer science. An abstract syntax tree is an intermediate representation during the compilation process, used to represent the semantic structure of the source code. It transforms the source code into a tree structure, where each node represents a semantic unit, and the edges represent the relationships between them. Abstract syntax trees play a crucial role in the lexical and syntactic analysis stages of the compiler, helping to understand the meaning of the source code and carry out subsequent optimization and target code generation processes. Simply put, an abstract syntax tree (AST) is a method of describing a program by dividing it into independent blocks, making the program easier to analyze and optimize. To generate an AST, all equations and their premises must be connected with arrows until all premises are identified. The image below is an AST of a script.

On the other hand, a Merkle tree can be used to verify whether an element belongs to a set without needing to know the entire set. For example, Bitcoin’s Simplified Payment Verification wallets (SPV wallets) use Merkle trees to verify whether a transaction exists within a block, saving bandwidth by not downloading the full block.

To generate a Merkle tree, each element is hashed individually to create a unique identifier; these identifiers are then paired and hashed again to create an identifier for that pair; this process is repeated until only one identifier remains, known as the “Merkle root,” which is a concise identifier that represents the entire set.

When verifying whether an element belongs to a set, the owner of the set can provide you with all the identifiers from that element to the Merkle root. This proves that the element is indeed part of the set.

In short, the technology behind AST allows you to divide a program into multiple small blocks, while a Merkle tree allows us to verify that these blocks are indeed parts of a whole program, without exposing the entire program. This is the basic principle of MAST, which allows spenders to replace unused conditions in a single transaction with a Merkle proof, with the benefits of reducing transaction size, enhancing privacy, and supporting larger contracts.

There are many examples of MAST trees online, and those familiar with program development can clearly understand the logic related to a MAST process.

With the advent of MAST abstract syntax trees, it becomes necessary to extend the native syntax capabilities of Bitcoin, leading to the creation of Taproot Scripts.

(3) Taproot Scripts

Introduced under the BIP 342 protocol, Taprootscript is an upgraded version of the original Bitcoin script, essentially a collection of operation codes with commands that support the implementation of other BIPs. Taprootscript also eliminates the 10,000-byte script size limit, providing a better environment for creating smart contracts on the Bitcoin network. This upgrade also laid the groundwork for the later development of Ordinals, which utilize Taproot’s script-path spend scripts to attach additional data. More details can be found at the official website:

https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

The capabilities of TaprootScript have not yet been fully utilized, and more developments in the future will demonstrate its potential, particularly in connecting Bitcoin’s first-layer network with second-layer technologies, where Taproot, MAST, and TaprootScripts will likely be used more extensively.

2.3 Ordinals, Inscriptions, BRC 20, and Other Protocols

With foundational tools like Segwit, Taproot, Schnorr, MAST, and Taproot Scripts in the Bitcoin ecosystem, new applications have begun to emerge. Initially, these applications were lightweight and simple.

(1) Ordinals Protocol, Inscriptions, and BRC 20

The creation of the Ordinals protocol is highly associated with the concept of satoshis. The protocol introduces the concepts of ordinals and inscriptions. Ordinals are a numbering scheme that assigns a unique number to each satoshi on the Bitcoin network according to the order they were mined. In the protocol, the ordinal identifier remains unchanged regardless of how the satoshi is transferred between different wallets. Bitcoin full nodes running Rodarmor’s open-source software, ORD, can track these numbered satoshis, providing a precise mechanism for people to track each satoshi and independently verify them.

Inscriptions involve engraving information onto satoshis. By leveraging SegWit and Taproot, the Ordinals protocol allows for the engraving of files smaller than 4 MB onto each satoshi on a Bitcoin block—these are the inscriptions, which can contain various types of information such as text, images, or videos.

In simple terms, the ordinal numbering scheme provides each satoshi with a unique, traceable identifier, giving it non-fungible characteristics. Inscriptions allow for the addition of indivisible data on these ordinals, akin to creating art on a blank canvas. Combined, they enable Bitcoin to host a new standard for NFTs. Essentially, Ordinals is like an NFT protocol but unlike ETH or other public blockchains where NFT metadata is usually stored on IPFS or centralized servers, Ordinals embeds metadata into the transaction’s witness data, as if “engraved” onto a specific satoshi.

BRC-20: Inspired by the Ordinals protocol, Twitter user @domodata created the experimental fungible token standard BRC-20 on Bitcoin on March 8, 2023. By assigning different “attributes” to each satoshi, the Ordinals protocol creates BTC network NFTs, whereas BRC-20 does so by providing a uniform “format” and “attributes” for BTC-based fungible tokens (FTs). BRC-20 employs the Ordinals protocol to write a JSON text into a BTC inscription to deploy token contracts, mint, and transfer tokens. Key deployment aspects include the token name, total supply, and maximum minting per occasion. For transactions involving transfers or buying/selling, an additional NFT tracks off-chain balances. A “first-come, first-served” minting mechanism provides fair issuance and participation opportunities. However, the relatively undeveloped infrastructure of the BTC ecosystem and its steep learning curve, coupled with low liquidity, make it easy for BRC-20 tokens like ordi, sats, and rats to surge, creating a wealth-creation myth.

(2) Other Protocols - Atomicals, ARC 20

The development of the Atomicals protocol was quite dramatic. Its founder, Arthur, initially wanted to develop a DID project on top of the newly released Ordinals protocol but realized that Ordinals had many limitations that were unfavorable for supporting some of the features he wanted to implement. Consequently, on May 29, 2023, Arthur tweeted about his concept for the Atomicals protocol, which was later launched on September 17, 2023, after months of development. Subsequently, the Atomicals protocol spawned concepts like Dmint, Bitwork, ARC-20, and RNS, with future plans to introduce AVM and splitting solutions. Like Ordinals and BRC-20, deploying fungible tokens on Atomicals results in the creation of ARC-20. Readers interested in ARC-20 can read further here: ARC-20 Tokens.

(3) Other Protocols - Rune

As the ecosystem evolved, Casey Rodarmor, the creator of Ordinals, pointed out that BRC-20 tokens have the “unfortunate consequence of UTXO sprawl” and suggested Runes as an alternative UTXO-based solution. Existing protocols generally suffer from complex implementations, poor user experiences, junk unspent transaction outputs (UTXOs), and operations requiring native tokens.

Runes’ transfer uses OP_RETURN, and the first data output in the protocol message is decoded into a sequence of integers, interpreted as a series of (ID, OUTPUT, AMOUNT) tuples. If the decoded number of integers is not a multiple of three, the protocol message is invalid. ID refers to the Token ID to be transferred, OUTPUT is the output index assigned (i.e., which output it is assigned to), and AMOUNT is the quantity allocated. After processing all tuple allocations, any unallocated Runes Tokens are assigned to the first non-OP_RETURN output, with the rest potentially being inscribed with Runes Tokens in the OP_RETURN output containing the protocol message.

Runes’ issuance is based on UTXO-tracking of homogeneous tokens. If the protocol message includes a second data push, it represents an issuance transaction. The second data push is decoded into two integers, SYMBOL and DECIMALS. If additional integers remain, the protocol message is invalid. SYMBOL is a basic 26-character readable symbol, similar to those used in Ordinals names, with the only valid characters being A to Z. DECIMALs indicate the decimal places to use when issuing Runes. If SYMBOL has not yet been assigned, the Runes Token is assigned an ID value (starting from 1). If SYMBOL has already been assigned or is one of BITCOIN, BTC, or XBT, no new Runes will be created. This is a special feature of the Runes protocol—it does not link balance records to wallet addresses but rather stores them within the UTXO itself. New Runes Tokens begin from the issuance transaction, specifying the supply, symbol, and decimal places, and this supply is allocated to specific UTXOs. UTXOs can contain any number of Runes Tokens, regardless of their size, and are used only for tracking balances. Then, the transfer function uses this UTXO, splitting it into multiple arbitrarily sized new UTXOs containing different amounts of Runes, sending the records to others. Compared to BRC-20, Runes simplifies the consensus layer, becoming simpler while not relying on off-chain data and lacking native tokens, making it highly suitable for Bitcoin’s native UTXO model.

(4) Other Protocols - BTC Stamps, SRC 20, SRC 721

The Bitcoin Stamps system was launched by Mike In Space in March 2023, initially as a proof-of-concept project on Counterparty, a Bitcoin Layer 2 that has existed since 2014. Due to updates in its underlying protocols, Stamps has completely transitioned to Bitcoin, becoming known as SRC-20 last summer. Initially, Mike envisioned Stamps as a method for minting permanent Bitcoin NFTs. However, the protocol has since expanded to replicate BRC-20, a type of batch-replaceable token that has thrived on Bitcoin due to the inscription craze sparked by Casey Rodarmor’s launch of Ordinals in January 2023.

The main difference between Stamps and Ordinals lies in their architecture. Stamps stores its metadata in multi-signature unspent transaction outputs (UTXOs), while Ordinals stores its metadata in the “witness” part of Bitcoin transactions. This architectural difference highlights the trade-offs made by developers. For instance, Stamps’ UTXO method makes them unprunable, thus appearing permanent, although their manufacturing cost is higher than that of Ordinals. Conversely, Ordinals’ use of witness data ultimately makes them prunable, and their manufacturing cost is lower than that of Stamps.

Thus, while Ordinals may offer the best durability-cost ratio for today’s crypto NFTs (which can also be obtained on Ethereum, but at a higher construction cost), Stamps currently seems to provide the best guarantee of direct permanence.

Following the emergence of BTC Stamps, SRC 20 and SRC 721 were developed, operating similarly to BRC-20. BRC-20 is built on the Ordinals protocol, while SRC-20 is built on BTC STAMPS. Interested readers can further read the SRC 20 and SRC 721 documentation here:

SRC 20 Protocol

SRC 721 Protocol

This concludes the introduction to significant new technologies on Bitcoin’s Layer 1 network. For further scaling and enhancement, the focus will shift to Bitcoin’s upper-layer infrastructure, such as Bitcoin Layer 2 or solutions leveraging the Lightning Network. For more on this topic, readers are suggested to read “A Comprehensive Guide to Bitcoin Layer 2 Infrastructure, Version 1.5” and “From the Perspective of State Machines: Observing the Architecture and Construction Path of Future Web3.0 Applications,” or other articles related to Bitcoin Layer 2 construction or architectural design.

3. New Technology Usage and Future Development Needs

Based on the content of Section 2, we observe that the technological evolution within the Bitcoin ecosystem has laid a foundation for broader applications. However, as development is a process and some related technologies are still immature, there is a significant difference between current popular applications and future common uses.

3.1 Methods of Using New Technology

From the previous sections, we see that the essence of Bitcoin’s technological development is about expanding block capacity and capabilities.

Block Expansion: Segregated Witness (SegWit) has effectively expanded block capacity, although there are various proposals to trim the witness data, such events are unlikely, especially after the witness data has gained more significance.

Capability Expansion: Technologies like Taproot, Schnorr, MAST, and Taproot Scripts have enhanced Bitcoin’s capabilities. Particularly, the combination of MAST and Taproot Scripts expands the abilities of Bitcoin’s native scripting language, allowing the handling of more complex scenarios. However, expanding these capabilities also increases the complexity of Bitcoin development and understanding, since script development is not conducted in a high-level language. Furthermore, the expansion of these capabilities lags behind users’ understanding and learning pace regarding block capacity expansion.

The simplicity of using block expansion versus the complexity of capability expansion explains why users initially store small picture NFTs on the Bitcoin mainnet, leading to the emergence of applications like BRC 20. Most applications currently on the Bitcoin mainnet are exploring post-block expansion uses. A small portion of applications are beginning to explore capability expansion, such as the connection between the first and second layers in BEVM, which prominently utilizes the aforementioned basic elements. The combination of Schnorr signatures, MAST contracts, and the Bitcoin lightweight node network (BTC L2) is a representative case of learning how to connect the first and second layers. More extensive capability expansion cases are expected in the future.

Where should the boundaries of capability expansion lie? We can judge from the perspective of layered design. If these capabilities are primarily intended as connections between Bitcoin’s first and second layers, then they should not become overly complicated. However, driven by human creativity and the strong allure of asset issuance and management, some teams or individuals will explore more scenarios for capability expansion.

3.2 Future Development Needs

The most direct reason for the emergence of blockchain technology is digital currency, so issuing and managing assets are direct needs within the Bitcoin or blockchain domain. From exploring colored coins to applications like BRC 20 and ARC 20, as well as ICOs and IDOs on Ethereum, these are all explorations of asset issuance. Applications like Uniswap, Lending, and AMMs are about asset management. These types of applications have matured on networks like Ethereum and, as Bitcoin’s ecosystem technology evolves, these asset management applications are likely to shift to Bitcoin’s ecosystem, particularly to Bitcoin’s second layer.

Only after fulfilling the needs of asset issuance and management will there be the capacity and time to develop large-scale applications for the Web3.0 era (also known as the Value Age). The system architecture for future large-scale Web3.0 applications is discussed in “From the Perspective of State Machines Viewing Bitcoin’s Second Layer, Observing the Future Web3.0 Applications Architecture and Construction Path.”

The path to construction is a process of continuously meeting needs, which can be divided into short-term, mid-term, and long-term stages. The short-term involves new technology applications on the Bitcoin mainnet and simple stages of blockchain-based second-layer construction to fulfill major capability expansions for various financial applications. The mid-term involves more advanced stages of blockchain-based second-layer and distributed system second-layer constructions, catering to various financial and trust applications. The long-term involves the complete construction of the large-scale Bitcoin ecosystem, truly building the Web3.0 era.

Disclaimer：

1. This article is reprinted from [Foresightnews], All copyrights belong to the original author [付少庆、SatoshiLab、万物岛 BTC 工作室]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.