Where does the inscription go?

Preface

On December 6, 2023, when Bitcoin investors were cheering for the gains that Inscriptions had brought to Bitcoin, Luke Dashjr, the developer of the Bitcoin Core node client, poured cold water on it. He believed that the inscription was a "spam" attack and submitted a fix code and a CVE vulnerability report (CVE-2023-50428). Then the Bitcoin community exploded, and following the chaos of the hard fork in 2017, the Bitcoin community once again fell into fierce debate.

So should Bitcoin pay more attention to security and abandon some unexpected features, or should it be more tolerant of unexpected innovations and slightly tolerant of possible security issues?

We know that Bitcoin’s journey is not just speculation and hype, but also the continuous evolution of its ecosystem and security landscape. This article aims to delve into the twin narratives of Bitcoin’s growth: expanding utility within its ecosystem and strengthening security measures. We’ll explore how the synergy of innovation and strong security protocols can pave the way for a new era of digital assets.

BTC Ecosystem Overview and Basic Knowledge

We know that as the cornerstone of the cryptocurrency revolution, Bitcoin has always been used as a store of value like gold. When other public chain DEFI innovations are in full swing, people seem to have forgotten the existence of Bitcoin.

However, it was precisely on Bitcoin that the pioneers first started experiments with stablecoins, Layer2, and even DEFI. For example, USDT, the current hard currency in the crypto, was first issued on the Bitcoin Omnilayer network. The following figure shows from the perspective of technical implementation A basic classification of the Bitcoin ecosystem.

Including technologies such as side chains based on bidirectional anchoring, text parsing based on output scripts (OP_RETURN), engraving based on Taproot scripts, drive chains based on BIP300 updates and upgrades, and lightning networks based on state channels.

You may not understand many of the terms above, so don’t worry. Let’s get familiar with the following basic knowledge first, and then explain the technical principles of these ecosystems one by one and discuss the security issues involved.

UTXO is the basic unit of Bitcoin transactions

Unlike Ethereum's account balance system, there is no concept of an account in the Bitcoin system. Ethereum introduces four complex Merkle Patricia Tries to store and verify changes in account status. In contrast, Bitcoin cleverly uses UTXO to solve these problems more concisely.

Ethereum’s Four Trees

Bitcoin inputs and outputs

UTXO (Unspent Transaction Outputs, unspent transaction outputs), the name sounds very difficult to pronounce, but in fact, it is easy to understand after understanding the three concepts of input, output and transaction.

Transaction inputs and outputs

Friends who are familiar with Ethereum should know that a transaction is the basic communication unit in the blockchain network. Once the transaction is packaged and confirmed, it means that the state change on the chain is confirmed. In Bitcoin transactions, there is not a single address-to-address status operation, but multiple input scripts and output scripts.

The picture above is a very typical Bitcoin 2-to-2 transaction. Theoretically, the amount of BTC input and the amount of BTC output should be equal. In fact, the BTC output that is less than the input is earned by the block miners as miners' fees, which is equivalent to the Gas Fee in Ethereum.

We can see that when transferring BTC, the two input addresses need to be verified in the input script to prove that these two input addresses can spend these two inputs (that is, the unspent output of the previous one, UTXO), and The output script stipulates the conditions for spending two outputs of Bitcoin, that is, what conditions should be met the next time this unspent output is used as input (for ordinary transfers, the condition is the signature of the output address, such as the picture above, P2wPKH indicates that signature verification of the taproot address is required, and P2PKH indicates that the signature of the private key of the legacy address is required).

Specifically, the data structure of Bitcoin transactions is as follows:

In a Bitcoin transaction, the basic structure consists of two key parts: inputs and outputs. The input part specifies the initiator of the transaction, while the output part specifies the recipient of the transaction and the change (if any). 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 output of the transaction becomes the core element of the transaction structure.

This structure forms a chain connection. In the Bitcoin network, every legitimate transaction can be traced back to the output of one or more previous transactions. The starting point of these transaction chains is the mining reward, and the end point is the transaction output that has not yet been spent. All unspent outputs in the network are collectively called UTXO (Unspent Transaction Output) of the Bitcoin network.

In the Bitcoin network, the inputs of every new transaction must be unspent outputs. In addition, each input also requires the corresponding private key signature of the previous output. Each node in the Bitcoin network stores all UTXOs currently on the blockchain to verify the legitimacy of new transactions. Through UTXO and signature verification mechanisms, nodes are able to verify the legitimacy of new transactions without tracing the entire transaction history, thus simplifying the network operation and maintenance process.

Bitcoin's unique transaction structure is designed in line with its white paper "Bitcoin: A Peer-to-Peer Electronic Cash System". Bitcoin is an electronic cash system. Its transaction structure simulates the transaction process of cash. An address can be spent. The amount depends on the amount of cash received before. Each transaction requires all the cash on this address to be spent as a whole, and the output address of the transaction is usually a receiving address and a change address, just like in a supermarket. Change when transacting in cash.

script

In the Bitcoin network, scripts play a vital role. In fact, each output of a Bitcoin transaction actually points to a script rather than a specific address. These scripts are like a set of rules that define how the recipient can use the assets locked in the output.

The legality verification of transactions relies on two scripts: lock script and unlock script. A locking script exists within a transaction's output and defines the conditions required to unlock that output. Correspondingly, unlocking scripts must follow the rules defined by locking scripts to unlock UTXO assets. These scripts are located in the input part of the transaction. The flexibility of this scripting language allows Bitcoin to achieve a variety of condition combinations, demonstrating its characteristics as a "partially programmable currency."

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

There are two main common types of the most classic Bitcoin scripts: P2PKH (Pay-to-Public-Key-Hash) and P2SH (Pay-to-Script-Hash). P2PKH is a simple transaction type in which the recipient simply signs with the corresponding private key to use the asset. P2SH is more complex, such as in the case of multi-signatures, where a combined signature of multiple private keys is required to use the asset, or.

Together, these scripts and verification mechanisms form the core operation of the Bitcoin network, ensuring the security and flexibility of transactions.

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

Pubkey script: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

Input requires a signature

Signature script: sig

The output script rules of P2SH are as follows:

Pubkey script: OP_HASH160 OP_EQUAL

Input requires a multi-signature list

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

Among the above two types of script rules, Pubkey script represents the locking script, and Signature script represents the unlocking script. The words starting with OP_ are related script commands and are also instructions that the node can parse. These command rules are divided according to different Pubkey scripts, which also determine the rules for unlocking scripts.

The scripting mechanism in Bitcoin is relatively simple. It is just a stack-based engine that interprets relevant OP instructions. There are not too many script rules that can be parsed, and it cannot implement very complex logic. But it provided a prototype for blockchain programmability, and some subsequent ecological projects were actually developed based on scripting principles. With the updates of Segregated Witness and Taproot, the types of OP instructions have become more abundant, the size of the scripts that can be included in each transaction has been expanded, and the Bitcoin ecosystem has ushered in explosive growth.

Inscription technical principles and safety issues

The popularity of inscription technology is inseparable from Bitcoin’s Segregated Witness and Taproot updates.

Technically, the more decentralized a blockchain is, the less efficient it is generally. Taking Bitcoin as an example, the size of each block remains at 1MB, which is the same size as the first block originally mined by Satoshi Nakamoto. Faced with the problem of expansion, the Bitcoin community did not choose the path of simply and directly increasing the block size. Instead, they adopted an approach called Segregated Witness (SegWit), an upgrade scheme that does not require a hard fork and aims to improve the network by optimizing the data structure in the block. processing power and efficiency.

Segregated Witness

In Bitcoin transactions, the information of each transaction is mainly divided into two parts: basic transaction data and witness data. Basic transaction data includes key financial information such as account balances, while witness data is used to verify the user's identity. For users, their main concern is information directly related to assets, such as account balances, while identity verification details do not require too many resources in transactions. In other words, the party receiving the asset is primarily concerned with whether the asset is available and does not have to pay too much attention to the details of the sender.

However, in Bitcoin's transaction structure, witness data (i.e., signature information) occupies a large amount of storage space, which leads to reduced transfer efficiency and increased transaction packaging costs. In order to solve this problem, 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 is optimized storage space usage, thus increasing transaction efficiency and reducing costs.

In this way, while the original 1M block size remains unchanged, each block can accommodate more transactions, and the Segregated Witness data (that is, various signature scripts) can occupy an additional 3M space, providing Taproot script instructions. The richness lays the foundation for storage.

Taproot

Taproot is an important soft fork upgrade of the Bitcoin network, designed to improve the privacy and efficiency of Bitcoin scripts, and the processing capabilities of smart contracts. This upgrade is considered a major advancement since the 2017 SegWit upgrade.

This Taproot upgrade includes three different Bitcoin Improvement Proposals (BIPs): Taproot (Merkle Abstract Syntax Tree, MAST), Tapscript, and a new multi-signature friendly digital signature scheme called "Schnorr signature" . Taproot’s purpose is to provide Bitcoin users with a variety of benefits, including increased transaction privacy and lower transaction costs. Additionally, it will enhance Bitcoin’s ability to perform more complex transactions, thereby expanding its scope of applications.

The Taproot update directly affects three ecosystems: one is the ordinals protocol, which uses Taproot's script-path spend scripts to implement additional data; the other is the upgrade of the Lightning Network to Taproot Asset, which evolves from simple peer-to-peer BTC payment to peer-to-peer It supports the issuance of new assets; the other is the newly proposed BitVM, which uses op_booland and op_not in Taproot to "etch" the bool circuit into the Taproot script to realize the smart contract virtual machine function.

Ordinals

Ordinals is a protocol invented by Casey Rodarmor in December 2022 that gives each Satoshi a unique serial number and tracks them in transactions. Anyone can attach additional data, including text, images, videos, etc., to UTXO's Taproot script through Ordinals.

Friends who are familiar with Ordinals must know: the total number of Bitcoins is 21 million, and each Bitcoin contains 10^8 Satoshi (Satoshi), so there are a total of 21 million*10^8 Satoshis on the Bitcoin network, and the Ordinals protocol will These Satoshis are distinguished and each Satoshi has a unique number. This is theoretically possible, but in practice it cannot be done.

Because the BTC network has a minimum transfer limit of 546 satoshis (segwit is at least 294 satoshis) to resist dust attacks, that is, transfers of 1 satoshi and 1 satoshi are not allowed. Depending on the type of transfer address, at least 546 satoshis or 294 satoshis must be transferred. Satoshi, and according to the first-in-first-out numbering theory of Ordinals, at least Satoshi No. 1 to Satoshi No. 294 of each block are indivisible.

So the so-called engraving is not engraved on a certain satoshi, but engraved in the script of a transaction, and this transaction must contain at least a transfer of 294 satoshis, and then be tracked by a centralized indexer (such as unisat) and identify the transfer of these 294 satoshis or 456 satoshis.

How inscriptions are encoded in transactions

In principle the spending of Taproot scripts can only be done from existing Taproot output, so inscription should theoretically be done via a two-stage commit/reveal procedure. First, in the commit transaction, create a Taproot input based on the contents of the script path spend and specify the spend/revealed signature conditions in the output. Second, in a reveal transaction, the output created by the commit transaction is spent, revealing the inscription content on the chain.

However, in the actual indexer scenario, we do not pay much attention to the role of revealing the transaction. Instead, we directly read the script fragment consisting of an OP_FALSE OP_IF ... OP_ENDIF in the input script, and read the content of the inscription from it.

Because the combination of OP_FALSE and OP_IF instructions will cause the script to not be executed, bytes of arbitrary content can be stored in it without affecting the logic of the original script.

A text inscription containing the string "Hello, world!" is 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

The Ordinals protocol essentially serializes this piece of code into the Taproot script.

Let’s find a transaction from the chain to explain in detail the coding principle of ordinarys:

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

We can view the details of this transaction:

We analyze the encoding of the witness field starting from 0063 (OP_FALSE OP_IF), and we can understand the serialized encoding content:

So as long as we can decode this part of the code in the witness script, we can know the inscribed content. What is encoded here is plain text information, and other data such as html, pictures, videos, etc. are also similar.

In theory, you can also define your own encoding content, or even encrypted content that only you know, but these content cannot be displayed in ordinary browsers.

BRC20

On March 9, 2023, an anonymous Twitter user named domo posted a tweet on Twitter to create a fungible token standard on top of Ordinals Protocol, called the BRC20 standard. The idea is that JSON string data can be inscribed into Taproot scripts via the Ordinals protocol to deploy, mint, and transfer fungible BRC-20 tokens.

Figure 1: The humble beginnings of the BRC-20 token (domo’s first post on the subject)

Source: Twitter (@domodata)

Figure 2: Three possible initial operations for BRC-20 tokens (p = protocol name, op = operation, tick = ticker/identifier, max = maximum supply, lim = minting limit, amt = quantity)

Source: https://domo-2.gitbook.io/brc-20-experiment/, Binance Research

The initiator of the token deploys the brc20 token on the chain through deploy, and then the participants obtain the token through mint at almost no cost (only mining fees). When the number of mint exceeds the max, the inscription of the mint inscription will be considered invalid by the indexer . After this, the address that owns the Token can transfer the Token through the transfer inscription.

It is worth noting that Casey, the founder of Ordinals, is very unhappy that BRC-20 transactions account for the majority of the Ordinals protocol. He has publicly stated that BRC-20 brought a bunch of garbage to the Ordinals he created. Therefore, the Casey team publicly sent a letter asking Binance to delete Ordinals in the ORDI token introduction. He did not want the Ordinals protocol to be related to ORDI.

extended protocol

BRC20 swap

At present, unisat, the largest market, indexer and wallet supplier for inscription trading, has proposed the BRC20 swap protocol for BRC20 transactions, which is now available for early users to trial.

Previous inscription transactions could only be carried out through a method called PSBT (Partially Signed Bitcoin Transaction), which is similar to Opensea's off-chain signature scheme and uses centralized services to "match" the signatures of buyers and sellers. This results in that BRC20 assets can only be traded through pending orders like NFT assets, and the liquidity and transaction efficiency are very low.

brc20 swap introduces a mechanism called a module in the json string of the brc20 protocol. In this module, a set of scripts similar to smart contracts can be deployed. Taking the swap module as an example, the user can lock BRC20 into the module through transfer, that is, initiate a transfer transaction to himself, but the inscription in the transaction is locked in the module. After the user completes the transaction or withdraws from LP, You can initiate a transaction and withdraw the brc20 tokens.

Currently, brc20 swap operates in the extended mode of the black module. The black module is for security reasons. Without consensus and verification, the funds that users can withdraw are determined by the sum of funds in the module, that is, no user can withdraw Assets that exceed the total assets locked into the module.

When the behavior of the black module is understood and implemented by users, gradually becomes reliable, and is gradually accepted by more indexers, the product transitions from the black module to the white module and reaches a consensus upgrade. Users can freely deposit and withdraw assets.

In addition, because the brc20 protocol and even the entire Ordinals ecosystem are still in their early stages, Unisat occupies a greater influence and reputation. It provides complete indexing services such as transactions and balance inquiries for the protocol, and there is a single centralization risk. Its modular operation architecture allows more service providers to participate, thereby achieving a more decentralized index.

BRC420

The Brc420 protocol was developed by RCSV. They expanded upon the original inscription by adding a recursive index. More complex asset formats are defined recursively. At the same time, Brc420 establishes a binding relationship between usage rights and royalties on the basis of a single inscription. When a user mints an asset, he or she needs to pay royalties to the creator, and when he owns an inscription, he can allocate the right to use it and set a price for it. This move can encourage more innovation in the Ordinals ecosystem.

The proposal of Brc420 provides a broader imagination space for the inscription ecology. In addition to building a more complex metaverse through recursive references, smart contract ecology can also be constructed through recursive references of code inscriptions.

ARC20

The ARC20 token standard is provided by the Atomics protocol. In this standard, "atom" is the basic unit, built on Bitcoin's smallest unit Satoshi (sat). This means that each ARC20 token is always backed by 1 sat. Additionally, ARC20 is the first token protocol to mint via Proof of Work (PoW) inscriptions, allowing participants to directly mine inscriptions or NFTs in a manner similar to mining Bitcoin.

Equivalent of 1 ARC20 token to 1 sat brings several benefits:

1. First of all, the value of each ARC20 token will never be less than 1 sat, which makes Bitcoin act as a "digital gold anchor" in this process.

2. Secondly, when verifying a transaction, you only need to query the UTXO corresponding to sat, which is in contrast to BRC20, which requires off-chain ledger status records and the complexity of a third-party sequencer.

3. In addition, all operations of ARC20 can be completed through the Bitcoin network without additional steps.

4. Finally, due to the composability of UTXO, the direct exchange of ARC20 tokens and Bitcoin can theoretically be achieved, which provides the possibility of future liquidity.

The Atomics protocol sets special prefix parameters for Bitwork Mining for ARC20 tokens. Token issuers can choose a special prefix, and users must calculate the matching prefix through CPU mining before they are eligible to mint the ARC20 token. This “one CPU, one vote” model is consistent with the philosophy of Bitcoin fundamentalists.

Is the inscription safe?

The inscription seems to be just a piece of "harmless" text uploaded to the chain and parsed through a centralized indexer. It seems that the security issue is just a security consideration for centralized services. However, in terms of on-chain security, you still need to pay attention to the following points:

On-chain security issues

1. Increase node burden

Inscriptions increase the size of Bitcoin blocks, which increases the resources nodes require to propagate, store, and validate blocks across the network. If there are too many inscriptions, it will reduce the decentralization of the Bitcoin network and make the network more vulnerable to attacks.

2. Reduce security

Inscriptions can be used to store any type of data, including malicious code. If malicious code is added to Bitcoin blocks, it could lead to network security vulnerabilities.

3. Transactions need to be structured

The transaction of inscriptions requires the construction of transactions and attention to the first-in-first-out rule of ordinals to prevent the indexability of inscriptions from being destroyed due to inadvertence.

4. There are risks in buying and selling

Inscription's trading market, whether OTC or PSBT, has the risk of asset loss.

specific security issues

1. The orphan block rate and fork rate increase

Inscriptions increase the block size, which leads to an increase in the orphan block rate and the fork rate. Orphan blocks refer to blocks that are not recognized by other nodes, and forks refer to the existence of multiple competing blockchains in the network. Orphaned blocks and forks reduce the stability and security of the network.

2. The attacker tampered with the inscription

An attacker can exploit the openness of the inscription to conduct tampering attacks.

For example, an attacker could replace the information stored in the inscription with malicious code to infiltrate the indexer's servers or compromise user devices via Trojans.

3. Improper use of wallet

If the wallet is used improperly and the wallet cannot index the inscriptions, it is likely that the inscriptions will be transferred incorrectly, resulting in asset losses.

4. Phishing or Scamming

Attackers may use fake unisat and other indexer websites to induce users to conduct inscription transactions, thereby stealing user assets.

5. PSBT signature omission

Atomics Market once caused user assets to be damaged due to the incorrect use of signature methods.

Related Reading:

<The Analysis of the Atomics Market User Asset Loss>

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

Actions that can be taken

1. Limit the size of inscriptions

The size of the inscription can be limited to reduce the impact on the node burden, which Luke mentioned at the beginning of the article is already doing.

2. Encrypt the inscription

Inscriptions can be encrypted to prevent attacks by malicious code.

3. Use trusted sources of inscriptions

Trusted sources of inscriptions can be used to prevent signature issues and phishing.

4. Use a wallet that supports inscriptions

Use an Inscription-enabled wallet to make transfers.

5. Pay attention to the review of inscription codes and related scripts

In the new experiments of brc20-swap and recursive inscription, due to the introduction of codes and related scripts, it is necessary to ensure the security of these codes and scripts.

Summarize

From a technical and security perspective, Bitcoin Inscription is essentially a rule-bypassing vulnerability. The taproot script does not appear to store data, and there are also some security issues with it. Luke's changes to the bitcoin core code are correct from a security perspective. Luke did not directly modify the consensus layer of Bitcoin, but chose to adjust the Spam Filter (strategy filter) module so that nodes can automatically filter out Ordinals transactions when receiving P2P broadcast messages. In this strategy filter, there are several functions called isStandard() that check whether various aspects of the transaction meet the standards. If a transaction does not meet the criteria, the transaction received by the node will be quickly discarded.

In other words, although Ordinals transactions can eventually be added to the blockchain, most nodes will not add this type of data to the transaction pool, which will increase the delay for Ordinals data to be received by the mining pool willing to package it on the chain. However, if a mining pool broadcasts a block containing a BRC-20 transaction, other nodes will still recognize it.

Luke has already rolled out changes to the policy filter in the Bitcoin Knots client, and plans to introduce similar changes in the Bitcoin Core client. In this revision, he introduced a new parameter called g_script_size_policy_limit, which is used to limit the size of scripts in several different places. This change means there will be additional limitations on script size when processing transactions, affecting how transactions are accepted and processed.

Currently, the default value of this parameter is 1650Bytes, and any node client can set it through the parameter -maxscriptsize at startup:

However, even if the code is updated, it will still be a long time before all miner nodes are updated to the new version. During this time, innovators in the Inscription community should be able to create a more secure protocol.

Metatrust Labs has scored and monitored Inscription investment risks on the metaScore platform through on-chain data and asset tracking. At the same time, it has also launched a Bitcoin network monitoring rule engine on the metaScout platform, which can help investors monitor the real-time status of Bitcoin Inscription. data.

In this issue, we explore the technical principles and possible security issues of the now popular inscription ecology. In the next issue, we will bring you the more complex Taproot circuit etching technology-bitVM, so stay tuned.

About MetaTrust Labs

MetaTrust Labs is a leading provider of Web3 artificial intelligence security tools and code audit services incubated by Nanyang Technological University in Singapore. We provide advanced AI solutions that empower developers and project stakeholders to secure Web3 applications and smart contracts. Our comprehensive services include AI security scanning, code auditing, smart contract monitoring and transaction monitoring. By integrating AI, we ensure a secure ecosystem and enhance trust between users and developers.

Official website: https://www.metatrust.io/

Twitter: https://twitter.com/MetaTrustLabs

Linkedin: https://www.linkedin.com/in/metatrust