Where does the inscription go?
Preface
On December 6, 2023, when Bitcoin investors were cheering for the increase in Bitcoin brought by Inscriptions, Luke Dashjr, a developer of the Bitcoin Core node client, poured cold water on the situation. He believed that Inscriptions was a "spam" attack and submitted a fix code and CVE vulnerability report (CVE-2023-50428). The Bitcoin community was then in an uproar. Following the chaos of the hard fork in 2017, the Bitcoin community was once again caught in a heated debate.
So should Bitcoin focus more on security and abandon some unexpected features, or should it be more inclusive of unexpected innovations and tolerate some possible security issues?
We know that Bitcoin’s journey is not just about speculation and hype, but also about the continuous evolution of its ecosystem and security landscape. 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 how the synergy of innovation and strong security protocols paves 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 regarded 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 pioneers first started experiments with stablecoins, Layer2, and even DEFI. For example, the current hard currency USDT in the cryptocurrency circle was first issued on the Bitcoin Omnilayer network. The figure below is a basic classification of the Bitcoin ecosystem from the perspective of technical implementation.
Including side chains based on two-way 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. Don’t worry. Let’s first familiarize ourselves with the following basic knowledge, 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 transaction
Unlike Ethereum's account balance system, Bitcoin does not have the concept of accounts. 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) may sound a bit awkward, but it is easy to understand once you understand the three concepts of input, output, and transaction.
Transaction Inputs and Outputs
Friends who are familiar with Ethereum should know that transactions are the basic communication unit in the blockchain network. Once a transaction is packaged and confirmed, it means that the state change on the chain is confirmed. In Bitcoin transactions, it is not a single address-to-address state operation, but a combination of multiple input scripts and output scripts.
The above picture is a very typical Bitcoin 2-to-2 transaction. In theory, the number of BTC input and the number of BTC output should be equal. In fact, the BTC output that is less than the input is earned by the block miner as a handling fee, which is equivalent to the Gas Fee in Ethereum.
We can see that when the two input addresses transfer BTC, they need to be verified in the input script to prove that the two input addresses can spend the two inputs (that is, the unspent output of the previous transaction, UTXO), while the output script stipulates the conditions for spending the two output bitcoins, that is, what conditions should be met when the unspent output is used as input next time (for ordinary transfers, the condition is the signature of the output address. For example, in the figure above, P2wPKH means that the signature verification of the taproot address is required, and P2PKH means that the signature of the legacy address private key is required).
Specifically, the data structure of a Bitcoin transaction 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 and the total output. 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 legal 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 referred to as UTXO (Unspent Transaction Output) of the Bitcoin network.
In the Bitcoin network, the input of each new transaction must be an unspent output. In addition, each input requires the signature of the corresponding private key of the previous output. Each node in the Bitcoin network stores all UTXOs on the current blockchain to verify the legitimacy of new transactions. Through the UTXO and signature verification mechanism, nodes can verify the legitimacy of new transactions without tracing back the entire transaction history, thereby simplifying the operation and maintenance of the network.
Bitcoin's unique transaction structure is designed in accordance with its white paper "Bitcoin: A Peer-to-Peer Electronic Cash System". Bitcoin is an electronic cash system, and its transaction structure simulates the cash transaction process. The amount that can be spent at an address depends on the amount of cash received before. Each transaction is to spend all the cash on this address as a whole, and the output address of the transaction is usually one receiving address and the other a change address, just like the change when using cash transactions in a supermarket.
Screenplay
In the Bitcoin network, scripts play a vital role. In fact, each output of a Bitcoin transaction actually points to a script, not 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 legitimacy verification of transactions relies on two scripts: locking scripts and unlocking scripts. The locking script is present in the output of the transaction and is used to define the conditions required to unlock the output. The unlocking script corresponds to it and must follow the rules defined by the locking script to unlock the UTXO assets. These scripts are located in the input part of the transaction. The flexibility of this scripting language allows Bitcoin to implement a variety of conditional 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 a "first in, first out" rule.
There are two main common types of 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 only needs to sign with the corresponding private key to use the asset. P2SH is more complicated, for example, in the case of multi-signature, the combined signature of multiple private keys is required to use the asset, or.
These scripts and verification mechanisms together constitute the core operating mode 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 needs to provide a multi-signature list
Signature script: [say] [say...]
In the above two script rules, Pubkey script represents the locking script, and Signature script represents the unlocking script. Words starting with OP_ are related script commands, which are also instructions that the node can parse. These command rules are divided according to the differences in Pubkey script, which also determines the rules for unlocking scripts.
The script mechanism in Bitcoin is relatively simple. It is just a stack-based engine that interprets related OP instructions. It can only parse a few script rules and cannot implement very complex logic. However, it provides a prototype for blockchain programmability. Some subsequent ecological projects are actually developed based on the principle of scripts. With the update of Segregated Witness and Taproot, the types of OP instructions have become richer, and the size of scripts that can be included in each transaction has been expanded, and the Bitcoin ecosystem has ushered in explosive growth.
Inscription Technology Principles and Security 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. Take Bitcoin, for example. The size of each of its blocks remains at 1MB, the same size as the first block originally mined by Satoshi Nakamoto. Faced with the problem of capacity expansion, the Bitcoin community did not choose to simply increase the block size. Instead, they adopted a method called "Segregated Witness" (SegWit), an upgrade solution that does not require a hard fork and aims to improve the network's processing power and efficiency by optimizing the data structure in the block.
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 balance, while witness data is used to verify the identity of the user. For users, they are mainly concerned about information directly related to assets, such as account balance, and the details of identity verification do not need to take up too many resources in the transaction. In other words, the party receiving the assets is mainly concerned about whether the assets are available, without having to pay too much attention to the detailed information of the sender.
However, in the transaction structure of Bitcoin, witness data (i.e. signature information) occupies a large amount of storage space, which leads to reduced transfer efficiency and increased transaction packaging costs. To solve this problem, Segregated Witness (SegWit) technology was introduced. Its core idea is to separate witness data from the main transaction data and store it separately. The result of this is to optimize the use of storage space, thereby improving transaction efficiency and reducing costs.
In this way, each block can accommodate more transactions while the original 1M block size remains unchanged, and the isolated witness data (that is, various signature scripts) can occupy an additional 3M space, laying the storage foundation for the enrichment of Taproot script instructions.
Taproot
Taproot is an important soft fork upgrade of the Bitcoin network, which aims to improve the privacy, efficiency and processing capacity of Bitcoin scripts and smart contracts. This upgrade is considered a major advancement since the SegWit upgrade in 2017.
The Taproot upgrade includes three different Bitcoin Improvement Proposals (BIPs): Taproot (Merkel Abstract Syntax Tree, MAST), Tapscript, and a new multi-signature-friendly digital signature scheme called "Schnorr Signature". Taproot aims to provide multiple benefits to Bitcoin users, including increased privacy and lower transaction costs. In addition, it will enhance Bitcoin's ability to perform more complex transactions, thereby expanding its scope of application.
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 point-to-point BTC payments to point-to-many and supports the issuance of new assets; and the other is the newly proposed BitVM, which "etches" the bool circuit into the Taproot script through op_booland and op_not in Taproot, thereby realizing 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. Ordinals allow anyone to attach additional data to the Taproot script of a UTXO, including text, pictures, videos, etc.
Those who are familiar with Ordinals must know that the total number of Bitcoins is 21 million, and each Bitcoin contains 10^8 Satoshis, so there are a total of 21 million*10^8 Satoshis on the Bitcoin network. The Ordinals protocol will distinguish these Satoshis, and each Satoshi has a unique number. This is theoretically possible, but not in practice.
In order to defend against dust attacks, the BTC network has a minimum transfer limit of 546 satoshis (segwit has a minimum of 294 satoshis), which means that 1 satoshi transfers are not allowed. Depending on the transfer address type, at least 546 satoshis or 294 satoshis must be transferred. According to the Ordinals first-in-first-out numbering theory, at least satoshis 1 to 294 in 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 a centralized indexer (such as Unisat) will track 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 outputs, so inscriptions should theoretically be done through a two-phase commit/reveal procedure. First, in the commit transaction, a Taproot input based on the contents of script path spend is created, and the signature conditions for spending/revealing are specified in the output. Second, in the reveal transaction, the output created by the commit transaction is spent, revealing the contents of the inscription on the chain.
However, in the actual indexer scenario, the role of posting transactions is not very important. Instead, a script fragment consisting of an OP_FALSE OP_IF ... OP_ENDIF is directly read from the input script to read the content of the inscription.
Because the OP_FALSE OP_IF command combination will cause the script to not be executed, you can store bytes of arbitrary content 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 code into the Taproot script.
Let’s find a transaction on the chain to explain in detail the encoding principle of ordinals:
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) to 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 content of the inscription. The information encoded here is plain text information, and other data such as HTML, pictures, videos, etc. are similar.
Theoretically, you can also define your own encoded content, or even encrypted content that only you know, but these contents cannot be displayed in ordinals 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, calling it the BRC20 standard. The idea is that JSON string data can be engraved in Taproot scripts through the Ordinals protocol to deploy, mint, and transfer fungible BRC-20 tokens.
Figure 1: The humble beginnings of BRC-20 tokens (domo’s first post on the topic)
Source: Twitter (@domodata)
Figure 2: Three possible initial operations for a BRC-20 token (p = protocol name, op = operation, tick = ticker/identifier, max = maximum supply, lim = minting limit, amt = amount)
Source: https://domo-2.gitbook.io/brc-20-experiment/, Binance Research
The initiator of the token deploys the brc20 token to the chain through deploy, and then the participants obtain the token at almost no cost through mint (only the mining fee). When the mint quantity exceeds the max, the mint inscription will be considered invalid by the indexer. After that, the address with 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 most of the Ordinals protocol. He once publicly stated that BRC-20 brought a lot of garbage to Ordinals, which he created. Therefore, Casey's team publicly sent a letter to Binance to delete Ordinals from the introduction of the ORDI token. He does not want the Ordinals protocol to be associated with ORDI.
Extending the protocol
BRC20 swap
Unisat, the largest market, indexer and wallet provider for inscription transactions, has proposed the BRC20 swap protocol for BRC20 transactions, and now allows early users to try it out.
Previously, inscription transactions could only be conducted through a method called PSBT (partially signed Bitcoin transactions), which is similar to Opensea's off-chain signature solution, using a centralized service to "match" the signatures of buyers and sellers. This resulted in BRC20 assets being traded only through pending orders like NFT assets, with low liquidity and transaction efficiency.
BRC20 swap introduces a mechanism called module in the json string of the BRC20 protocol, in which a set of scripts similar to smart contracts can be deployed. Taking the swap module as an example, users can lock BRC20 into the module through transfer, that is, initiate a transfer transaction to themselves, but the inscription in the transaction is locked in the module. After completing the transaction or withdrawing LP, users can initiate a transaction and then withdraw the BRC20 token.
Currently, brc20 swap runs in extended mode of black module. The black module is for security reasons. Without consensus and verification, the total amount of funds in the module is used to determine the funds that users can withdraw. That is, no user can withdraw assets exceeding the total amount of assets locked in the module.
When the behavior of the black module is understood and executed by users, gradually becomes reliable, and is gradually accepted by more indexers, the product transitions from the black module to the white module, and a consensus upgrade is reached. Users can then freely deposit and withdraw assets.
In addition, because the brc20 protocol and even the entire Ordinals ecosystem are still in their early stages, Unisat has a greater influence and reputation. It provides complete indexing services such as transactions and balance inquiries for the protocol, which poses a centralization risk of being the only one. 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 added a recursive index extension to the original inscription. A more complex asset format was defined in a recursive way. At the same time, Brc420 established a binding relationship between usage rights and royalties based on a single inscription. When a user mints an asset, he needs to pay royalties to the creator, and when he owns an inscription, he can allocate its usage rights and set a price for it, which can encourage more innovation in the Ordinals ecosystem.
The introduction of Brc420 provides a broader imagination space for the inscription ecosystem. In addition to building a more complex metaverse through recursive references, it is also possible to build a smart contract ecosystem through recursive references of code inscriptions.
ARC20
The ARC20 token standard is provided by the Atomicals protocol, in which "atoms" are the basic units, built on top of Bitcoin's smallest unit, sat. This means that each ARC20 token is always backed by 1 sat. In addition, ARC20 is the first token protocol minted through proof-of-work (PoW) inscriptions, allowing participants to directly mine inscriptions or NFTs in a similar way to mining Bitcoin.
Equating 1 ARC20 token to 1 sat brings multiple benefits:
1. First, the value of each ARC20 token will never be less than 1 sat, which makes Bitcoin act as a kind of "digital gold anchor" in the process.
2. Secondly, when verifying a transaction, it is only necessary to query the UTXO corresponding to sat, which contrasts with the complexity of BRC20, which requires off-chain ledger state records and third-party sorters.
3. In addition, all operations of ARC20 can be completed through the Bitcoin network without the need for additional steps.
4. Finally, due to the composability of UTXO, it is theoretically possible to directly exchange ARC20 tokens with Bitcoin, which provides possibilities for future liquidity.
The Atomicals protocol sets a special prefix parameter for Bitwork Mining for ARC20 tokens. Token issuers can choose a special prefix, and users must calculate the matching prefix through CPU mining to be 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 "harmless" text on the chain and parsed by a centralized indexer. It seems that the security issue is only a security consideration on the centralized service. However, in terms of on-chain security, the following points should be noted:
On-chain security issues
1. Increase node burden
Inscriptions increase the size of Bitcoin blocks, which increases the resources required by nodes to propagate, store, and verify blocks on 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. Reduced security
Inscriptions can be used to store any type of data, including malicious code, which, if added to a Bitcoin block, could lead to a network security breach.
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 indexicality of the inscription from being destroyed due to inadvertence.
4. There are risks in buying and selling
The trading market of Inscription, whether OTC or PSBT, carries the risk of asset loss.
Specific safety issues
1. Increased orphan block rate and fork rate
Inscriptions increase the size of blocks, which will lead to an increase in the orphan block rate and 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. Orphan blocks and forks will reduce the stability and security of the network.
2. The attacker tampered with the inscription
Attackers can exploit the openness of the inscription to perform tampering attacks.
For example, an attacker could replace the information stored in the inscription with malicious code, thereby infiltrating the indexer's server or invading the user's device through a Trojan horse.
3. Improper use of wallet
If the wallet is used improperly and cannot index the inscription, it is very likely that the inscription will be transferred incorrectly, resulting in asset loss.
4. Phishing or Scam
Attackers may use fake indexer websites such as unisat to induce users to conduct inscription transactions and steal user assets.
5. PSBT Signature Omission
Atomicals Market once caused user assets to be damaged due to the use of incorrect signing methods.
Related Reading:
<The Analysis of the Atomicals Market User Asset Loss>
https://metatrust.io/company/blogs/post/the-analysis-of-the-atomicals-market-user-asset-loss
What can be done?
1. Limit the size of the inscription
The size of the inscription can be limited to reduce the impact on the node burden, which is what Luke mentioned at the beginning of the article has already done.
2. Encrypt the inscription
The inscription can be encrypted to prevent attacks by malicious code.
3. Use a trusted source for the inscription
A trusted source of inscriptions can be used to prevent signature issues and phishing.
4. Use a wallet that supports inscriptions
Use a wallet that supports Inscription to carry out transfer activities.
5. Pay attention to the review of inscription codes and related scripts
In the new experiments of brc20-swap and recursive inscriptions, 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 inscriptions are essentially a loophole that bypasses the rules. The taproot script was not created to store data, and its security also has some issues. Luke's modification of the bitcoin core code is correct from a security perspective. Luke did not directly modify the consensus layer of Bitcoin, but chose to adjust the Spam Filter module so that nodes can automatically filter out Ordinals transactions when receiving P2P broadcast messages. In this policy filter, there are multiple functions named isStandard() that are used to check whether various aspects of a transaction meet the standards. If a transaction does not meet the standards, 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 such 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 BRC-20 transactions, 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 modification, he introduced a new parameter called g_script_size_policy_limit, which is used to limit the size of scripts in multiple different places. This change means that when processing transactions, the script size will be subject to additional restrictions, affecting how transactions are accepted and processed.
Currently, the default value of this parameter is 1650Bytes. Any node client can set it by using the parameter -maxscriptsize at startup:
However, even if the code is updated, it will take a long time before all mining 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. It has also launched a Bitcoin network monitoring rule engine on the metaScout platform to help investors monitor the real-time data of Bitcoin inscriptions.
In this issue, we explore the technical principles and possible security issues of the current popular inscription ecosystem. In the next issue, we will bring you a more complex Taproot circuit etching technology - bitVM, so stay tuned.
About MetaTrust Labs
MetaTrust Labs is a leading Web3 AI security tool and code audit service provider incubated by Nanyang Technological University, Singapore. We provide advanced AI solutions that empower developers and project stakeholders to protect 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 that enhances trust between users and developers.
Official website: https://www.metatrust.io/
Twitter: https://twitter.com/MetaTrustLabs
Linkedin: https://www.linkedin.com/in/metatrust
