After reading this, your understanding of Ordinals inscriptions will exceed that of 99% of people

Author: Ash Li, Noah Ho

With the birth of the Ordinals protocol, it provides numbering and inscription capabilities for Bitcoin, thereby broadening the range of products in the Bitcoin ecosystem and bringing new vitality to the Bitcoin ecology. In this article, we will delve into the details of the Ordinal protocol, including how to number and track each Bitcoin, as well as the relationship between inscriptions and numbering. But before we dive into this topic, we first need to understand some basic background about Bitcoin to help us better comprehend the subsequent content.

After reading this article, you will grasp the transaction mechanism and payment model of Bitcoin, understand how Ordinals achieves numbering and tracking for each satoshi, and learn how inscriptions are created and traded. Additionally, you will understand the differences between different types of wallets.

I. Background of Bitcoin

Bitcoin adopts a cash-like transaction model, with its payment method based on a model called UTXO, which differs from the traditional account balance-based model. For example, in the bank's account bookkeeping model, when A transfers 100 yuan to B, the bank records three steps, which constitute a transaction process. The first step is to deduct 100 yuan from A's account, with the record ID for this step being tid1. The second step is to deposit 100 yuan into B's account, with the record ID for this step being tid2. The third step is to record a transfer record that associates tid1 and tid2, indicating that A's account has decreased by 100 yuan and B's account has increased by 100 yuan. In this way, the transfer relationship between A and B is recorded and can be queried and tracked in the future. Now, we will explain Bitcoin's payment method through an introduction to UTXO and the payment model.

UTXO

In the Bitcoin blockchain, all balances are stored in a list called "Unspent Transaction Output" (UTXO). Each UTXO contains a certain amount of Bitcoin, as well as the owner's information, and indicates whether it is available. It can be imagined as a cash check signed by the holder's name, which can be transferred to others as long as the holder signs it. For a specific address, the total amount of all its UTXOs equals the balance of that address's wallet. By traversing all UTXOs, we can obtain the current balance of each address. Summing all UTXO amounts gives the total circulating Bitcoin.

In the structure of Bitcoin transactions, each transaction includes several inputs and outputs, where each input is a reference to an existing UTXO, and each output specifies a new fund receiving address and the corresponding amount. Once a transaction is initiated, the UTXOs referenced by its inputs are temporarily locked to prevent them from being reused before the transaction is completed. Only when this transaction is successfully packaged into a block by miners and confirmed by the network does the status of the relevant UTXOs change. Specifically, the UTXOs used for transaction inputs will be removed from the UTXO list, indicating that they have been consumed, while the transaction outputs will generate new UTXOs and add them to the UTXO list. It can be understood that an old cash check becomes invalid after being used, generating a new cash check whose ownership belongs to the new holder.

It is important to emphasize that each UTXO can only be used once in a transaction. Once it is consumed as an input, it will be permanently removed from the UTXO list. Meanwhile, the newly generated outputs are added to the list as new UTXOs. The UTXO list is constantly changing and will be updated accordingly with the creation of each new block. Moreover, by analyzing the transaction history in the blockchain, we can reconstruct the state of the UTXO list at any given point in time.

Additionally, the total input amount of a transaction usually slightly exceeds its total output amount. This difference, known as the transaction fee or network fee, is given as an incentive to the miners responsible for packaging the transaction into a block. The size of the network fee is proportional to the complexity of the transaction; therefore, a transaction with more inputs and outputs typically requires a higher network fee.

Now, to better understand the structure of Bitcoin transactions, we will conduct an in-depth analysis through a specific example. The structure of a Bitcoin transaction is as follows, where the variables vin and vout represent the "input" and "output" of the Bitcoin transaction, respectively. Bitcoin transactions do not record changes in account data like traditional account balance models but represent them through inputs and outputs.

Source: https://github.com/bitcoin/bitcoin/blob/v22.0/src/primitives/transaction.h#L270

We can randomly select a transaction record from blockchain.com for analysis. The following figure shows the transaction with Hash ID 0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2. It contains one input and two outputs.

By using the bitcoin-cli commands getrawtransaction and decoderawtransaction, we can view the underlying structure of the above transaction:

In the Bitcoin network, transaction outputs contain two important pieces of information: address (public key hash) and amount (in Bitcoin). If an output of a transaction is not used in the inputs of other transactions, then that output is referred to as an unspent transaction output (UTXO). Whoever possesses the private key corresponding to the public key in the UTXO has the right to use (i.e., spend) that UTXO.

Let's take a look at the information in "vin" from the above code, which indicates that the UTXO spent in this transaction comes from another transaction (with ID 7957a…f6f18) and is the 0th output of that transaction (a transaction can have multiple outputs, indexed starting from 0). We can find the amount of this UTXO from historical transactions (for example, 0.1), so in this transaction, this user spent 0.1 BTC. The value 0.1 does not need to be explicitly written in the transaction but is obtained by looking up the UTXO information. This transaction's "vout" has two outputs, which correspond to two new UTXOs, representing new balances and holders until another transaction consumes them as inputs.

Payment Model

To better understand the payment model of the Bitcoin network, we will introduce an example of a payment process where A pays B an amount of n Bitcoin. The following figure illustrates the process of user A sending 3 Bitcoin to user B.

1. For user A, the first step is to determine the entire set of UTXOs they own, which represents all the Bitcoin that user A can control;

2. A selects one or more UTXOs from this set as inputs for the transaction, with the total amount of these inputs m (2 + 0.8 + 0.5 = 3.3 BTC) being greater than the amount to be paid n (3 BTC);

3. User A sets two outputs for the transaction: one output pays the address of B an amount of n (3 BTC), and the other output pays a change address of A an amount of m - n - fee (3.3 - 3 - 0.001 = 0.299 BTC). User wallets typically consist of multiple addresses, and generally, each address is used only once, with change returned to a new address by default;

4. Once the miners package this transaction on-chain for confirmation, B will receive the transaction information. Since the block size has an upper limit (about 1 MB), miners prioritize confirming transactions with higher fee rates (fee_rate = fee/size) to maximize their fee rewards. We can see real-time mining transaction fee situations in the mempool. If we want the fastest confirmation during the transfer process, we can choose high priority or customize a suitable transaction fee rate.

II. Numbering and Tracking of Satoshis

The total number of Bitcoins is 21 million, and each Bitcoin contains 10^8 satoshis. Therefore, there are a total of 21 million * 10^8 satoshis in the Bitcoin network. The Ordinals protocol distinguishes these satoshis and assigns a unique number to each satoshi. This section will introduce how this protocol uniquely numbers each satoshi and how to track the accounts they belong to. Additionally, we will briefly introduce the classification of satoshi rarity.

Numbering of Satoshis

According to the Ordinals protocol, the numbering of satoshis is determined by the order in which they are mined. The following figure shows the representation of the 0th satoshi mined from the 0th block.

There are several ways to express a satoshi:

• Integer notation: For example, 2099994106992659, indicating the sequence number assigned to that satoshi according to the mining order.
• Decimal notation: For example, 3891094.16797, where the first number indicates the block height at which the satoshi was mined, and the second number indicates the satoshi's number within the block.
• Degree notation: For example, 3°111094′214″16797‴, where the first number is the cycle, starting from 0, the second number is the block index of the halving epoch, the third number is the block index during difficulty adjustment, and the last number is the index of the satoshi within the block.
• Percentage notation: For example, 99.99971949060254%, indicating the position of that satoshi in the Bitcoin supply, expressed as a percentage.
• Name: For example, Satoshi. A name encoded using characters a to z for the sequence number.

We will explain how to number newly mined Bitcoins through an example. Observing the 795952nd block of the Bitcoin blockchain, we can see that the first transaction Tx 3a1f…b177 records the miner's reward (Coinbase transaction). This transaction contains newly mined Bitcoins, which are the packaging rewards for miners and the transaction fees paid by the initiator to the miners. By examining the inputs in the following figure, we can find that the UTXO's ID consists of a string of 0s and the block height. The output address is the miner's wallet address, and the amount is the total of the aforementioned rewards and fees.

If we further examine the portion of the output to the miner, we can see the address, amount, and distribution of the included satoshis. As mentioned earlier, these include mining rewards and fees. Among them, the green sat numbering information 1941220000000000--1941220625000000 represents the new satoshis generated from the mining reward, while the remaining 712 records correspond to all the fees in that block.

We can verify the number Sat 1941220000000000. Its block number is 795952, and its decimal notation is 795952.0, meaning that the satoshi was mined at block height 795952, and its number in this block is 0, with the subsequent rarity marked as uncommon, which we will detail in the following sections.

Flow of Satoshis

Since every BTC is generated through mining rewards, they are all traceable. Bitcoin accounts use the UTXO model. Suppose user A has obtained the 100th to 110th satoshis through mining (10 satoshis are stored as a whole in a UTXO with ID adc123). When user A wants to pay user B 5 satoshis, they choose to use the UTXO with ID abc123 as the input for the transaction, where 5 satoshis go to user B, and 5 satoshis are returned as change to user A. Both sets of 5 satoshis are a whole, stored in two UTXOs with IDs abc456 and abc789. The above UTXO IDs and the number of satoshis are only examples; in practice, the minimum number of satoshis sent is 546, and the UTXO IDs are not expressed in this form.

In the above transaction, the flow path of user A's 10 satoshis is as follows:

1. 10 satoshis are generated through mining, numbered [100, 110). This indicates that the satoshis numbered from 100 to 109 are stored in the UTXO with ID abc123, and their owner is user A.

2. When A makes the transfer, the 10 satoshis are divided into two parts, each containing 5 satoshis. Here, the "first in, first out" principle is applied, meaning that the numbering of satoshis is determined by their index in the transaction output. Assuming the output order is first user A, then user B, the remaining 5 satoshis of user A will have the sequence number [100, 105), stored in the UTXO with ID abc456, while user B's 5 satoshis will have the sequence number [105, 110), stored in the UTXO with ID abc789.

Rarity (Rare Satoshi)

As a derivative play of the Ordinals protocol, the rarity of satoshis can be defined based on their mining order. This leads to some special satoshis having different rarities. The following are the different levels of satoshi rarity:

• common: Any satoshi other than the first satoshi of the block (total supply of 21 trillion)
• uncommon: The first satoshi of each block (total supply of 6,929,999)
• rare: The first satoshi of each difficulty adjustment period (total supply of 3,437)
• epic: The first satoshi after each halving (total supply of 32)
• legendary: The first satoshi of each cycle (total supply of 5)
• mythic: The first satoshi of the genesis block (total supply of 1)

This concept of rare satoshis can add more fun and value to the Bitcoin ecosystem. Satoshis of different rarities may have different values in the market, attracting collectors and investors.

Inscription Method

Ordinals are significantly different from NFTs on other non-Bitcoin chains. The main difference is that the metadata of Ordinals is not stored in a specific location. Instead, this metadata is embedded in the witness data of the transaction, which is why we refer to it as "inscription," as this data is "carved" into a specific part of the Bitcoin transaction, and this data is attached to specific satoshis. This inscription process is achieved through Segregated Witness (SegWit) and "Pay-to-Taproot" (P2TR), which includes two stages: commit and reveal, allowing any form of content (such as text, images, or videos) to be inscribed onto designated satoshis. We will introduce another more direct storage method, OP_RETURN, and explain why it has not been used as an inscription method. At the same time, we will explain what Segregated Witness and Pay-to-Taproot are and their roles in inscriptions. Finally, we will introduce the method of inscription.

OP_RETURN

In Bitcoin Core client version 0.9, the RETURN operator was ultimately implemented as a compromise. RETURN allows developers to add 80 bytes of non-payment data to transaction outputs. Unlike pseudo-payments, RETURN creates a clear verifiable non-consumable output, and such data does not need to be stored in the UTXO set. RETURN outputs are recorded on the blockchain; they consume disk space and increase the size of the blockchain, but they are not stored in the UTXO set, so they do not inflate the UTXO memory pool, nor do they increase the costly memory overhead for full nodes.

Although OPRETURN is a very straightforward way to store information on the Bitcoin blockchain, it is also a potential method for inscriptions. However, the limitations of OPRETURN pose some challenges when handling metadata storage. First, OPRETURN can only store 80 bytes of data, which is clearly insufficient for cases requiring larger data storage. Second, OPRETURN data is stored in the transaction output section; although this data is not stored in the UTXO set, it occupies storage space on the blockchain, leading to an increase in blockchain size. Finally, using OP_RETURN will increase transaction fees, as it requires paying more fees to publish these transactions.

Segregated Witness

In contrast, the new method provided by SegWit can overcome the above issues. SegWit is an important protocol upgrade for Bitcoin, proposed by Bitcoin core developer Pieter Wuille in 2015 and officially adopted in version 0.16.0 in 2017. The term Segregated in Segregated Witness means separation or isolation, while Witness refers to the signature data related to the transaction. Therefore, SegWit separates certain transaction signature data (witness data) from the transaction.

The main benefit of separating signature data from transaction-related data is that it reduces the size of data stored in a Bitcoin block. This allows each block to have additional capacity to store more transactions, meaning the network can handle more transactions, and senders pay lower fees. Technically, this involves taking the script signature (scriptSig) information out of the base block structure and placing it in a new data structure. Nodes and miners performing validation will also verify the script signatures in this new data structure to ensure the transaction is valid. The SegWit upgrade introduced a new witness field in transaction outputs to ensure privacy and performance. Although witness data is not designed for data storage, it actually gives us an opportunity to store inscription metadata and other content. We can use the following diagram to better understand Segregated Witness:

Description of transaction structure before SegWit (percentage data usage)

Description of transaction structure after SegWit (percentage data usage)

Transaction data structure before and after SegWit

Taproot

P2TR is a type of Bitcoin transaction output introduced in the Taproot upgrade conducted in 2021, which allows different transaction conditions to be stored more privately on the blockchain. In the inscriptions of Ordinals, P2TR plays a crucial role. Inscriptions essentially embed specific data content into Bitcoin transactions, and the Taproot upgrade, especially P2TR, makes this embedded data more flexible and economical.

First, due to the storage method of Taproot scripts, we can store inscription content in the Taproot script path spending scripts, which have almost no restrictions on content while also obtaining a discount on witness data, making the storage of inscription content relatively economical. Since Taproot scripts can only be consumed from existing Taproot outputs, inscriptions adopt a two-stage commit/reveal process. First, in the commit transaction, a Taproot output is created that commits to a script containing the inscription content. Then, in the reveal transaction, the output created by the commit transaction is consumed, revealing the inscription content on-chain.

This approach significantly reduces resource consumption. If P2TR is not used, witness information would be stored in the transaction outputs. Thus, as long as this output is not consumed, the witness information would remain stored in the UTXO set. In contrast, if P2TR is used, the witness information will not appear in the transaction generated during the commit phase, so it will not be written into the UTXO set. Only when this UTXO is consumed will the witness information appear in the transaction inputs of the reveal phase. P2TR allows metadata to be written into the Bitcoin blockchain without ever appearing in the UTXO set. Since maintaining/modifying the UTXO set requires more resources, this approach can save a significant amount of resources.

Inscription

The Ordinals protocol utilizes SegWit to relax the size limits on writing content to the Bitcoin network, allowing inscription content to be stored in witness data. This enables the storage of up to 4MB of metadata. Taproot makes it easier to store any witness data in Bitcoin transactions, allowing Ordinals developer Casey Rodarmor to repurpose old opcodes (OPFALSE, OPIF, OP_PUSH) for what he describes as "envelopes" to store arbitrary data known as "inscriptions."

The process of minting inscriptions consists of the following two steps:

1. First, a commitment to a script containing the inscription content is created in the commit transaction as a Taproot output. The storage format is Taproot, meaning that the output of the previous transaction is P2TR (Pay-To-Taproot), and the input of the subsequent transaction embeds specific formatted content in the witness's Taproot script; first, the string "ord" is pushed onto the stack to eliminate ambiguity about the inscription's other uses. OPPUSH 1 indicates that the next push contains the content type, and OPPUSH 0 indicates that the subsequent data push contains the content itself. Large inscriptions must use multiple data pushes, as one of the limitations of Taproot is that a single data push cannot exceed 520 bytes. At this point, the inscription data is associated with the UTXO of the transaction output but has not been made public.

2. Second, the output created by the commit transaction needs to be consumed in the reveal transaction. At this stage, a transaction is initiated by using the UTXO corresponding to that inscription as input. At this point, the corresponding inscription content is made public to the entire network.

Through these two steps, the inscription content is bound to the UTXO being inscribed. According to the previous introduction to the positioning of satoshis, the inscription is performed on the first satoshi corresponding to the input UTXO, and the inscription content is included in the displayed transaction inputs. Based on the previous introduction to the flow and tracking of satoshis, this satoshi with special content can be transferred, purchased, sold, lost, and recovered. It is important to note that inscriptions cannot be repeated; otherwise, subsequent inscriptions will be invalid.

We will illustrate this process in detail by inscribing a small image of a BTC NFT, which mainly includes the previously mentioned commit and reveal stages. First, we see that the Hash ID of the first transaction is 2ddf9…f585c. It can be noted that this transaction's output does not contain witness data, and there is no related inscription information on the webpage.

Next, we check the records of the second stage, with Hash ID e7454…7c0e1. Here, we can see the information of the Ordinals inscription, which is the witness's inscription content. The input address of this transaction is the output address of the previous transaction, and the output of 0.00000546 BTC (546 satoshis) is sent to the user's address. At the same time, we can also find this inscription in sat 1893640468329373.

In the Bitcoin wallet, we can see this asset. If we want to trade this NFT, we can directly send it to another person's address, which means sending out this UTXO, thus completing the flow of the inscription.

IV. Bitcoin Wallets

After understanding what the Ordinals ecosystem is, the flow of satoshis, and the related knowledge of inscriptions, there are currently many application scenarios, whether it is the emergence of related derivative protocols such as BRC-20, ORC-20, BRC-721, GBRC-721, etc., which require us to have corresponding wallets to support and display token information or NFT images. This section will introduce the concepts and characteristics of different Bitcoin wallet addresses.

Bitcoin addresses start with 1, 3, or bc1. Like email addresses, they can be shared with other Bitcoin users, who can use them to send Bitcoin directly to their wallets. From a security perspective, Bitcoin addresses contain no sensitive content. They can be published anywhere without compromising account security. Unlike email addresses, we can create new addresses at any time as needed, and all these addresses will directly deposit funds into your wallet. In fact, many modern wallets automatically create a new address for each transaction to maximize privacy. A wallet is simply a collection of addresses and the keys to unlock the funds within them. First, we need to know how Bitcoin wallet addresses are generated.

Bitcoin Private Key and Public Key

Bitcoin uses the elliptic curve Secp256k1, where the "private key" is a random number between 1 and n−1, with n being a very large number (256 bits), approximately represented in scientific notation as:

This range is enormous, making it virtually impossible to guess someone else's private key. This random integer private key can be represented in 256 bits and exists in various encoding formats. If using WIF or WIF-compressed forms, the private key is unencrypted and can be decoded to obtain the original "random integer." Another method is BIP38, which proposes encrypting the private key using the AES algorithm, resulting in a private key starting with the characters 6P, which must be entered with a password to be imported into various Bitcoin wallets; this is the private key we commonly use.

Subsequently, we use the elliptic curve formula K = kG, where the private key k generates the Bitcoin public key K, and G is the Base Point, a parameter of secp256k1. We can obtain the two coordinates of K, which represent the public key in two forms: "Uncompressed format" and "Compressed format."

• Uncompressed format means directly concatenating the two coordinates x and y, with a 0x04 prefix added at the front;
• Compressed format means encoding as 02 x when y is even, and as 03 x when y is odd;

Bitcoin Addresses

The various types of Bitcoin addresses are shown in the following figure, with four representation methods:

Source: https://en.bitcoin.it/wiki/Invoice_address

1. Legacy (P2PKH) Format

Example: 1Fh7ajXabJBpZPZw8bjD3QU4CuQ3pRty9u

Addresses starting with "1" are the original Bitcoin address format, still in use today. They are derived from the public key through hash calculations and are also known as P2PKH, which stands for Pay To PubKey Hash.

2. Nested SegWit (P2SH) Format

Example: 3KF9nXowQ4asSGxRRzeiTpDjMuwM2nypAN

Addresses starting with "3" are abbreviated as P2SH, which stands for Pay To Script Hash. They support more complex functions than Legacy addresses. Nested P2SH obtains existing P2SH addresses (starting with "3") and encapsulates them with SegWit addresses.

3. Native SegWit (Bech32) Format

Example: bc1qf3uwcxaz779nxedw0wry89v9cjh9w2xylnmqc3

The address starting with bc1 was proposed in BIP0173; they are native Segregated Witness addresses. Bech32 encoded addresses are specifically designed for SegWit. Bech32 was defined in BIP173 at the end of 2017, and one of the main features of this format is that it is case-insensitive (the address only contains 0-9, a-z), effectively avoiding confusion during input and making it more readable. Since fewer characters are needed in the address, it uses Base32 encoding instead of traditional Base58, making calculations more convenient and efficient. Data can be stored more compactly in QR codes. Bech32 provides higher security and better optimizes checksum and error detection codes, minimizing the chances of invalid addresses.

Bech32 addresses are compatible with SegWit. There is no need for additional space to place SegWit addresses into P2SH addresses, so using Bech32 format addresses incurs lower fees. Bech32 addresses have several advantages over older Base58 addresses (Base58Check encoding is used to encode byte arrays in Bitcoin into human-readable strings): smaller QR codes; better error prevention; more secure; case-insensitive; consisting only of lowercase letters, making them easier to read, input, and understand.

4. Taproot Format (P2TR)

Bech32 has a drawback: if the last character of the address is p, inserting or deleting any number of characters q immediately before p will not invalidate its checksum.

To mitigate the above drawback of Bech32, BIP0350 proposed Bech32m addresses:

• For version 0 native Segregated Witness addresses, the previous Bech32 is used;
• For version 1 (or higher) native Segregated Witness addresses, the new Bech32m is used.

For Bech32m addresses, when the version is 1, they always start with bc1p (i.e., Taproot addresses). Specifically, just like native Segregated Witness, wallets can consist of seed phrases and password phrases. These are used to generate extended public and private keys for deriving addresses along arbitrary paths in hierarchical deterministic wallets. They are mainly used to store BRC-20 and BTC NFTs, among others.

V. About Us

Spectrum Labs is a team composed of master's and doctoral researchers focused on blockchain research, as well as seasoned professionals in the blockchain industry. We are dedicated to researching blockchain technology and its applications to help people better understand blockchain. Spectrum Labs' main business includes writing research reports, developing courses, and creating tools.

The BTC NFT Chinese Community is a BTC NFT Chinese communication platform created for newcomers among the global Chinese-speaking population.