Author: Ash Li, Noah Ho

Source: Spectrum Lab

I. Background of Bitcoin

Bitcoin adopts a transaction model similar to cash, with its payment method based on a model called UTXO, which is different from the traditional balance-based model. For example: in the account bookkeeping model of a bank, 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 as tid1. The second step is to deposit 100 yuan into B's account, with the record ID as tid2. The third step is to record a transfer, which associates tid1 and tid2, indicating that A's account decreases by 100 yuan and B's account increases 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 the payment method of Bitcoin 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 bitcoins, the owner's information, and indicates whether it is available. It can be imagined as a cash check with the owner's name, which can be transferred to others as long as the owner signs on it. For a specific address, the total amount of all its UTXOs is the balance of the address's wallet. By traversing all UTXOs, we can obtain the current balance of each address. The sum of all UTXO amounts represents the current total circulation of bitcoins.

In the transaction structure of Bitcoin, each transaction includes several inputs and outputs, where each input refers to an existing UTXO, and each output specifies a new fund receiving address and the corresponding amount. Once a transaction is initiated, the inputs part referring to UTXOs will be temporarily locked to prevent duplicate usage before the transaction is completed. Only when this transaction is successfully packaged into a block by miners and receives network confirmation, the status of the related UTXOs will change. Specifically, the UTXOs used for transaction inputs will be removed from the UTXO list, indicating that they have been spent, and the transaction outputs will generate new UTXOs and add them to the UTXO list. It can be understood that old cash checks become invalid after use, generating new cash checks owned by new holders.

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

Additionally, the total input amount of a transaction usually slightly exceeds its total output amount. This difference, called the transaction fee or network fee, serves as an incentive for miners responsible for packaging the transaction into blocks. The size of the network fee is proportional to the complexity of the transaction, so a transaction with more inputs and outputs usually needs to pay a higher network fee.

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

const std::vectorCTxIn> vin;const std::vectorCTxOut> vout;const int32_t nVersion;const uint32_t nLockTime;

We can analyze a random transaction record on blockchain.com. The following image shows a transaction with Hash ID 0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2, which includes one input and two outputs.

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

{    "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, transaction outputs contain two important pieces of information: the address (public key hash) and the amount (in bitcoins). If an output of a transaction is not used in the inputs of other transactions, then this transaction output is called an Unspent Transaction Output (UTXO). Whoever owns the private key corresponding to the public key in the UTXO has the right to use (spend) this UTXO.

Let's take a look at the information in the "vin" in the above code, which indicates that the UTXO spent in this transaction comes from another transaction (with id 7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18) and its 0th output (a transaction's output can have multiple, indexed from 0). We can find the amount of this UTXO (e.g., 0.1) from historical transactions, so the user spent 0.1 BTC in this transaction. The value 0.1 does not need to be explicitly written in the transaction; it is obtained by looking up UTXO information. This transaction's "vout" has two outputs, creating two new UTXOs, corresponding to new balances and holders, until they are spent as inputs in another transaction.

Payment Model

To better understand the payment model of the Bitcoin network, let's go through an example of A paying n bitcoins to B. The image below shows the process of user A sending 3 bitcoins to user B.

1. For user A, it is necessary to determine the collection of all UTXOs owned by them, i.e., all the bitcoins user A can spend;
2. A selects one or more UTXOs from this collection as inputs for the transaction, where the sum of these inputs' amounts is m (2+0.8+0.5=3.3 BTC), which must be greater than the amount n to be paid (3 BTC);
3. User A sets two outputs for the transaction: one output pays to B's address, with an amount of n (3 BTC), and the other output pays to A's own change address, with an amount of m-n-fee (3.3-3-0.001=0.299 BTC). A user's wallet typically consists of multiple addresses, and in general, each address is used only once, with the change defaulting to a new address;
4. After miners package and confirm this transaction on the blockchain, B can receive the transaction information. Because the block has a size limit (about 1 MB), miners will prioritize confirming transactions with a high transaction fee rate (fee_rate=fee/size) to get the highest fee return. We can see real-time mining transaction fee information on mempool. If we want the fastest confirmation during the transfer process, we can choose a high priority or customize an appropriate transaction fee rate;

II. Numbering and Tracking of Satoshis

The total amount of bitcoins is 21 million, and each bitcoin contains 10^8 satoshis (Satoshi, Sat). Therefore, there are a total of 21 million * 10^8 satoshis on the Bitcoin network. The Ordinals protocol distinguishes these satoshis and assigns a unique number to each satoshi. This section will explain how this protocol uniquely numbers each satoshi and how to track its account. In addition, it will also briefly introduce the rarity and classification of satoshis.

Numbering of Satoshis

According to the Ordinals protocol, the numbering of satoshis is based on the order in which they are mined. The image below shows the representation of the 0th satoshi mined from the 0th block.

There are multiple ways to express satoshis:

• Integer symbol: For example, 2099994106992659, represents the sequence number assigned to the satoshi according to the mining order.
• Decimal symbol: For example, 3891094.16797, where the first number represents the block height at which the satoshi was mined, and the second number represents the satoshi's number within the block.
• Degree symbol: For example, 3°111094′214″16797‴, where the first number is the cycle, numbered from 0, the second number is the block index of the halving epoch, the third number is the block index during the difficulty adjustment period, and the last number is the satoshi index in the block.
• Percentage symbol: For example, 99.99971949060254%, represents the position of the 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. By 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 includes newly mined bitcoins, which are the miner's block reward and the transaction initiator's fee paid to the miner. By looking at the inputs in the image below, we can see that the UTXO id is composed of a string of 0s and the block height. The output address is the miner's wallet address, and the amount is the sum of the reward and fee mentioned above.

If we further examine the part of the output given to the miner, we can see the address, amount, and the distribution of satoshis. As mentioned earlier, these include the mining reward and fees. The green satoshi numbering information 1941220000000000–1941220625000000 represents the new satoshis generated as mining rewards, and the remaining 712 satoshis correspond to all the fees in that block.

We can verify the numbering of Sat 1941220000000000. Its block number is 795952, and the decimal symbol is 795952.0, indicating that the block height at which the satoshi was mined is 795952, and the satoshi's number in this block is 0. The rarity marking is "uncommon," which we will detail in the following section.

Circulation of Satoshis

Because every BTC is generated through mining rewards, they are all traceable. Bitcoin accounts use the UTXO model. For example, if user A obtains the 100th to 110th satoshis through mining (10 satoshis are collectively stored in a UTXO with the id adc123), when user A wants to pay 5 satoshis to user B, they choose to use the id abc123 as the input for the transaction. 5 satoshis are given to user B, and 5 satoshis are returned to user A as change. Both sets of 5 satoshis are collectively stored in two UTXOs with the ids abc456 and abc789. The UTXO ids and the number of satoshis mentioned above are for illustration purposes only. In actual cases, the minimum limit for sending satoshis is 546, and UTXO ids are not expressed in this form.

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

1. 10 satoshis are generated through mining, with the numbers ranging from [100 *, 110). The * indicates that the satoshis numbered from the 100th to the 109th are stored in the UTXO with the id abc123, owned by user A.

2. When A makes the transfer, the 10 satoshis are split into two sets of 5 satoshis each. The "first in, first out" principle is used here, meaning that the ordering of the satoshis is determined by their index in the transaction output. Assuming the order is user A first, then user B, the remaining 5 satoshis for user A have numbers ranging from [100, 105), stored in the UTXO with the id abc456, while the 5 satoshis for user B have numbers ranging from [105, 110), stored in the UTXO with the id abc789.

Rarity of Satoshis

As a derivative of the Ordinals protocol, the rarity of satoshis can be defined based on the order in which they are mined, resulting in some special satoshis having different levels of rarity. The different levels of rarity for satoshis are:

• common: Common level, any satoshi except the first one in a block (total supply of 21 trillion)
• uncommon: Excellent level, the first satoshi in each block (total supply of 6,929,999)
• rare: Rare level, the first satoshi in each difficulty adjustment period (total supply of 3,437)
• epic: Epic level, the first satoshi after each halving (total supply of 32)
• legendary: Legendary level, the first satoshi in each cycle (total supply of 5)
• mythic: Mythical level, the first satoshi in 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.

III. Inscription Method

Ordinals is significantly different from other NFTs on non-Bitcoin blockchains. 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 transactions, which is why we call it "inscription." This data is "engraved" in a specific part of Bitcoin transactions, 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: commitment and reveal, and can engrave any form of content, such as text, images, or videos, on specific satoshis. We will also introduce another more direct storage method, OP_RETURN, and explain why it is not used as a means of inscription. Additionally, we will explain what Segregated Witness and Pay-to-Taproot are and the roles they play in the inscription. Finally, we will introduce the inscription method.

OP_RETURN

In the Bitcoin Core client version 0.9, a compromise was eventually reached by adopting the RETURN opcode. **RETURN allows developers to add 80 bytes of non-payment data to transaction outputs.** Unlike pseudo-payments, RETURN creates a clear, verifiable, non-spendable output, and this type of data does not need to be stored in the UTXO set. RETURN outputs are recorded on the blockchain, consuming disk space and increasing the size of the blockchain, but they are not stored in the UTXO set, so they do not cause UTXO memory pool inflation or increase the expensive memory cost of full nodes.

Although OP_RETURN is a very direct means of storing information on the Bitcoin blockchain, it is also a potential means of inscription. However, the limitations of OP_RETURN pose some challenges when dealing with metadata storage. Firstly, OP_RETURN can only store 80 bytes of data, which is clearly insufficient for cases requiring larger data storage. Secondly, OP_RETURN data is stored in the transaction outputs, and while this data is not stored in the UTXO set, it occupies storage space on the blockchain, leading to an increase in the size of the blockchain. Finally, using OP_RETURN can lead to higher transaction fees, as it requires more fees to publish these transactions.

Segregated Witness

In contrast, the new method provided by SegWit can overcome the above issues. SegWit is a significant protocol upgrade for Bitcoin, proposed by Bitcoin Core developer Pieter Wuille in 2015 and formally adopted in version 0.16.0 in 2017. Segregated Witness, where "segregated" means separated and "witness" refers to transaction-related signature data, separates some transaction signature data (witness data) from the transaction.

The main benefit of separating signatures from transaction-related data is the reduction in the size of data stored in a Bitcoin block. This gives each block additional capacity to store more transactions, meaning the network can process more transactions, and senders pay lower fees. Technically, it involves taking the script signature (scriptSig) information out of the base block and putting it into a new data structure. Nodes and miners that perform verification also verify the script signature in this new data structure to ensure the validity of the transaction. The SegWit upgrade introduces a new witness field in transaction outputs to ensure privacy and performance. Although witness data is not designed for data storage, it actually provides an opportunity to store inscription metadata and other content. We can better understand Segregated Witness through the image below:

Taproot

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

Firstly, due to the storage method of Taproot scripts, we can store inscription content in the Taproot script path spending script, which has almost no restrictions on content and also receives a discount on witness data, making the storage of inscription content relatively economical. Since Taproot script spending can only be done from existing Taproot outputs, the inscription adopts a two-stage commitment/reveal process. First, in the commitment transaction, a Taproot output containing the inscription content script is created. Then, in the reveal transaction, the output created by the commitment transaction is spent, thereby revealing the inscription content on the chain.

This approach greatly reduces resource consumption. If P2TR is not used, witness information will be stored in the transaction outputs. As long as this output is not spent, the witness information will continue to be stored in the UTXO set. In contrast, if P2TR is used, the witness information will not appear in the transactions created in the commitment phase, and therefore it will not be written into the UTXO set. The witness information will only appear in the transaction inputs in the reveal phase when this UTXO is spent. P2TR allows metadata to be written to 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 limit for writing content to the Bitcoin network and stores inscription content in the witness data, allowing it to store metadata of up to 4MB. 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, known as "inscriptions."

The process of inscribing an inscription includes the following two steps:

1. First, a commitment to a script containing the inscription content is created in the Taproot output of the commitment transaction. The format stored is Taproot, where the output of the previous transaction is P2TR (Pay-To-Taproot), and the input of the subsequent transaction embeds specific formatted content in the Taproot script of the witness. The string ord is first pushed onto the stack to eliminate ambiguity about the purpose of the inscription. OP_PUSH 1 indicates the next push contains the content type, and OP_PUSH 0 indicates the subsequent data push contains the content itself. Large inscriptions must use multiple data pushes, as one of the few 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 publicly revealed.
2. Secondly, the output created by the commitment transaction needs to be spent in the reveal transaction. In this phase, a transaction is initiated by using the UTXO corresponding to that inscription as input. At this point, the corresponding inscription content is publicly revealed to the entire network.

Through the above two steps, the inscription content is now bound to the UTXO being inscribed. Based on the positioning of the satoshis as described earlier, the inscription is performed on the first satoshi corresponding to its input UTXO, and the inscription content is included in the input of the revealing transaction. Based on the tracking of satoshis as described earlier, the satoshi with the special content inscription can be transferred, purchased, sold, lost, and recovered. It is important to note that inscriptions cannot be repeated, otherwise subsequent inscriptions are invalid.

We will illustrate this process in detail by inscribing a BTC NFT small image, which mainly includes the commitment and reveal phases mentioned earlier. 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 related inscription information on the webpage.

Next, we look at the record of the second phase, with the hash ID e7454...7c0e1. Here, we can see the Ordinals inscription information, which is the inscription witness data. The input address of this transaction is the output address of the previous transaction, and the output of 0.00000546 BTC (546 satoshis) is sending this NFT to its own address. At the same time, we can also find this inscription in Sat 1893640468329373.

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

IV. Bitcoin Wallet

After understanding the Ordinals ecosystem, the circulation of satoshis, and the relevant knowledge of inscriptions, there are currently many application scenarios, whether it is the emergence of derivative protocols such as BRC-20, ORC-20, BRC-721, GBRC-721, etc., which require corresponding wallets to support and display 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. 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 do not contain any sensitive information. They can be published anywhere without compromising the security of the account. Unlike email addresses, we can create new addresses as needed, and all of 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 understand how Bitcoin wallet addresses are generated.

Bitcoin Private Key and Public Key

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

This range is extremely large, making it almost impossible to guess someone else's private key. This random integer private key can be represented with 256 bits and exists in multiple 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 with the AES algorithm. Private keys obtained using this method start with the characters 6P and must be imported into various Bitcoin wallets with a password, which is the private key we commonly use.

Later, we will use the elliptic curve formula K = kG to generate the public key K from the private key k, where G is the Base Point, a parameter of secp256k1. This yields two coordinates for K, representing the public key in two formats: "Uncompressed format" and "Compressed format."

• In the Uncompressed format, the two coordinates x and y are directly concatenated, with a 0x04 prefix added in front;
• In the Compressed format, when y is even, it is encoded as 02x, and when y is odd, it is encoded as 03x;

Bitcoin Addresses

Various types of Bitcoin addresses are illustrated in the following image, with four representation methods:

Reference: 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 calculation 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 P2SH, which stands for Pay To Script Hash. It supports more complex functionality than Legacy addresses. Nested P2SH involves encapsulating existing P2SH addresses (starting with "3") with SegWit addresses.

3. Native SegWit (Bech32) Format

Example: bc1qf3uwcxaz779nxedw0wry89v9cjh9w2xylnmqc3

The addresses starting with "bc1" proposed in BIP0173 are native SegWit addresses. Bech32-encoded addresses are a format developed specifically for SegWit. Bech32, defined in BIP173 at the end of 2017, is characterized by being case-insensitive (containing only 0-9, az), effectively avoiding confusion and being more readable when entered. With fewer characters required in the address, Base32 encoding is used instead of traditional Base58, making calculations more convenient and efficient. Data can be stored more densely in QR codes. Bech32 provides higher security, better optimized validation, and error detection code, minimizing the chance of invalid addresses.

Bech32 addresses are compatible with SegWit. Using Bech32 format addresses results in lower fees, as there is no need for additional space to place SegWit addresses in P2SH addresses. Bech32 addresses have several advantages over old Base58 (Base58Check encoding used to encode byte arrays in Bitcoin into human-readable strings): smaller QR codes, better error prevention, increased security, case insensitivity, and consisting only of lowercase letters, making them easier to read, enter, and understand.

4. Taproot Format (P2TR)

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

To address the above drawback of Bech32, Bech32m addresses were proposed in BIP0350:

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

For Bech32m addresses, when the version is 1, they always start with bc1p (i.e., Taproot addresses). Specifically, like native SegWit, wallets can be composed of seed phrases and passphrase. These are used to generate extended public and private keys for deriving addresses on arbitrary paths in hierarchical deterministic wallets. This is mainly used for storing BRC-20 and BTC NFTs.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。