0x0 Preface

On December 6, 2023, while Bitcoin investors were celebrating the surge brought by Inscriptions, Luke Dashjr, the developer of the Bitcoin Core node client, poured cold water on the excitement. He considered Inscriptions as a "spam" attack and submitted a fix code and CVE vulnerability report (CVE-2023-50428). Subsequently, the Bitcoin community erupted in debate, reminiscent of the chaos caused by the hard fork in 2017. So, should Bitcoin prioritize security and sacrifice some unexpected features, or should it embrace unexpected innovations and tolerate potential security issues to some extent?

We know that the journey of Bitcoin is not just speculation and trading; it is also a process of continuous evolution in its ecosystem and security framework. This article aims to delve into the dual narrative of Bitcoin's growth: the expanding utility within its ecosystem and the strengthening of security measures. We will explore the synergy between innovation and robust security protocols and how they pave the way for the new era of digital assets.

0x1 Overview of BTC Ecological System and Basic Knowledge

As the cornerstone of the cryptocurrency revolution, Bitcoin has always been regarded as a store of value similar to gold. While other public chain DeFi innovations are flourishing, it seems that people have forgotten about the existence of Bitcoin.

However, it was on Bitcoin that pioneers first experimented with stablecoins, Layer2, and even DEFI. For example, the popular stablecoin USDT was initially issued on the Bitcoin Omnilayer network. The following diagram provides a basic classification of the Bitcoin ecosystem from a technical implementation perspective. This includes technologies such as sidechains based on two-way anchoring, text parsing based on output script (OP_RETURN), engraving based on Taproot scripts, driven chains based on BIP300 updates, and state channel-based Lightning Network.

Many of these terms may still be unfamiliar, but don't worry. Let's first familiarize ourselves with the fundamental knowledge and then explain the technical principles of these ecosystems one by one, discussing the associated security issues.

UTXO: The Basic Unit of Bitcoin Transactions

Different with Ethereum's account balance system, Bitcoin does not employ the concept of accounts. Ethereum introduced four complex Merkle Patricia Tries to store and verify changes in account states. In contrast, Bitcoin ingeniously utilizes UTXO to address these issues in a more concise manner. Four Trees of Ethereum Inputs and Outputs of Bitcoin UTXO (Unspent Transaction Outputs) may sound convoluted, but it becomes easily understandable once you grasp the concepts of inputs, outputs, and transactions.

Inputs and Outputs of Transactions

Those familiar with Ethereum should know that transactions are the fundamental communication units within blockchain networks. Once a transaction is packaged, mined, and confirmed, it signifies the determination of state changes on the chain. In Bitcoin transactions, it is not a simple operation of states between addresses; rather, they consist of multiple input and output scripts. The above diagram illustrates a typical Bitcoin 2 to 2 transaction. In theory, the amount of BTC in the inputs should be equal to the amount in the outputs. However, the portion of BTC that is less in outputs compared to inputs serves as the miner's transaction fee, earned by the block miner. This is equivalent to the Gas Fee in Ethereum.

When transferring BTC from two input addresses, validation needs to be performed in the input script to prove that these two input addresses can spend the respective inputs (i.e., the unspent outputs, UTXO) from the previous transaction. The output script defines the conditions for spending the two output bitcoins, i.e., the conditions that must be met when using this unspent output as an input in the next transaction (typically, for a regular transfer, the condition is the signature of the output address). In the above diagram, P2wPKH represents the signature verification of a Taproot address, while P2PKH represents the signature of a legacy address. Specifically, the data structure of a Bitcoin transaction is as follows:

In Bitcoin transactions, the basic structure consists of two key components: inputs and outputs. The input part specifies the sender of the transaction, while the output part indicates the recipient of the transaction and any change (if applicable). The transaction fee is the difference between the total input amount and the total output amount. Since the input of each transaction is the output of a previous transaction, the outputs of transactions become the core elements of the transaction structure.

This structure forms a chain-like connection. In the Bitcoin network, every valid transaction can be traced back to one or more previous transaction outputs. The starting point of these transaction chains is the mining reward, and the endpoint is the currently unspent transaction outputs. All unspent outputs in the network are collectively referred to as Unspent Transaction Outputs (UTXOs) in the Bitcoin network.

In the Bitcoin network, the inputs of each new transaction must be unspent outputs. Additionally, each input requires the corresponding private key signature of the previous output. Every node in the Bitcoin network stores all the UTXOs on the current blockchain to verify the validity of new transactions. Through the UTXO and signature verification mechanism, nodes can verify the validity of new transactions without tracing the entire transaction history, thereby simplifying the operation and maintenance process of the network.

Bitcoin's unique transaction structure aligns with its whitepaper, "Bitcoin: A Peer-to-Peer Electronic Cash System." Bitcoin is an electronic cash system, and its transaction structure simulates the process of cash transactions. The amount that can be spent on an address depends on the previously received cash amount. Each transaction aims to spend all the cash on that address as a whole, and the output addresses of a transaction usually consist of a recipient address and a change address, similar to receiving change in cash transactions at a supermarket.

Script

In the Bitcoin network, scripts play a crucial role. In fact, each output of a Bitcoin transaction refers to a script instead of a specific address. These scripts act like a set of rules that define how the recipient can spend the assets locked in the output.

The validity of a transaction relies on two types of scripts: the locking script and the unlocking script. The locking script exists in the output of a transaction and defines the conditions required to unlock that output. The corresponding unlocking script, which is located in the input part of the transaction, must follow the rules defined by the locking script to unlock the UTXO (Unspent Transaction Output) assets. The flexibility of this scripting language allows Bitcoin to implement various combinations of conditions, showcasing its characteristics as a "partially programmable currency."

In the Bitcoin network, each node runs a stack-based interpreter to interpret these scripts based on "first-in, first-out" rules.

The most classic Bitcoin scripts mainly consist of two commonly used types: P2PKH (Pay-to-Public-Key-Hash) and P2SH (Pay-to-Script-Hash). P2PKH is a simple transaction type where the recipient only needs to sign with the corresponding private key to spend the assets. P2SH, on the other hand, is more complex. For example, in the case of multisignature, it requires a combination of multiple private key signatures to spend the assets.

These scripts and verification mechanisms together constitute the core operation of the Bitcoin network, ensuring the security and flexibility of transactions.

For example, in Bitcoin, the output script rules for P2PKH are as follows:

Pubkey script: OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG

The input requires a signature:

Signature script: sig

For P2SH, the output script rules are as follows:

Pubkey script: OP_HASH160  OP_EQUAL

The input requires a multisig list:

Signature script:  [sig] [sig...]

In the above two script rules, the pubkey script represents the locking script, and the signature script represents the unlocking script. The words starting with OP_ are script commands and instructions that nodes can interpret. These command rules are categorized based on the different pubkey scripts and also determine the rules for the unlocking script.

Bitcoin's scripting mechanism is relatively simple. It is an engine based on a stack-based model that interprets related OP commands. The supported script rules are not too extensive, and it cannot implement complex logic. However, it provides a prototype for blockchain programmability. Some subsequent ecosystem projects have developed based on the principles of scripting. With the updates of Segregated Witness (SegWit) and Taproot, the types of OP commands have become more diverse, and the script size that can be included in each transaction has been increased, leading to an explosive growth in the Bitcoin ecosystem.

0x2 Mnemonic Technology: Principles and Security Issues

The popularity of mnemonic technology is closely related to Bitcoin's Segregated Witness (SegWit) and Taproot updates.

From a technical perspective, the higher the decentralization level of a blockchain, the lower its efficiency usually is. Taking Bitcoin as an example, the size of each block is still maintained at 1MB, the same as the size of the first block mined by Satoshi Nakamoto. Faced with the scalability issue, the Bitcoin community did not choose the straightforward path of increasing the block size. Instead, they adopted a method called Segregated Witness (SegWit), which is an upgrade solution that does not require a hard fork. Its aim is to improve the network's processing capacity and efficiency by optimizing the data structure within the blocks.

Segregated Witness (SegWit):

In Bitcoin transactions, the information is primarily divided into two parts: basic transaction data and witness data. The basic transaction data includes crucial financial information such as account balance, while the witness data is used for verifying the users' identities. For users, they are mainly concerned with the information directly related to their assets, such as the account balance, and the details of identity verification do not need to occupy too many resources in the transaction. In other words, the receiving party is primarily interested in the availability of the assets and does not need to excessively focus on the detailed information of the sender.

However, in the transaction structure of Bitcoin, the witness data (i.e., signature information) occupies a significant amount of storage space, which leads to reduced transfer efficiency and increased transaction packaging costs. To address this issue, Segregated Witness (SegWit) technology was introduced. Its core idea is to separate the witness data from the main transaction data and store it separately. The result of this approach is an optimization of storage space utilization, thereby improving transaction efficiency and reducing costs. In this way, without changing the original 1MB block size, each block can accommodate more transactions, while segregated witness data (which includes various signature scripts) can occupy an additional 3MB of space, laying the storage foundation for the enrichment of Taproot script instructions.

Taproot

Taproot is a significant soft fork upgrade to the Bitcoin network aimed at improving the privacy, efficiency, and processing capabilities of Bitcoin scripts and smart contracts. This upgrade is considered a major advancement since the Segregated Witness (SegWit) upgrade in 2017.

The Taproot upgrade consists of three different Bitcoin Improvement Proposals (BIPs): Taproot (Merkle Abstract Syntax Tree, MAST), Tapscript, and a new multisignature-friendly digital signature scheme called "Schnorr signatures." Taproot aims to provide several benefits to Bitcoin users, including enhanced transaction privacy and reduced transaction costs. Additionally, it will enhance Bitcoin's ability to execute more complex transactions, thereby expanding its range of applications.

The Taproot update directly affects three ecosystems: one is the Ordinals protocol, which utilizes Taproot's script-path spend scripts to enable additional data; another is the Lightning Network, which upgrades to Taproot Asset, evolving from simple peer-to-peer BTC payments to multiparty payments and support for issuing new assets; and finally, the newly proposed BitVM, which incorporates boolean circuits into Taproot scripts using op_booland and op_not, thereby enabling smart contract virtual machine functionality.

Taproot's advancements bring significant improvements to the Bitcoin network, enhancing privacy, scalability, and the capabilities of executing complex transactions and smart contracts.

Ordinals

Ordinals is a protocol invented by Casey Rodarmor in December 2022. It assigns a unique sequential number to each Satoshi and tracks them in transactions. Using Ordinals, anyone can attach additional data to the Taproot script of a UTXO, including text, images, videos, etc.

Those familiar with Ordinals certainly know that the total supply of Bitcoin is 21 million, and each bitcoin consists of 10^8 Satoshis. Therefore, there are a total of 21 million * 10^8 Satoshis on the Bitcoin network. The Ordinals protocol aims to differentiate these Satoshis, assigning a unique number to each of them. While this is theoretically possible, it is not practical to achieve in reality. Due to the need to resist dust attacks, the Bitcoin network imposes a minimum limit of 546 Satoshis (or 294 Satoshis for SegWit) for transactions. This means that it is not possible to transact with individual Satoshis. Depending on the address type, a minimum of 546 or 294 Satoshis must be transferred. According to the Ordinals "first in, first out" numbering theory, at least the Satoshis numbered from 1 to 294 in each block are indivisible.

Therefore, the concept of "engraving" is not about engraving on a specific Satoshi, but rather engraving in the script of a transaction that involves at least a transfer of 294 Satoshis. Centralized indexers, such as Unisat, can then track and identify the movement of these 294 or 456 Satoshis.

Inscription Encoding Method in Transactions

In principle, the spending of a Taproot script can only occur from existing Taproot outputs. Therefore, in theory, the inscription should be carried out through a two-stage commit/reveal process. Firstly, in the commit transaction, a Taproot input is created based on the script path spend content, and the spending/reveal signature conditions are indicated in the output. Secondly, in the reveal transaction, the output created by the commit transaction is spent, revealing the on-chain inscription content.

However, in practical indexer scenarios, the focus is not on the role of the reveal transaction but rather on directly reading the script fragment consisting of OP_FALSE OP_IF ... OP_ENDIF in the input script to extract the inscription content.

Because the combination of OP_FALSE OP_IF instructions causes that script segment not to be executed, arbitrary bytes of content can be stored within it without affecting the original script's logic.

A text inscription containing the string "Hello, world!" would be serialized as follows:

OP_FALSE OP_IF OP_PUSH "ord"OP_1OP_PUSH "text/plain;charset=utf-8"OP_0OP_PUSH "Hello, world!"OP_ENDIF

https://explorer.btc.com/btc/transaction/885d037ed114012864c031ed5ed8bbf5f95b95e1ef6469a808e9c08c4808e3ae

We can view the detailed information of this transaction：

By analyzing the encoding of the witness field starting from 0063 (OP_FALSE OP_IF), we can understand the serialized encoding content： So, as long as we can decode the code in this part of the witness script, we can determine the engraved content. Here, the encoding represents plain text information, and other data such as HTML, images, videos, etc., follow similar principles.

In theory, you can also define your own encoding content, including encrypted content that only you know. However, these contents cannot be displayed in the Ordinals browser.

BRC20

On March 9, 2023, an anonymous Twitter user named "domo" tweeted about creating a standardized token called BRC20 on the Ordinals Protocol. The idea was to embed JSON string data in a Taproot script using the Ordinals protocol to deploy, mint, and transfer fungible BRC-20 tokens. Figure 1: The humble beginnings of BRC-20 tokens (the first post about domo) From：Twitter（@domodata）

Figure 2: Three possible initial operations for BRC-20 tokens (p = protocol, op = operation, tick = ticker code/identifier, max = maximum supply, lim = minting limit, amt = amount) From：https://domo-2.gitbook.io/brc-20-experiment/ Binance Research

The issuer of the token deploys the BRC-20 token onto the blockchain through deployment. Participants can then acquire tokens at almost no cost by using the "mint" operation (only paying the miner's fee). Once the minted quantity exceeds the maximum supply (max), the indexer considers the minted script to be invalid. Afterward, addresses holding the tokens can transfer them using the "transfer" operation.

It's worth noting that Casey, the founder of Ordinals, is highly displeased with the dominance of BRC-20 transactions on the Ordinals protocol. He openly expressed frustration with the amount of "garbage" that BRC-20 has brought to Ordinals. As a result, Casey's team publicly requested Binance Research to remove any mention of Ordinals in the introduction of the ORDI token. Casey wants to dissociate the Ordinals protocol from ORDI.

Extension Protocol

BRC20 swap

Currently, the largest market, indexer, and wallet provider, Unisat, has proposed the BRC20 swap protocol for BRC20 transactions. Early users are now allowed to try it out.

Previously, in script transactions, only a partially signed Bitcoin transaction (PSBT) method was available, similar to Opensea's off-chain signature scheme. It relied on centralized services to "match" the signatures of the buying and selling parties. This meant that BRC20 assets could only be traded through listing orders, resulting in low liquidity and trading efficiency, similar to NFT assets.

BRC20 swap introduces a mechanism called "modules" into the JSON string of the BRC20 protocol. Within this module, a script similar to a smart contract can be deployed. Taking the swap module as an example, users can lock BRC20 tokens into the module through a transfer, which initiates a transaction to themselves. The script of the transaction is then locked in the module. Users can complete the transaction or withdraw the LP by initiating another transaction to extract the BRC20 tokens.

Currently, BRC20 swap operates in an extension mode using black modules. Black modules ensure security by determining the funds a user can withdraw based on the sum of funds in the module. In other words, no user can withdraw more assets than the total assets locked in the module without consensus and verification. Once the behavior of black modules is understood and executed by users, and as they gradually gain reliability and acceptance from more indexers, the product transitions from black modules to white modules, achieving consensus upgrade. Users can then freely deposit and withdraw assets. In addition, because the BRC20 protocol and the entire Ordinals ecosystem are still in the early stages, Unisat has a significant influence and reputation, providing comprehensive indexing services for transactions and balance queries for the protocol, creating a centralized risk. The modular architecture allows more service providers to participate, thereby achieving a more decentralized indexing system.

BRC420

The BRC420 protocol, developed by RCSV, expands on the existing cipher by introducing recursive indexing. It defines more complex asset formats through recursion. Additionally, BRC420 establishes a relationship between ownership and royalties based on individual ciphers. When users mint assets, they are required to pay royalties to the creators. By owning a cipher, users can allocate usage rights and set prices, which encourages more innovation within the Ordinals ecosystem.

The introduction of BRC420 provides a broader imagination for the cipher ecosystem. It allows the construction of more intricate metaverses through recursive references and facilitates the development of smart contract ecosystems using code ciphers.

ARC20

The ARC20 token standard is provided by the Atomicals protocol. In this standard, "atomicals" are the basic units built on top of Bitcoin's smallest unit, the satoshi (sat). This means that each ARC20 token is always backed by 1 sat. Additionally, ARC20 is the first token protocol that utilizes proof-of-work (PoW) ciphers for minting, allowing participants to directly mine ciphers or NFTs similar to mining Bitcoin.

Equating 1 ARC20 token to 1 satoshi brings several benefits:

• Firstly, the value of each ARC20 token will never be lower than 1 satoshi, making Bitcoin serve as a "digital gold anchor" in this process.
• Secondly, validating transactions only requires querying the UTXO corresponding to the satoshi, contrasting the complexity of BRC20, which requires off-chain ledger state records and third-party sorters.
• Additionally, all operations of ARC20 can be completed through the Bitcoin network without additional steps.
• Lastly, due to the composability of UTXOs, it is theoretically possible to achieve direct exchange between ARC20 tokens and Bitcoin, providing possibilities for future liquidity.

The Atomicals protocol sets special prefix parameters for Bitwork Mining of ARC20 tokens. Token issuers can choose a specific prefix, and users must calculate a matching prefix through CPU mining to qualify for minting the corresponding ARC20 token. This "one CPU, one vote" model aligns with the ideals of Bitcoin purists.

Cipher Security

On the surface, ciphers appear to be harmless text stored on the blockchain and parsed by centralized indexers. However, there are still several considerations for on-chain security:

• Increased node burden: Ciphers increase the size of Bitcoin blocks, requiring additional resources for nodes to propagate, store, and validate blocks. If there are too many ciphers, it can reduce the decentralization of the Bitcoin network and make it more susceptible to attacks.
• Reduced security: Ciphers can store any type of data, including malicious code. If malicious code is added to a Bitcoin block, it can lead to network vulnerabilities.
• Construction of transactions: Cipher transactions need to be constructed correctly and adhere to the first-in, first-out rules of ordinals to prevent the indexability of ciphers from being compromised due to negligence.
• Risk in buying and selling: The market for cipher transactions, whether OTC or PSBT, carries the risk of asset loss.

Here are some specific security issues:

• Increased orphan rate and fork rate: Ciphers increase the size of blocks, leading to increased orphan rates and fork rates. Orphan blocks are blocks not recognized by other nodes, and forks refer to the existence of multiple competing blockchains in the network. Orphans and forks reduce the stability and security of the network.
• Tampering with ciphers: Attackers can exploit the openness of ciphers for tampering attacks. For example, attackers can replace the stored information in the cipher with malicious code, infiltrating indexer servers or compromising user devices through trojans.
• Improper wallet usage: Mishandling wallets, such as transferring ciphers without the wallet indexing them, can result in asset loss.
• Phishing or scams: Attackers may use fake indexer websites such as Unisat to deceive users into engaging in cipher transactions and steal their assets.
• PSBT signature omissions: Atomicals Market has experienced asset losses due to incorrect signature methods used in PSBT.

https://metatrust.io/blogs/post/the-analysis-of-the-atomicals-market-user-asset-loss

To address these security issues, the following measures can be taken:

• Limiting the size of ciphers: The size of ciphers can be restricted to reduce the burden on nodes, as mentioned earlier by Luke.
• Encrypting ciphers: Ciphers can be encrypted to prevent attacks from malicious code.
• Using trusted sources for ciphers: Trusted sources can be utilized to prevent signature issues and phishing attempts.
• Using wallets that support ciphers: Wallets that support ciphers should be used for transfer activities.
• Conducting thorough code and script audits for ciphers: In the case of experiments involving BRC20-swap and recursive ciphers, the introduction of code and related scripts requires ensuring their security.

From a technical and security perspective, Bitcoin ciphers are essentially a vulnerability that circumvents the rules. Taproot scripts were not designed for data storage, and their security has some issues. Luke's modifications to the Bitcoin Core code are correct from a security standpoint. Luke did not directly modify the consensus layer of Bitcoin but chose to adjust the Spam Filter module, allowing nodes to automatically filter out Ordinals transactions when receiving P2P broadcast messages. In this strategy filter, there are several functions named isStandard() that check various aspects of the transaction for compliance with the standards. If a transaction does not meet the standards, the received transaction will be quickly discarded by the node.

In other words, although Ordinals transactions can still be included in the blockchain, most nodes will not add such data to their transaction pools, which increases the delay in Ordinals data being accepted by mining pools willing to include them in blocks. However, if a mining pool broadcasts a block containing BRC20 transactions, other nodes will still recognize it.

Luke has introduced modifications to the policy filter in the Bitcoin Knots client and plans to introduce similar changes in the Bitcoin Core client. In this modification, he introduced a new parameter called g_script_size_policy_limit, which limits the script size in multiple different positions. This change means that the script size will be subject to additional restrictions when processing transactions, affecting how transactions are accepted and processed. Currently, the default value for this parameter is 1650 bytes. Any node client can set this value at startup using the -maxscriptsize parameter:

However, even with code updates, it will take a considerable amount of time for all mining nodes to fully update to the new version. During this time, innovators in the cipher community should be able to create more secure protocols. （The latest news said the issue has been closed after the discussion by Bitcoin core developers.）

Metatrust Labs has already conducted risk scoring and monitoring of cipher investments through on-chain data and asset tracking on the metaScore platform. Additionally, they have introduced a rule engine for monitoring the Bitcoin network on the metaScout platform, which can assist investors in monitoring real-time data related to Bitcoin ciphers.

In this issue, we explore the technical principles and potential security issues of the current popular cipher ecosystem.

In the next issue, we will bring you a more complex Taproot circuit carving technique called bitVM. Stay tuned for more information!