Unveiling the Mysteries of Ordinal Inscriptions: A Comprehensive and In-Depth Popular Science Interpretation

With the creation of the Ordinal protocol, which provides the ability to number and inscribe bitcoins, it has broadened the range of products available to the bitcoin ecosystem and brought a new dynamic to the bitcoin ecosystem. In this article, we will dive into the details of the Ordinal protocol, including how each bitcoin is numbered and tracked, and how inscriptions relate to numbering. But before we dive into this topic, we need to first understand some basic background on Bitcoin to help us better understand what follows.

After completing this article, you will have mastered the transaction mechanism and payment model of Bitcoin, understand how Ordinals implements numbering and tracking for each satoshi, and how inscriptions are created and traded. In addition, you will understand the differences between different types of wallets.

I. Bitcoin Background

Bitcoin uses a cash-like transaction model, and its payments are based on a model called UTXO, which is different from the traditional account balance-based model. For example, in a bank account bookkeeping model process, when A transfers $100 to B, the bank records three steps that make up a transaction process. The first step is to debit $100 from A’s account, and the record ID for this step is tid1. The second step is to deposit $100 into B’s account, and the record ID for this step is tid2. The third step is to record a transfer record that associates tid1 with tid2, indicating that A’s account is reduced by $100 and B’s account is increased by $100. In this way, the transfer relationship between A and B is recorded and can be queried and traced in the future. Now, we will explain how Bitcoin payments are made by introducing for UTXO and the payment model.

UTXO

In the Bitcoin blockchain, all balances are stored in a list called the Unspent Transaction Output (UTXO). Each UTXO contains a certain number of bitcoins, along with information about the owner of those bitcoins, and indicates whether they are available. Think of it as a cash check signed with the holder’s name, which can be transferred to another person for use as long as the holder signs it. For a given address, all of its UTXO amounts add up to the balance of the wallet at that address. By traversing all UTXOs, we can obtain the current balance for each address. Adding up all the UTXO amounts adds up to the full amount of bitcoins currently in circulation.

In Bitcoin’s transaction structure, each transaction consists of several inputs and outputs, where each input is a reference to an existing UTXO, and each output specifies the new address where the funds will be received and the corresponding amount. Once a transaction is initiated, the UTXO referenced in its input section is temporarily locked to prevent reuse until the transaction is completed. Only when this transaction is successfully packed into a block by the miner and confirmed by the network, the associated UTXO status changes. Specifically, the UTXOs used as input to the transaction are removed from the UTXO list, indicating that they have been consumed, while the output of the transaction generates new UTXOs that are added to the UTXO list. It can be understood that the old cash checks are used and then expire, generating new cash checks whose ownership belongs to the new holder.

It is worth emphasizing that each UTXO can only be used once in a single transaction. Once it is consumed as an input, it is permanently removed from the UTXO list. At the same time, the newly generated output is added to the list as a new UTXO. the UTXO list is constantly changing, and as each new block is created, it is updated accordingly. And, by analyzing the transaction history in the blockchain, we are able to reconstruct the state of the UTXO list at any given point in time.

In addition, the total input amount of a transaction will usually slightly exceed its total output amount. This difference, called the Transaction fee or Network fee, is given as an incentive to the miners responsible for packing the transactions into blocks. The size of the network fee is proportional to the complexity of the transaction, so a transaction that contains more inputs and outputs will usually require a higher network fee.

Now, in order to understand the structure of Bitcoin transactions in a more visual way, we will go through a concrete example. The structure of a Bitcoin transaction is as follows, where the variables vin and vout represent the “input” and “output” of a Bitcoin transaction, respectively. Bitcoin transactions are not represented by inputs and outputs, unlike traditional account balance models that record account-shaped data changes.

const std::vector<CTxIn> vin;
const std::vector<CTxOut> vout;
const int32_t nVersion;
const uint32_t nLockTime;

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

We can pick a random transaction record at blockchain.com to analyze. The figure below shows a transaction with Hash ID 06270***345c2f2. It contains one input and two outputs.

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

{
    "version": 1,
    "locktime": 0,
    "vin": [
        {
            "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
            "vout": 0,
            "scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
            "sequence": 4294967295
        }
    ],
    "vout": [
        {
            "value": 0.01500000,
            "scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG"
        },
        {
            "value": 0.08450000,
            "scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
        }
    ]
}

In the Bitcoin network, the transaction output contains two important pieces of information: the address (public key hash) and the amount (in bitcoins). If the output of a transaction is not used in the input of other transactions, then this transaction output is called the unspent transaction output (UTXO). Whoever has the private key corresponding to the public key in the UTXO has the right to use or spend this UTXO.

Let’s look at the information in the “vin” in the code above, which indicates that the UTXO spent on this transaction came from another transaction (with the id 7957a3***999f6f18) of the 0th output (there can be more than one output of a transaction, the index is numbered from 0), we can find the amount of this UTXO from the history of transactions (for example, 0.1), so this The value 0.1 does not need to be explicitly written in the transaction, but is obtained by looking up the UTXO information. The “vout” of this transaction has two outputs, which are two new UTXOs, corresponding to the new balance and the holder, until another transaction consumes them as input.

Payment Model

To better understand the payment model of the Bitcoin network, we present an example of the payment process for a payment from A to B in the amount of n bitcoins. The following diagram shows the process of sending 3 bitcoins from user A to user B.

1. 1. For user A, it is first necessary to determine the set of all UTXOs it owns, i.e. all the bitcoins at user A’s disposal;
2. 2. A selects one or more UTXOs from this set as inputs to the transaction, and the sum of these inputs is m(2+0.8+0.5=3.3 BTC) to be greater than the amount to be paid, n(3 BTC);
3. 3. User A sets two outputs for the transaction, one output to pay to B’s address in the amount of n(3 BTC) and the other output to pay to one of A’s own change addresses in the amount of m-n-fee(3.3-3-0.001=0.299 BTC). (b) The user’s wallet usually consists of multiple addresses, each of which is normally used only once, and the change is returned to a new address by default;
4. 4. Waiting for the miner to package this transaction on the chain for confirmation, B can receive this transaction information. Because the block size has an upper limit (about 1 MB), miners will give priority to confirm transactions with high transaction rate (fee_rate=fee/size ) to get the highest fee return. We can see the real-time mining transaction fee at mempool. If we want the fastest confirmation during the transfer process, we can choose High Priority or customize a suitable transaction fee rate.

II. Satoshi’s Numbering and Tracking

The total number of bitcoins is 21 million, and each bitcoin contains 10^8 Satoshi (Sat). Thus, there are 21 million * 10^8 satoshi on the Bitcoin network. the Ordinals protocol distinguishes these satoshi by uniquely numbering each one. This section describes how the protocol does this, and how it keeps track of the accounts in which each satoshi is located. In addition, the rarity classification of the satoshi will be described.

Satoshi’s Numbering

According to the Ordinals protocol, satoshi are numbered according to the order in which they are mined. The following figure shows the representation of the 0th satoshi mined from the 0th block.

There are various representations for Ordinal numbers:

• Integer notation: 2099994106992659 The ordinal number, assigned according to the order in which the satoshi was mined.
• Decimal notation: 3891094.16797 The first number is the block height in which the satoshi was mined, the second the offset of the satoshi within the block.
• Degree notation: 3°111094′214″16797‴. The first number is cycle, numbered starting from 0, the second is the index of block in halving epoch, the third number is the index of block in difficulty adjustment period, and the last number is the index of sat in the block.

We will walk through an example of how to number the newly mined bitcoins. Looking at block 795952 of the bitcoin blockchain, we can see that the first of these transactions, Tx 3a1f…b177 records the miner’s reward (the coinbase transaction). This transaction contains newly mined bitcoin, which are used as a packaged reward for the miner, as well as a fee paid to the miner by the initiator of the transaction. By looking at the input of the diagram below, we can see that its UTXO id consists of a string of zeros and the block height. The output address is then the miner’s wallet address, and the amount is the sum of the rewards and fees mentioned above.

If we further look at the section of the output to the miners, we can see the distribution of addresses, amounts and the satoshi contained. As mentioned earlier, these contain the mining rewards and fees. Of these, the green sats number information 1941220000000000–1941220625000000 are the new satoshi generated by the mining reward, while the remaining 712 satoshi records correspond to all the fees in the block.

We can verify the number Sat 1941220000000000. Its block number is 795952 and the decimal is 795952.0, which means that the block height for mining this Satoshi is 795952, and Satoshi’s number in this block is 0, followed by the rarity mark for uncommon, which we will describe in detail in the later part.

Satoshi’s Flow

Because each BTC is generated through mining rewards, they are all traceable. Bitcoin accounts use the UTXO model. Let’s assume that user A has obtained the 100th-110th satoshi by mining (the 10 satoshi are stored as a whole in the same UTXO with id adc123). When user A wants to pay user B 5 satoshi, he chooses to use id abc123 as the input of the transaction, where 5 satoshi are given to user B and 5 satoshi are returned to user A as change. both copies of 5 satoshi are stored as a whole in two UTXOs with ids abc456 and abc789 respectively. The above UTXO ids and the number of satoshi are shown as examples only, in practice the minimum number is 546sats and the UTXO ids are not expressed in this form.

In the above transaction, the flow path of 10 satoshi of user A is

1. mining generates 10 satoshi with the number [100, 110). It means that the numbered 100th to 109th satoshi are stored in the UTXO with id abc123 and its owner is user A.
2. When A does the transfer, the 10 satoshi are divided into two parts, each with 5 satoshi. The “first-in-first-out” principle is used here, i.e., the numbering of the satoshi is determined by their index in the transaction output. Assuming that the order of the output is User A and then User B, then the remaining 5 satoshi of User A are numbered [100 , 105) and stored in the UTXO with id abc456, while the 5 satoshi of User B are numbered [105, 110) and stored in the UTXO with id abc789.

Rare Satoshi

As a derivative play of Ordinals protocol, the rarity of Satoshi can be defined based on the order in which they are mined. This will result in some special Satoshi having different rarities. The following are the rarity levels of different Satoshi:

• common: Any sat that is not the first sat of its block (Total supply: 2.1 quadrillion)
• uncommon: The first sat of each block (Total supply: 6,929,999)
• rare: The first sat of each difficulty adjustment period (Total supply: 3437)
• epic: The first sat of each halving epoch (Total supply: 32)
• legendary: The first sat of each cycle (Total supply: 5)
• mythic: The first sat of the genesis block (Total supply: 1)

This concept of rare satoshi can add more interest and value to the bitcoin ecosystem. Satoshi of different rarity may have different values in the market, attracting collectors and investors.

III. Inscription Method

Ordinals is significantly different from other NFTs on non-bitcoin chains. One of the main differences is that Ordinals’ metadata is not stored in a specific location. Instead, the metadata is embedded in the witness data of the transaction, which is why we call it an “inscription”, because it is “engraved” like an inscription on a specific part of the bitcoin transaction. The data is attached to a specific satoshi. This inscription process is implemented through Segregated Witness (SegWitness) and Pay-to-Taproot (P2TR), which consists of two phases: commit and reveal. It is possible to inscribe any kind of content (e.g. text, image or video) on a specified satoshi. We will introduce another more direct storage method, OP_RETURN, below and explain why it is not used as a means of inscription. Also, we will describe what isolated witness and Pay-to-Taproot are and what role they play in inscription. Finally we will introduce the way of inscriptions.

OP_RETURE

In Bitcoin Core client version 0.9, the compromise was finally achieved by adopting the RETURN operator. RETURN allows developers to add 80 bytes of non-payment data to the transaction output. Unlike pseudo-payments, RETURN creates an explicitly verifiable non-consumable output; such data does not need to be stored in the UTXO set. RETURN outputs are recorded on the blockchain, they consume disk space and cause the blockchain to increase in size, but they are not stored in the UTXO set and therefore do not inflate the UTXO memory pool, nor do they add to the expensive memory cost of the full node.

While OP_RETURN is a very straightforward means of storing information to the Bitcoin blockchain, it is also a potential means of inscription. However, OP_RETURN‘s limitations make it face some challenges when dealing with metadata storage. First, OP_RETURN can only store 80 bytes of data, a limitation that is clearly not met for cases where larger amounts of data need to be stored. Second, OP_RETURN data are stored in the transaction output section, and although such data are not stored in the UTXO set, they take up storage space in the blockchain, leading to an increase in the size of the blockchain. Finally, the use of OP_RETURN leads to an increase in transaction fees, as it requires more fees to be paid to post these transactions.

Segregated Witness

In contrast, SegWit offers a new approach that overcomes these problems. SegWit is a major protocol upgrade for Bitcoin, proposed by Pieter Wuille, a core Bitcoin developer, in 2015 and finally formally adopted in version 0.16.0 in 2017.Segregated in Segregated Witness means separated, isolated, and Witness is a signed thing associated with a transaction. Thus, SegWit is the separation of certain transaction signature data (witness data) from the transaction.

The main benefit of separating signature from transaction-related data is that it reduces the size of the data stored in a bitcoin block. This gives each block extra capacity to store more transactions, and means that the network can process more transactions and the sender pays lower fees. Technically speaking, this means taking the scriptSig information out of the base block and putting it in a new data structure. The Segwit upgrade introduces a new witness field in the transaction output to ensure privacy and performance. While the witness data is not designed for data storage, it actually gives us an opportunity to store content such as inscription metadata. Let’s understand segregated witnessing more graphically with the following diagram:

Taproot

P2TR is a transaction output type of Bitcoin that was introduced in the Taproot upgrade that took place in 2021, which allows different transaction conditions to be stored in the blockchain in a more private manner. P2TR plays a crucial role in Ordinals’ inscriptions. Inscriptions essentially embed specific data content into Bitcoin transactions, and the Taproot upgrade, and P2TR in particular, makes this embedded data more flexible and economical.

First, due to the way Taproot scripts are stored, we can store inscription content in Taproot script path spending scripts that are virtually unlimited in terms of content, while still receiving a discount on witness data, making it relatively economical to store inscription content. Since Taproot scripts can only be consumed from already existing Taproot output, inscriptions are submitted/revealed using a two-stage submission/reveal process. First, in the submit transaction, a Taproot output is created that promises a script containing the inscription content. Then, in the reveal transaction, the output created by the submit transaction is consumed, thus revealing the inscription content on the chain.

This approach significantly reduces the consumption of resources. If P2TR is not used, the witness information is stored in the output of the transaction. Thus, as long as this output is not consumed, the witness information will remain stored in the UTXO set. In contrast, if P2TR is used, the witness information does not appear in the transactions generated during the commit phase, so it is not written to the UTXO set. Only when this UTXO is consumed does the witness information appear in the transaction input during the reveal phase. p2tr allows metadata to be written to the bitcoin blockchain, but never appears in the UTXO set. Since maintaining/modifying the UTXO set requires more resources, this approach saves a lot of resources.

Inscriptions

The Ordinals protocol takes advantage of SegWit’s relaxation of size restrictions on writing to Bitcoin network content by storing inscription content in witness data. Taproot makes it easier to store arbitrary witness data in bitcoin transactions, allowing Ordinals developer Casey Rodarmor to reuse old opcodes (OP_FALSE, OP_IF, OP_PUSH) for what he describes as “envelopes” to store arbitrary data for what are called “inscriptions” .

The process of casting an inscription consists of the following two steps:

First, it is necessary to create a Commit-to-Taproot output of the script containing the content of the inscription in the submitted transaction. The format stored is Taproot, i.e. the output of the previous transaction is P2TR (Pay-To-Taproot) and the input of the latter transaction, with a specific format embedded in the witnessed Taproot script; first the string ord is put on the stack to disambiguate the inscription from having other uses. OP_PUSH 1 indicates that the next push contains the content type, and OP_PUSH 0 indicates that subsequent data pushes contain the content itself. Large inscriptions must use multiple data pushes because one of taproot’s few restrictions is that individual data pushes must not be larger than 520 bytes. At this point the data for the inscription already corresponds to the UTXO of the transaction output, but is not made public.

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

The text inscription containing the string “Hello, world!” is serialized as above

Second, it is necessary to consume that output created by submitting the transaction in the reveal transaction. At this stage, the transaction is initiated by taking as input the UTXO corresponding to that inscription. At this point, the content of its corresponding inscription is disclosed to the entire network.

With the two steps described above, the inscription content has been bound to the UTXO being inscribed. Again, according to the positioning of the satoshi described above, the inscription is made on the first satoshi corresponding to its input UTXO, and the inscription content is included in the input showing the transaction. According to the introduction to the flow and tracking of the satoshi described above, this satoshi inscribed with special content can be transferred, bought, sold, lost and restored. It should be noted that inscriptions cannot be repeated, otherwise the later inscriptions are invalid.

We will illustrate this process in detail by inscribing an example of a small BTC NFT image, which consists of the two main phases mentioned before, commit and reveal. First, we see that the Hash ID of the first transaction is 2ddf9…f585c. It can be noted that the output of this transaction does not contain witness data and there is no relevant inscription in the web page.

Next, we look at the second stage of the record, whose Hash ID is e7454…7c0e1. Here we can see the information of Ordinals inscription, which is the content of the witness inscription. The input address of this transaction is the output address of the previous one, while the output of 0.00000546BTC (546 Satoshi) sends this NFT to its own address. Also, we can find the satoshi where this inscription is located in Sat 1893640468329373.

In the Bitcoin wallet, we can see this asset. If we want to trade this NFT, we can send it directly to someone else’s address, which means sending this UTXO, which completes the flow of inscriptions.

IV. Bitcoin Wallet

After we understand what Ordinals is, the flow of Satoshi and the knowledge about inscriptions, there are many application scenarios that are currently emerging, be it BRC-20, ORC-20, BRC-721, GBRC-721 and other related derivative protocols that require us to have corresponding wallets to support and display out token information or NFT small images. In this section we will introduce the concept and characteristics of different bitcoin wallet addresses.

Bitcoin addresses start with 1, 3, or bc1. Just like email addresses, they can be shared with other Bitcoin users who can use them to send Bitcoins directly to their wallets. From a security perspective, a bitcoin address does not have any sensitive content. It can be published anywhere without compromising the security of the account. Unlike email addresses, we can create new addresses as often as needed, all of which will deposit funds directly into your wallet. In fact, many modern wallets automatically create a new address for each transaction for maximum privacy. A wallet is simply a collection of addresses and the keys to unlock the funds in them. First we need to know how the addresses of Bitcoin wallets are created.

Bitcoin Private and Public Keys

Bitcoin uses the elliptic curve Secp256k1, where the “private key” is a random number between 1 and n-1, n being a very large number (256 bits), and n being expressed in scientific notation as approximately 1.15792*10^77。The range is so large that it is almost impossible to guess anyone else’s private key. This random integer private key can be represented by 256 bits and there are many ways to encode it. If the private key in WIF, WIF-compressed form is unencrypted, it can be decoded to get the original “random integer”. Another way is BIP38, which proposes to encrypt the private key with AES algorithm. The private key obtained from this scheme starts with the character 6P, and this private key must be entered as a password to be imported into various bitcoin wallets, which is the private key we usually use.

We will then use the elliptic curve formula K = kG to generate the public key K of Bitcoin from the private key k. G is the Base Point, which is a parameter of secp256k1. The two coordinates of K are the two expressions of the public key, which are “Uncompressed format” and “Compressed format”.

• Uncompressed, which is a direct concatenation of two coordinates x and y, preceded by a 0x04 prefix;
• Compressed form, which is coded as 02 x, when y is even and 03 x when y is odd;

Bitcoin Addresses

The various types of bitcoin addresses can be shown in the following diagram, with four representations:

1. Legacy (P2PKH) Format

Example: 1Fh7ajXabJBpZPZw8bjD3QU4CuQ3pRty9u

The address starts with a “1” and is the original address format for Bitcoin, which is still in use today. It is also known as P2PKH, which stands for Pay To PubKey Hash, and is obtained by computing the public key through a hash.

2. Nested SegWit (P2SH) Format

Example: 3KF9nXowQ4asSGxRRzeiTpDjMuwM2nypAN

Nested P2SH, which takes an existing P2SH address (starting with “3”) and wraps it with a SegWit address.

3. Native SegWit (Bech32) Format

Example: bc1qf3uwcxaz779nxedw0wry89v9cjh9w2xylnmqc3

Addresses starting with bc1 are proposed in BIP0173, and they are native Isolated Witness addresses. bech32 encoded addresses, an address format developed specifically for SegWit. bech32 was defined in BIP173 in late 2017, and one of the main features of the format One of the main features is that it is case-insensitive (only 0-9, az, are included in the address), making it effective in avoiding confusion and more readable when entered. Because fewer characters are needed in the address, the address is encoded using Base32 instead of the traditional Base58, making computation easier and more efficient. Data can be stored more tightly in the QR code. bech32 provides higher security, better optimization of checksum and error detection codes, and minimizes the chance of invalid addresses.

Bech32 addresses themselves are compatible with SegWit. No extra space is needed to put SegWit addresses into P2SH addresses, so fees are lower with Bech32 format addresses. Bech32 addresses have several advantages over older Base58 (Base58Check encoding is used to encode byte arrays in Bitcoin into human-encodable strings) addresses: smaller QR codes; better error-proofing; more secure; is not case sensitive; and consists of only lowercase letters, so it is easier to read, type, 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 alleviate this drawback of Bech32, the Bech32m address is proposed in BIP0350:

• For a version 0 native isolated witness address, use the previous Bech32;
• For a version 1 (or higher) native isolated witness address, the new Bech32m is used.

For Bech32m addresses, they always start with bc1p (i.e. Taproot address) when version 1 is used. Specifically, like a local isolated witness, a wallet can consist of a seed phrase and a cryptographic phrase. These are used to generate extended public and private keys that are used to derive arbitrary path addresses in a hierarchical deterministic wallet. The main purpose is to store BRC-20 as well as NFTs for BTC, etc.

Source: Spectrum Lab