Author: Fu Shaoqing, SatoshiLab, Everything Island BTC Studio

1 Preface

While studying Bitcoin technology, the author found that understanding SegWit, Taproot, and TaprootAssets from the perspective of the evolution of Segregated Witness makes it easier to learn and grasp their development patterns. This also helps to better understand the Taproot Assets protocol from Lightning Network Labs, the role of Universe, and the capabilities and future potential of the TaprootAssets protocol. With these insights, it becomes easier to design related products for users.

There are two important perspectives to keep in mind when reading this article: Bitcoin scaling and Bitcoin capability expansion.

Scaling refers to expanding the data capacity that Bitcoin can use and manage. In the early days, this was limited to the Block size, but later it refers to all data that can be managed by Bitcoin. The ultimate limit of scaling is managing infinite data space.

Capability expansion refers to enhancing the functionality that Bitcoin’s script instructions can achieve. The ultimate limit is achieving Turing-complete programming capability.

The entire history of Bitcoin is a history of scaling and capability expansion, including various Bitcoin fork chains, explorations on OP_RETURN, and three major Segregated Witness version upgrades.

Most readers can ignore the detailed technical diagrams of the three versions; these are included for the author’s deeper understanding and do not affect the reading experience.

The BIP protocols mentioned in the article are all marked with their respective dates, allowing readers to appreciate the time cycle from the birth of an idea to its deployment in production, and to gauge the difficulty of implementing the technology. More importantly, the protocol release and activation dates for the three Segregated Witness versions reveal the overall development pattern, making it easier to predict future trends. This serves as a valuable reference for teams developing products based on these technologies and protocols, helping them choose the right time to participate. Entering too early often means the supporting technology is immature, making pioneers “martyrs”; entering too late means missing the opportunity and becoming mere “spectators.” The author believes that entering just before the technology becomes available is the best timing. This judgment is often based on time and technical details.

# 1.1 Early Transactions (No Segregated Witness)

The transaction defined in the White Paper (the simplest transaction model):

![] ( https://img-cdn.gateio.im/social/moments-b 1d1e13125aa4168cb4b94759c9f4386)

The most basic early Bitcoin transaction allowed multiple inputs and two outputs. One output is the change returned to yourself, and the other is the transfer to an external party. (Note: The difference between total input and total output is the Trading Fee.)

Most transactions have two outputs, though there are scenarios with only one output, summarized as follows:

![] ( https://img-cdn.gateio.im/social/moments-eb 2838590b599622064e59c7164e4672)

To better illustrate the difference, we use a diagram with two inputs and two outputs. (Another main reason is that the reference material I used provided such a diagram, so I didn’t have to redraw it. Just being lazy ^_^)

Isn’t this comparative diagram easier to understand?

![] ( https://img-cdn.gateio.im/social/moments- 3bd23e4224babcd8d070dea206e8b1e8)

Comparison of traditional transaction diagram and Segregated Witness (SegWit) transaction diagram

# 1.2 Exploration on OP_RETURN

Why discuss OP_RETURN when talking about Segregated Witness? Because it was an earlier exploration than Segregated Witness and helps to better understand the reasons for Segregated Witness’s emergence.

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

OP_RETURN was originally used for early termination of script execution, with the result presented as the top item of the stack. There was an exploit in the original Operation Code, but Satoshi Nakamoto quickly patched it.

Further changes to OP_RETURN functionality

In the Bitcoin Core v0.9.0 upgrade, the “OP_RETURN output” script was made a standard output type, allowing users to append data to “unspendable transaction outputs.” The data size limit in such scripts was initially 40 bytes, later increased to 80 bytes.

Storing data on the blockchain

Changing OP_RETURN to always return false led to interesting results. Since no Operation Codes or data are evaluated after OP_RETURN, network users began using this Operation Code to store data in any format.

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

On BSV, the 220-byte limit was retained for a short period. Then, in January 2019, since OP_RETURN terminates the script without nodes verifying subsequent Operation Codes, nodes also do not check if the script is within the 520-byte maximum script size limit. As a result, node operators decided to increase the maximum transaction size to 100 KB, giving developers more freedom for application innovation and allowing new applications to store larger, more complex data in the Bitcoin ledger. There was even an example of someone storing an entire website on the BSV ledger.

Although OP_RETURN has some extended functionality, its overall capability is still limited. Improvements on OP_RETURN did not lead to more architectural technical evolution (still limited to the 1 MB Block), which led to the development of Segregated Witness technology. Its three version upgrades better illustrate Segregated Witness’s correctness and powerful effects in scaling and capability expansion.

# 1.3 Comparison Diagram of Early Transactions and Three Segregated Witness Versions

To help everyone better understand the full history of Segregated Witness in Bitcoin, we present a comparative diagram of the four stages at the beginning of the article.

![] ( https://img-cdn.gateio.im/social/moments-c 2d61a4507ac2e8aa7c743d6e938650e)

2 First Version of Segregated Witness: SegWit

# 2.1 Introduction and Related Protocols

Segregated Witness, or SegWit, was first proposed by Pieter Wuile (Bitcoin Core developer and Blockstream co-founder) in December 2015, later forming Bitcoin BIP 141. Segregated Witness mainly solves three problems (see below); the first two increase security and performance, while the third, which has the greatest impact on new technology, indirectly increases Block capacity (see the concept of Block weight below), laying the foundation for Bitcoin’s scaling and enabling further enhancements in Taproot (the second version of Segregated Witness).

Related protocols:

BIP-141: Segregated Witness ( Consensus layer ) / 2015-12-21

BIP-143: Transaction Signature Verification for Version 0 Witness Program / 2016-01-03

BIP-144: Segregated Witness ( Peer Services ) / 2016-01-08

# 2.2 Origin and Function

Segregated Witness mainly solves the following problems:

1. Transaction malleability issue.

2. In SPV proofs, transmitting transaction Signatures becomes optional, reducing the data required for Merkle proof transmission.

3. Indirectly increases Block capacity.

The first two mainly improve security and performance, while the third, which indirectly increases Block capacity, lays the foundation for Bitcoin’s scaling and enables further enhancements in Taproot (the second version of Segregated Witness).

Although Block capacity is indirectly increased, Segregated Witness is still subject to Block size limits. Bitcoin’s Block size limit is 1 MB, and since witness data is not included in this limit, to prevent abuse, there is still a total Block size restriction. 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 Block size of serialized transactions (in bytes) as described in BIP 144, including base data and witness data.

Segregated Witness limits Block weight to <= 4 MB.

Segregated Witness also technically enables Bitcoin scaling via the Lightning Network, which is not detailed here.

# 2.3 Detailed Technical Analysis

Bitcoin Segregated Witness (SegWit) technology led to three major changes:

• Transaction structure changes;
• Increased Block size;
• A new Bitcoin Address format.

(1) Transaction structure is shown below:

![] ( https://img-cdn.gateio.im/social/moments- 656dc57a1fc9d42b81e3e9f2381e397f)

Comparing the above diagram with the original Bitcoin transaction diagram, the Witness section is added, which contains the unlocking code. The Witness data is stored in an extended data area outside the 1 MB Block.

A more detailed SegWit transaction data diagram:

![] ( https://img-cdn.gateio.im/social/moments- 1411673aa66cdf278e69966820f6d862)

Detailed SegWit transaction diagram

(2) Transaction size introduction

![] ( https://img-cdn.gateio.im/social/moments- 17aada02e03d03cf6029fe22336f410c) Block size increase

![] ( https://img-cdn.gateio.im/social/moments- 30d5482c73883e5a2e13b4fb03ed4c5a)

Through the changes in signed transaction structure and the content of BIP-141, we see that Bitcoin’s Block can actually be expanded up to 4 MB, with the original 1 MB as the basic transaction data area and an additional 3 MB for Witness data.

(3) Segregated Witness Address format

Bitcoin Segregated Witness (SegWit) uses two new locking scripts, P2WPKH and P2WSH, resulting in a new Bech32-based Address encoding.

Bech32 Address encoding format is defined as follows:

![] ( https://img-cdn.gateio.im/social/moments- 3ec5d37f2e39d77658c7b9512ba50803)

The formats for locking scripts P2WPKH and P2WSH are explained below, with Taproot (the second version of Segregated Witness) Address samples included.

![] ( https://img-cdn.gateio.im/social/moments-c 354bfe70bd53cd2ab07357bbc01d9b5)

Locking script

P2WPKH

![] ( https://img-cdn.gateio.im/social/moments-d 65edd35659bfd5a1ea10211c40c0474)

Here, the 20-byte Public Key hash is actually the original Bitcoin Address form in the Algorithm.

P2WSH

![] ( https://img-cdn.gateio.im/social/moments- 621e4c57b92388a80e0db1c804f739b5)

wTXID Commitment

![] ( https://img-cdn.gateio.im/social/moments-c 9954be7248a41edd627bae7d2f27cb4)

All transaction IDs (wTXID) in the witness area are combined via a Merkle Tree to form a root hash submitted to coinbase, as shown in the diagram.

Single witness transaction ID (wTXID) formation principle diagram

wTXID

![] ( https://img-cdn.gateio.im/social/moments-ae 0cb158016248243aed51bc02c6e4eb)

# 2.4 Development and Summary

Segregated Witness technology was proposed in December 2015 and officially activated in 2017 at Block height 481824.

Block explorer link:

Detailed study and breakdown:

Segregated Witness technology is a major milestone in Bitcoin’s history, ushering in a golden era of scaling and capability expansion. From the perspective of scaling and capability expansion, Segregated Witness mainly accomplished scaling. Following this logic, the next version’s development would focus on capability expansion.

![] ( https://img-cdn.gateio.im/social/moments- 3667342ba93c72df5621d9abb4bd9868)

3 Second Version of Segregated Witness: Taproot

From the perspective of scaling and capability expansion, we can predict the functionality of the second version of Segregated Witness.

# 3.1 Introduction and Related Protocols

If you just use the word Taproot, many people think it’s a new concept, but if you say it’s the second version of Segregated Witness (SegWit), most will understand the connection. The related BIPs are 340, 341, and 342: BIP 340 (Schnorr Signatures for secp256k1), BIP 341 (Taproot: SegWit version 1 spending rules), BIP 342 (Validation of Taproot Scripts).

Related protocols:

BIP-341: Taproot: SegWit version 1 spending rules / 2020-1-9

BIP-342: Validation of Taproot Scripts / 2020-1-19

BIP-340: Schnorr Signatures for secp256k1 / 2020-1-19

In November 2021, Taproot was officially activated as a soft fork. This upgrade combined BIP 340, BIP 341, and BIP 342. BIP 340 introduced Schnorr Signatures, which can verify multiple transactions simultaneously, replacing the Elliptic Curve Digital Signature Algorithm (ECDSA), further increasing network capacity and speeding up batch transaction processing, making complex smart contracts possible; BIP 341 implemented Merkleized Abstract Syntax Tree (MAST) to optimize transaction data storage on the blockchain; BIP 342 (Tapscript) expanded Bitcoin’s native script capabilities using Bitcoin’s script encoding language.

The space expansion from Segregated Witness (SegWit) and Taproot led to the emergence of Schnorr, MAST, and Taproot Scripts, whose mission is to expand the functionality of the Bitcoin Mainnet.

# 3.2 Origin and Function

With Segregated Witness (SegWit) technology, Bitcoin’s Block capacity was increased. However, SegWit still left some issues:

(1) The underlying cryptographic Algorithm in SegWit still used ECDSA. (New developments require better asymmetric cryptography to support richer features, so Schnorr Signatures were adopted.)

(2) Space was increased, but unlocking scripts were still simple one-to-one structures. (Hence, MAST trees with complex conditional structures emerged.)

(3) SegWit did not enhance Bitcoin script functionality. (Thus, Tapscript was introduced.)

The second version of Segregated Witness, Taproot, effectively solved these issues, enabling further development and more features. BIP 340 solved (1); BIP 341 implemented Merkleized Abstract Syntax Tree (MAST) to solve (2); BIP 342 (Tapscript) expanded Bitcoin’s native script capabilities to solve (3).

# 3.3 Detailed Technical Analysis

Key new features of Taproot technology:

• Introduction of Schnorr Signatures
• Two types of P2TR locking scripts: Key Path Spend (similar to P2WPKH); Script Path Spend (similar to P2WSH)
• Script tree (MAST Merkle Abstract Syntax Tree)
• Taproot Script

1. Schnorr Signatures

Taproot’s development, while expanding capabilities, required improvements in Signature Algorithms, leading to the adoption of Schnorr Signatures to replace ECDSA. Schnorr Signature is a digital Signature scheme for efficiently and securely signing transactions and messages. It was first described by Claus Schnorr in a 1991 paper. Schnorr is praised for its simplicity, provable security, and linearity.

Advantages of Schnorr Signatures:

Schnorr Signatures offer multiple advantages, including efficiency, enhanced privacy, and retaining all ECDSA functionality and security assumptions. Schnorr Signatures enable smaller Signature sizes, faster verification, and improved resistance to certain attacks.

The most notable advantage is key aggregation, which allows multiple Signatures to be aggregated into one Signature valid for the sum of their keys. In other words, Schnorr enables multiple parties to generate a Signature valid for the sum of their Public Keys. Signature aggregation allows multiple signers’ Signatures to be merged into a single Signature. Key aggregation reduces transaction fees and improves scalability, as Signatures from multisig setups occupy the same space in a Block as single-party transactions. This feature can be used to reduce the size of multisig payments and other multisig-related transactions, such as Lightning Network channel transactions.

Another important feature of Schnorr Signatures is non-malleability.

Schnorr also provides many privacy advantages. It allows multisig schemes to be indistinguishable from traditional single Public Key transactions, making it harder for observers to distinguish multisig spending from single Signature spending on-chain. In n-of-m multisig setups, Schnorr makes it harder for external observers to determine which participants signed the transaction 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 digital Signatures faster, more secure, and easier to process. Notably, Schnorr Signatures are backward compatible with BTC’s cryptographic Algorithm, allowing them to be introduced via soft fork upgrade.

2. Basic principle diagram and Key Path Spend, Script Path Spend

![] ( https://img-cdn.gateio.im/social/moments- 0eaaa87a0cb8da7ebdc33600d49f61f8)

3. MAST Merkle Abstract Syntax Tree

Understanding Key Path Spend and Script Path Spend above, the most important thing is that these scripts can be organized into a tree structure.

This tree integrates the AST (Abstract Syntax Tree) and Merkle Tree. As shown below:

AST tree

![] ( https://img-cdn.gateio.im/social/moments- 093eed4d3754b7bf9029abc37af0569c) ![] ( https://img-cdn.gateio.im/social/moments- 5d3c25d5c0b9621a12c71d0ce66541ed)

Building the semantic tree above into a Merkle Tree:

![] ( https://img-cdn.gateio.im/social/moments-c 03ec3788c9a3ee1d7e207ac9a937460)

4. Taproot Scripts

In BIP 342, Tapscript is introduced. Taprootscript is an upgraded version of the original Bitcoin script, and can be considered a language, but it is actually a set of Operation Codes with commands that support the implementation of 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 Ordinals, as the Ordinals protocol uses Taproot’s script-path spend scripts to implement additional data.) For more details, refer to the official website:

Currently, TaprootScript’s capabilities have not been fully utilized, and future development will reveal its power. For example, connection technology between Bitcoin Layer 1 and Layer 2 networks should make more use of Taproot, MAST, and TaprootScripts.

Note: Actually, on Taproot Layer 1, TaprootScript’s capabilities are still somewhat limited, as it requires support from Bitcoin’s Virtual Machine. In the third version of Segregated Witness, the TaprootAssets protocol has a dedicated Virtual Machine (TAP-VM) for TaprootScript, making capability expansion more powerful and better isolated from the Bitcoin Mainnet runtime environment.

# 3.4 Development and Summary

Taproot technology was proposed in January 2020 and officially activated in November 2021 as a soft fork. With Taproot technology in the Bitcoin ecosystem, new applications began to emerge, starting with lightweight, simple applications.

Typical applications include:

(1) Ordinals protocol, inscriptions, BRC20

(2) Other protocols – Atomicals, ARC20

(3) Other protocols – Rune

SegWit and Taproot completed the first exploration of scaling and capability expansion, but both are limited by the existing structure.

Bitcoin’s first scaling expanded the Block from 1 MB to 4 MB. If this approach continues, even with technical support, wouldn’t it make the Block extremely large like other Bitcoin fork chains? This would lead to centralization and serious security issues for the blockchain. Therefore, the next step in scaling requires a different technical principle.

Although Taproot completed Bitcoin’s first capability expansion, this expansion also has limitations. On the Bitcoin Mainnet, the Virtual Machine executing BTCScript and TapScript is the same (Bitcoin’s stack computation). This limits capability expansion and affects the stability and security of the Bitcoin Mainnet. If new capability expansion is isolated from the Bitcoin Mainnet’s Virtual Machine, forming an independent Virtual Machine that works with the Mainnet’s Virtual Machine in a layered protocol, it would be a more reasonable development path. This isolated Virtual Machine could even evolve from non-Turing-complete to Turing-complete.

![] ( https://img-cdn.gateio.im/social/moments- 21f0bc002d952b8cd84e2dc4dd8af0b3)

4 Third Version of Segregated Witness: TaprootAssets Protocol

With the first round of scaling and capability expansion technologies on the Bitcoin Mainnet, a solid technical reference and implementation philosophy was established for future scaling and capability expansion. The next development of Bitcoin should mainly address further scaling. Of course, solving both scaling and capability expansion together would be ideal, but supporting two major changes simultaneously is very risky and makes engineering implementation extremely difficult. Thus, another round of scaling technology for the Bitcoin Mainnet emerged (along with some minor capability expansion technologies).

# 4.1 Origin and Function

With the development of Taproot, the Bitcoin ecosystem gained more possibilities, reflected in several aspects:

(1) Is it possible to store witness data outside the Bitcoin Block, achieving further Segregated Witness, i.e., storing witness data outside the Bitcoin Block and only storing proofs on the Bitcoin Mainnet?

(2) Can witness data have richer structures to meet more business needs?

(3) Further expand TaprootScript’s capabilities using a separate Virtual Machine for related computation.

If these goals can be achieved while fully preserving Bitcoin Mainnet characteristics, extremely rich functionality can be realized.

Does the second version of Segregated Witness, Taproot, fully satisfy Bitcoin’s technical development? Is there room for further upgrades and expansion?

# 4.2 Introduction and Related Protocols

Lightning Network Labs developed the Taproot Assets protocol in late 2021 for the reasons and background above. Taproot Assets protocol (formerly “Taro”) is more powerful than Taproot, with a very sophisticated design. (Special thanks to the protocol designer, Lightning Network Labs CTO, Olaoluwa Osuntokun.)

Taproot Assets protocol consists of seven important BIPs (not yet assigned BIP numbers):

BIP-TAP-ADDR: Taproot Asset On Chain Addresses Draft / 2021-12-10

BIP-TAP-MS-SMT: Merkle Sum Sparse Merkle Trees Draft / 2021-12-10

BIP-TAP-PROOF: Taproot Asset Flat File Proof Format Draft / 2021-12-10

BIP-TAP-PSBT: Taproot Assets PSBT Draft / 2023-02-24

BIP-TAP-UNIVERSE: Taproot Asset Universes Draft / 2021-12-10

BIP-TAP-VM: Taproot Asset Script v1 Draft / 2021-12-10

BIP-TAP: TAP: Taproot Assets Protocol Draft / 2021-12-10

TaprootAssets protocol pushes Bitcoin’s scaling and capability expansion to the extreme. Space, thanks to Universe, is theoretically unlimited; capability is limited by TaprootScript’s script capabilities and its Virtual Machine features (currently TAP-VM is not Turing-complete).

# 4.3 Detailed Technical Analysis

Key new features of Taproot Assets protocol:

• Data is stored entirely outside the Bitcoin Mainnet, with off-chain data proofs stored on the Bitcoin Mainnet Block;
• Off-chain data has a more complete structure, with a very sophisticated design for better extensibility;
• Off-chain data is supported by a powerful Virtual Machine (VM) that is beginning to separate from the Bitcoin Mainnet’s Virtual Machine, enabling more functionality beyond the Mainnet.

1. Off-chain data storage and on-chain proof

Taproot Assets protocol uses Universe to store off-chain data, which has significant advantages: it can provide public data to visitors or keep data private for enhanced privacy.

Currently, Taproot Assets protocol uses Merkle Sum Sparse Merkle Trees (MS-SMT) to address asset-related needs.

![] ( https://img-cdn.gateio.im/social/moments- 20cff3175ce1c38197a830762864d3f3)

This diagram shows the issuance of multiple assets using MS-SMT

![] ( https://img-cdn.gateio.im/social/moments-fcf 5b332c34dc2596fa22f833002dc42)

This diagram shows TaprootAssets asset transfer and holding.

2. Complete data structure – MS-SMT (Merkle Sum Sparse Merkle Tree)

Taproot Assets protocol uses the same UTXO model as the Bitcoin Mainnet for asset issuance, called vUTXO. Control of vUTXO total amount, splitting, merging, and transfer operations use MS-SMT. The sum ensures total amount remains unchanged, and the sparse Merkle Tree records all vUTXO states.

( From Virtual Byte in SegWit to Virtual UTXO in TA, what a similar evolutionary path! )

“Merkle Sum Sparse Merkle Tree” (MS-SMT) is a variant of the Merkle Tree defined by bip-tap-ms-smt. With 256-bit keys, it has 2^256 leaves, most of which are empty.

Each leaf contains an amount, and each branch node commits to the sum of amounts in its subtree’s leaves. Even if a subtree’s content is unknown, checking the branch node reveals the total amount in the subtree. The root commits to the total amount in all leaves.

Like a general Merkle Tree, a pruned tree containing the target leaf can provide Merkle proof of the leaf’s existence. MS-SMT also supports “non-inclusion proof” by requiring leaves representing non-existent keys to have an explicit “None” value, so proving “None” constitutes a non-inclusion proof. Thus, a default MS-SMT has 2^256 leaves representing “None.”

Asset leaf (asset UTXO)

The lower-level MS-SMT of the asset tree uses asset_script_key as the key and asset leaf as the value. Each asset leaf represents a UTXO (not a Bitcoin UTXO for simplicity), and the following attributes (including optional ones) are serialized in “type-length-value” format.

taproot_asset_version

asset_genesis

asset_id

asset_type

amt

lock_time

relative_lock_time

prev_asset_witnesses

• prev_asset_id

• asset_witness

• split_commitment_proof

split_commitment

asset_script_version

asset_script_key

asset_group_key

canonical_universe

asset_genesis is the preimage for deriving asset_id.

asset_script_key is both the key for the asset leaf and a Taproot-style Public Key (defined independently in tap-vm), and is the condition for spending the UTXO represented by the asset leaf.

To spend a UTXO, you must first satisfy the (external) Bitcoin spending condition, then the (internal) TAP spending condition specified by asset_script_key, which should be satisfied by prev_asset_id and asset_witness. For example, asset_witness is the Signature of the asset_script_key of the UTXO being spent.

![] ( https://img-cdn.gateio.im/social/moments- 4bbc1d2e0de7f871ff1aa4440933bc0d)

If a UTXO is split during asset transfer, split_commitment and split_commitment_proof are also needed. split_commitment is an MS-SMT representing all UTXOs after the split (so the asset tree actually has three layers), and the sum in the root is the total amount transferred.

split_commitment_proof is a Merkle proof for split_commitment, proving the existence of a split.

In all splits, only one has prev_asset_id, asset_witness, and split_commitment. All other splits only have split_commitment_proof. All splits share prev_asset_id and asset_witness.

3. Taproot Assets protocol Virtual Machine TAP-VM

In BIP-TAP-VM: Taproot Asset Script v1, a dedicated Virtual Machine for this protocol is defined. Initially, it is mainly based on minor adjustments to BIP-341 and BIP-342 (the two main Taproot BIPs), with slight extensions to BTCScript and TaprootScript.

The author believes that with this design, the TAP-VM execution environment is already separated from the Bitcoin Mainnet, and a more powerful Virtual Machine can be developed via Lightning Network Labs’ tapd application. For security and stability, this process is slow, which fits the characteristics of Bitcoin ecosystem applications.

TrustlessSwap is an important initial feature of the TaprootAssets protocol, and it already enables the development of relatively complex native Bitcoin applications.

![] ( https://img-cdn.gateio.im/social/moments- 55dabd37240b415487a51a4f01121de5)

In our project team’s development, we have already experienced some powerful features. For example, TrustlessSwap can already enable complex functional designs for Bitcoin and assets issued on it.

For a long time to come, after initial asset issuance stabilizes and matures, the focus of TaprootAssets protocol will be on TAP-VM functionality development.

Side note: I have a question. If development continues, can TAP-VM become a Turing-complete Virtual Machine? I believe that with enough time, it can eventually be achieved. Then comes a second question: in the long run, does the TaprootAssets protocol need a Turing-complete Virtual Machine?

# 4.4 Development and Summary

From the initial protocol files in late 2021 to the Taro version release in 2023, Taproot Assets protocol completed its initial exploration phase. However, the Taro version had many design flaws, resulting in poor support for upper-layer applications and a period of stagnation. With the release of tapd 0.3.0 in 2024, Taproot Assets protocol saw good exploratory development, and by June 2025, with tapd 0.6.0, the protocol entered a stable, Available state. This laid a solid foundation for developing richer applications based on Taproot Assets protocol.

Compared to protocols like Ordinals, inscriptions, BRC20, ARC, etc., which emerged after Taproot, applications built on TaprootAssets protocol will be richer, more stable, and more usable than those from the second version of Segregated Witness.

Applications such as TA asset issuance, TA new asset wallets, TrustlessSwap, Stablecoin, and more complex BTCFi applications have become possible and will gradually be realized.

The initial stage of TaprootAssets protocol mainly accomplished Bitcoin scaling, theoretically expanding Bitcoin’s usable space to infinity via Universe. TAP’s VM (Taproot Asset Script v1) also has an initial model, and importantly, an isolated, independently developing VM has emerged. In the foreseeable future, Bitcoin will continue to develop in the direction of capability expansion.

![] ( https://img-cdn.gateio.im/social/moments-f 38320008c754b15ef64b53a16a738e0)

5. Summary

Through three major upgrades of Segregated Witness technology in Bitcoin’s development history, the Bitcoin Mainnet has achieved tremendous improvements in scaling and capability expansion. In terms of scaling, Universe theoretically enables infinite space, and if combined with the Lightning Network, transaction TPS could be expanded infinitely; in terms of capability expansion, if TAP-VM becomes Turing-complete, capability expansion will reach its peak. These infrastructure developments will take a long time to mature.

The three major Segregated Witness upgrades have formed a strong protocol and technical foundation for the development of the Bitcoin ecosystem. From SegWit to Taproot to TaprootAsset protocol, most of the infrastructure needed for applications has been completed. I believe TaprootAssets will usher in an important product ecosystem boom.

Note: The script language after the three Segregated Witness upgrades is still non-Turing-complete.

These three Segregated Witness version upgrades have fundamentally changed Bitcoin’s structure. What stage will it develop to in the future? TaprootAsset protocol looks a bit like Layer 2 technology, but it doesn’t fully meet Layer 2 standards. Its characteristics and mechanisms are very similar to Bitcoin Layer 1, but it’s not a direct Layer 1 development. The author believes Bitcoin will develop into the BTC 2.0 stage and hopes to exchange ideas with more experts in the future. If the ideas can be clarified, I’ll describe the possible development and theoretical basis of BTC 2.0 at a later time.

If it’s BTC 2.0, wouldn’t it be better to name the seven TaprootAsset protocol BIPs with BIP 2 as the prefix? Should the review standards and design principles for BTC 1.0 and 2.0 protocols be more clearly planned? And can development resources be better divided and cooperated? In addition to maintaining the BTC 1.0 Bitcoin Mainnet, can the original BitcoinCore team join the development of BTC 2.0 and continue to contribute? Wouldn’t BTC 2.0 be built faster and better this way?……

Special thanks to YY from Lightning Network for much feedback and guidance on this article.

References