1. Bitcoin Background
Bitcoin uses a cash-like transaction model (cash system), and its payment method is based on a model called UTXO, which is different from the traditional account balance-based model.
For example, in the bank's account accounting model process, when A transfers 100 yuan to B, the bank will record three steps, which constitute a transaction process. The first step is to deduct 100 yuan from A's account, and the record ID of this step is tid1. The second step is to deposit 100 yuan into B's account, and the record ID of this step is tid2. The third step is to record a transfer record, 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 the introduction of UTXO and payment model.
UTXO
In the Bitcoin blockchain, all balances are stored in a list called "Unspent Transaction Outputs" (UTXO). Each UTXO contains a certain amount of Bitcoin, owner information, and availability status, similar to a check with the holder's name. This check can be signed and transferred to other people.
The balance of an address is equal to the sum of all its UTXOs. The current balance of each address can be obtained by traversing the UTXO list. At the same time, the sum of these UTXOs represents the total supply of all bitcoins at present.
In the Bitcoin transaction structure, each transaction contains inputs and outputs. Each input is a reference to an existing UTXO, while each output specifies a new receiving address and amount. Once a transaction is created, the UTXO associated with the input will be temporarily locked to prevent reuse. The status of the related UTXO will only change after it is successfully packaged and confirmed by the miners.
Specifically, the input UTXO is removed, and the output generates a new UTXO and adds it to the list. This is similar to generating a new check after the old check expires, and the ownership of the new check is transferred to the new holder.
It is important to emphasize that each UTXO can only be used once in a transaction, and is permanently removed after use, while new outputs are created and added to the UTXO list. As new blocks are created, the UTXO list is constantly updated. By analyzing the transaction history, the state of the UTXO list at any given point in time can be reconstructed.
In addition, the total input amount of a transaction usually slightly exceeds the total output amount, and this difference becomes the transaction fee as an incentive for K workers. Transaction fees are proportional to transaction complexity, so a transaction with more inputs and outputs usually requires a higher network fee.
To better understand the structure of Bitcoin transactions, we can use the following example to gain a deeper understanding, where "vin" represents the input of the transaction and "vout" represents the output of the transaction. Bitcoin transactions use the input and output approach rather than the traditional account balance model.
We can randomly select a transaction record on blockchain.com to analyze. The following figure shows the Hash ID
The transaction is 0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2. It contains one input and two outputs.
By using the bitcoin-cli commands getrawtransaction and decoderawtransaction, we can inspect the underlying structure of the above transaction:
In the Bitcoin network, each transaction output contains two key pieces of information: the address (public key hash) and the amount (in Bitcoins).
If the output of a transaction has not been used in the input of other transactions, then this output is called an unspent transaction output (UTXO). The person who has the private key corresponding to the public key in the UTXO has the right to use (i.e. spend) this UTXO.
Let's take a look at the information in "vin" in the above code. It indicates that the UTXO spent by this transaction comes from the 0th output (a transaction can have multiple outputs, and the index starts at 0) of another transaction (whose id is 7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18).
We can find the amount of this UTXO (for example, 0.1 bitcoin) from the transaction history. Therefore, in this transaction, the user spent 0.1 bitcoin, and the value 0.1 does not need to be explicitly written in the transaction, but is obtained by querying the UTXO information.
The "vout" of this transaction contains two outputs, which represent two new UTXOs, corresponding to the new balance and owner. These new UTXOs will exist until another transaction consumes them as input.
Payment Model
In order to better understand the payment model of the Bitcoin network, we use an example to introduce the payment process of n bitcoins paid by A to B. The figure below shows the process of user A sending 3 bitcoins to user B.
For user A, first you need to determine all the UTXO sets he owns, that is, all the bitcoins that user A can control;
A selects one or more UTXOs from this set as transaction inputs. The sum of the amounts of these inputs is m (2+0.8+0.5=3.3 BTC), which is greater than the amount to be paid n (3 BTC).
User A sets two outputs for the transaction, one output is paid to B's address, the amount is n (3 BTC), and the other output is paid to A's own change address, the amount is mn-fee (3.3-3-0.001 = 0.299 BTC). The user's wallet usually consists of multiple addresses, and generally each address is only used once, and the change is preset to be returned to a new address;
Once worker K packages and confirms the transaction on the blockchain, the recipient B will be able to obtain information about the transaction.
Since the size of each block is limited (usually about 1 MB), K workers give priority to confirming transactions with high transaction fees (fee_rate=fee/size) to obtain the highest fee returns.
We can view the mining K transaction fee rate in real time in the unconfirmed transaction pool (mempool). If we want to get confirmation as soon as possible during the transfer process, we can choose High Priority or customize a suitable transaction fee rate.
2. Numbering and Tracking of Satoshi
The total supply of Bitcoin is 21 million, and each Bitcoin contains 10^8 Satoshis (Sat). Therefore, in the Bitcoin network, we have a total of 21 million * 10^8 Satoshis.
The Ordinals protocol uses a unique way to number each satoshi to ensure its uniqueness and accurately track the account they belong to. In addition, it also indirectly classifies the rarity of satoshis.
Satoshi's number
According to the Ordinals protocol, Satoshis are numbered according to the order in which they are mined. The following figure shows how the 0th Satoshi mined in the 0th block is represented.
There are many ways to express Cong:
Integer symbol: For example, 2099994106992659, which indicates the serial number assigned to the satoshi in the order of mining.
Decimal notation: For example, 3891094.16797, the first digit indicates the height of the block where the satoshi was mined, and the second digit indicates the number of the satoshi in the block.
Degree notation: For example, 3°111094′214″16797‴, the first digit is the period, numbered from 0, the second digit is the block index of the halving epoch, the third digit is the block index of the difficulty adjustment period, and the last digit is the index of sats in the block.
Percent symbol: For example, 99.99971949060254%, which indicates the position of the satoshi in the Bitcoin supply, expressed as a percentage.
Name: For example, Satoshi. A name that encodes a serial number using characters a to z.
Let's take an example to explain how to number newly mined bitcoins. Observe the 795952th block of the Bitcoin blockchain, which contains a transaction named "Tx 3a1f...b177", which records the reward of K worker (coinbase transaction). This transaction includes newly mined bitcoins, which are rewards for K worker, as well as the handling fee paid by the transaction initiator to K worker.
By looking at the input part, we can see the UTXO ID, which consists of a string of 0s and the height of the block. In the output part, we can see the addresses that receive these rewards and fees, as well as their total amount.
If we look further at the outputs to K workers, we can see the addresses, amounts, and distribution of the Satoshis included. As mentioned before, these include the K mining rewards and handling fees.
Among them, the green sats number information 1941220000000000–1941220625000000 are the new Satoshis generated by mining K rewards, and the remaining 712 Satoshi records correspond to all the transaction fees in the block.
We can verify the number Sat 1941220000000000.
Its block number is 795952, and its decimal notation is 795952.0, which means that the block height of the satoshi is 795952, and the satoshi in this block is numbered 0. The rarity is marked as uncommon, which we will explain in detail in the following section.
The Circulation of Satoshi
Bitcoin's transaction model uses the Unspent Transaction Output (UTXO) model, which means that each Bitcoin (BTC) can be traced back to its source. Let's use an example to illustrate this process:
Assume that user A gets a reward by mining K, which includes bitcoins from the 100th to the 110th satoshi. These bitcoins are stored in the same UTXO (Unspent Transaction Output), whose ID is adc123.
Now, when user A wants to pay user B 5 satoshis, he chooses to use the UTXO with ID abc123 as the input of the transaction. This transaction will send 5 satoshis to user B and return 5 satoshis to user A as change.
Both 5 satoshis will become a whole, but will be stored in two different UTXOs, such as abc456 and abc789.
The above UTXO id and number of Satoshis are only shown as examples. In practice, the minimum number of Satoshis sent is 546 and the UTXO id is not expressed in this form.
In the above transaction, the flow path of user A’s 10 satoshis is:
Mining K generates 10 satoshis, numbered [100, 110). This means that the 100th to 109th satoshis are stored in the UTXO with id abc123, and its owner is user A.
When A makes a transfer, 10 satoshis are divided into two parts, each with 5 satoshis. The principle of "first in, first out" is adopted here, that is, the order of the satoshi numbers is determined by their index in the transaction output.
Assuming the output order is user A first and then user B, the sequence number of user A's remaining 5 satoshis is [100, 105), stored in the UTXO with id abc456, and the sequence number of user B's 5 satoshis is [105, 110), stored in the UTXO with id abc789.
Rare Satoshi
As a spin-off of the Ordinals protocol, the rarity of Satoshi can be defined based on the order in which they are mined. This will result in some special Satoshis having different rarities. Here are the rarity levels of different Satoshis:
Common: Any Satoshi except the first Satoshi in a block (total supply is 2100 trillion)
uncommon Premium: The first satoshi of each block (total supply is 6,929,999)
Rare: The first satoshi of each difficulty adjustment period (total supply is 3437)
epic: The first satoshi after each halving (total supply is 32)
Legendary: First Satoshi of each cycle (total supply is 5)
mythic: The first Satoshi in the genesis block (total supply is 1)
This concept of rare satoshis can add more interest and value to the Bitcoin ecosystem. Satoshis of different rarities may have different values in the market, attracting collectors and investors.
3. Inscription Method
One significant difference between Ordinals and other non-Bitcoin chain NFTs is that their metadata is not stored in a specific location.
Instead, this metadata is embedded in the witness data (witness field) of the transaction, which is why we call it an “inscription” because this data is “engraved” on a specific part of a Bitcoin transaction like an inscription, and this data is attached to a specific Satoshi.
This inscription process is achieved through Segregated Witness (SegWit) and "Pay-to-Taproot" (P2TR), which includes two stages: commit and reveal. Any form of content (such as text, images or videos) can be inscribed on the specified satoshi.
Next, we will detail another more direct storage method, OP_RETURN, and explain why it is not suitable for inscriptions. At the same time, we will explore the concepts of segregated witness and Pay-to-Taproot, and their role in inscriptions. Finally, we will take a deep dive into the inscription method.
OP_RETURE
In version 0.9 of the Bitcoin Core client, a compromise was finally reached with the RETURN operator. RETURN allows developers to add 80 bytes of non-payment data to transaction outputs. Unlike pseudo-payments, RETURN creates an explicitly verifiable but unspendable output that does not need to be stored in the UTXO (unspent transaction output) collection.
RETURN outputs are recorded on the blockchain, which will take up disk space and cause the blockchain size to increase, but they do not occupy the UTXO set, so they will not cause the UTXO set to swell, nor will they increase the expensive memory costs of full nodes.
Although OP_RETURN is a way to store information directly on the Bitcoin blockchain, it also has some challenges. First, OP_RETURN can only store 80 bytes of data, which is obviously not enough for situations where more data needs to be stored.
Secondly, OP_RETURN data are stored in transaction outputs. Although they do not occupy the UTXO set, they occupy the storage space of the blockchain, causing the blockchain size to increase.
Finally, using OP_RETURN increases transaction fees because it requires paying more to publish these transactions.
Segregated Witness
Compared with previous methods, SegWit provides a new solution to solve the above problems.
SegWit is a key protocol upgrade for Bitcoin, first proposed by Bitcoin core developer Pieter Wuille in 2015 and finally adopted in version 0.16.0 in 2017.
The "Segregated" in Segregated Witness (SegWit) means separation or isolation, while "Witness" refers to the signature data associated with the transaction. Therefore, the core concept of SegWit is to separate certain transaction signature data (also called witness data) from the actual transaction data.
The main benefit of separating signature data from transaction data is that it reduces the size of data stored in Bitcoin blocks. This allows each block to have more available capacity to accommodate more transactions, which also means that the network can process more transactions and users pay lower transaction fees.
Technically, this means moving the script signature data (scriptSig) originally included in the basic block structure to a new data structure. Validation nodes and K workers will also verify the script signature in this new data structure to ensure the validity of the transaction.
The SegWit upgrade also introduces a new witness data field to enhance privacy and efficiency. Although witness data is not specifically used to store plaintext transaction data, it actually gives us an opportunity to store content such as inscription metadata.
Let’s use the following diagram to better understand segregated witness:
Taproot
P2TR is a type of Bitcoin transaction output introduced in the 2021 Taproot upgrade that allows different transaction conditions to be stored more privately on the blockchain.
In this architecture, P2TR plays a vital role in Ordinals’ data inscription. Inscription is actually embedding specific data into Bitcoin transactions, and the Taproot upgrade, especially P2TR, makes this data embedding more flexible and economical.
Firstly, because of the way Taproot instruction codes are stored, we can store inscription data in the Taproot instruction path with almost no restrictions on the content of these instruction codes, while enjoying the discount of witness materials, making it relatively economical to store inscription data.
However, since the consumption of Taproot instructions can only come from existing Taproot outputs, the storage of inscriptions adopts a two-phase commit/reveal process. First, in the commit transaction, a Taproot output is created that commits to contain the inscription data.
Then, in the reveal transaction, the output established by the commit transaction is consumed, revealing the inscription contents on-chain.
This approach greatly reduces resource usage. Without P2TR, the witness data will be stored in the transaction output, and as long as the output is not consumed, the witness data will always exist in the UTXO set.
In contrast, if P2TR is used, the witness data will not appear in the transaction generated in the commit phase, and therefore will not be written to the UTXO set. Only when the UTXO is consumed will the witness data appear in the transaction input in the reveal phase.
P2TR allows raw data to be written to the Bitcoin blockchain without occupying space in the UTXO set. Since maintaining/modifying the UTXO set requires more resources, this approach can save a lot of resources.
Inscription
The Ordinals protocol expands the size limit of content written to the Bitcoin network by using SegWit, storing the plaintext content in the witness material, allowing up to 4MB of metadata storage.
Taproot simplifies the process of storing arbitrary witness data in Bitcoin transactions, allowing Ordinals developer Casey Rodarmor to repurpose old opcodes (OP_FALSE, OP_IF, OP_PUSH) to create so-called “envelopes” for storing arbitrary data called “inscriptions.”
The casting process of the inscription includes the following two steps:
First, in the submission transaction, a commitment pointing to the Taproot output containing the inscription content needs to be created. The storage format is Taproot, and the output of the previous transaction must be P2TR (Pay-To-Taproot), and the content in a specific format must be embedded in the Taproot witness script.
First, the string "ordn" is pushed onto the stack to disambiguate the purpose of the inscription. Then, OP_PUSH 1 is used to indicate that the next push contains the content type, and OP_PUSH 0 is used to indicate that the subsequent data push contains the content itself.
Since one of the limitations of Taproot is that a single data push cannot exceed 520 bytes, multiple data pushes are required to store large inscriptions. At this time, the inscription data has been associated with the unspent transaction output (UTXO) of the transaction output, but it has not yet been made public.
Secondly, in the reveal transaction, the output created needs to be consumed. In this phase, the transaction is initiated by taking the UTXO corresponding to the inscription as input. At this point, the content of the inscription associated with that UTXO will be disclosed to the entire network.
Through the above two steps, the inscription content has been associated with a specific UTXO. According to the positioning method of Satoshi (UTXO) introduced earlier, the inscription is engraved on the first Satoshi corresponding to its input UTXO, and the inscription content is included in the input of the display transaction.
According to the aforementioned circulation and tracking of Satoshi (UTXO), this Satoshi containing special content can be transferred, bought, sold, lost and restored. It should be noted that the inscription is not repeatable, otherwise the subsequent inscription will be invalid.
To explain this process in more detail, let's use an example to show how to engrave a small picture of a Bitcoin NFT. This process covers the two stages of commit and reveal mentioned earlier.
First, we can see that the hash ID of the first transaction is 2ddf9...f585c. It should be noted that the output of this transaction does not contain witness data, and there is no related inscription information on the web page.
Next, we look at the second phase records, whose hash ID is e7454…7c0e1. Here, we can see the Ordinals inscription information, which is the content of the witness inscription.
The input address of this transaction is the output address of the previous transaction, and the output 0.00000546BTC (546 Satoshi) is to transfer this NFT to its own address. At the same time, we can also 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 directly transfer it to someone else's address, that is, transfer this UTXO, thus completing the circulation of the inscription.
4. Bitcoin Wallet
After we understand what the Ordinals ecosystem is, the circulation of satoshis, and the relevant knowledge of inscriptions, there are currently many application scenarios. Whether it is the emergence of BRC-20, ORC-20, BRC-721, GBRC-721 and other related derivative protocols, we need to have corresponding wallets to support and display token information or NFT small pictures.
In this section, we will introduce the concepts and characteristics of different Bitcoin wallet addresses.
A Bitcoin address usually begins with 1, 3, or bc1 and is like an email address and can be shared with other Bitcoin users to transfer Bitcoin directly into your wallet.
From a security perspective, Bitcoin addresses contain no sensitive information and can therefore be shared in public at any time without threatening the security of your account. Unlike email addresses, you can create new Bitcoin addresses as needed, and all of them deposit funds directly into your wallet.
In fact, many modern wallets automatically create a new address for each transaction to maximize privacy. A wallet is just a collection of addresses and the keys that unlock the funds in them. First, we need to know how the address of a Bitcoin wallet is generated.
Bitcoin private and public keys
Bitcoin uses the elliptic curve Secp256k1. The "private key" is a random number between 1 and n−1. n is a very large number (256 bits). n is expressed in scientific notation as:
This range is very wide, making it almost impossible to crack someone else's private key. This private key is a random integer, usually represented by 256 bits of binary, and can be encoded in a variety of ways. Private keys in WIF (Wallet Import Format) or WIF-compressed format are unencrypted and can be directly decoded into the original random integer.
Another method is BIP38 (Bitcoin Improvement Proposal 38), which recommends using the AES algorithm to encrypt private keys. The private key generated by this scheme starts with the character 6P, and a password must be entered to import it into various Bitcoin wallets. This is the private key protection method we usually use.
Next, we use the elliptic curve formula K = kG, where k is the private key and G is the base point, which is an argument of the secp256k1 elliptic curve.
This formula can be used to obtain the two coordinates of K, which are the two expressions of the public key, namely "Uncompressed format" and "Compressed format".
Uncompressed form is to connect the two coordinates x and y directly together, and then add a 0x04 prefix in front;
Compressed form, that is, when y is an even number, it is encoded as 02 x, and when y is an odd number, it is encoded as 03 x;
Bitcoin Address
The various types of Bitcoin addresses are shown in the figure below. There are four ways to represent them:
1. Legacy (P2PKH) format
Example: 1Fh7ajXabJBpZPZw8bjD3QU4CuQ3pRty9u
The address starts with "1" and is the original address format of Bitcoin, which is still in use today. It is obtained by calculating the public key through Hash, also known as P2PKH, which is the abbreviation of Pay To PubKey Hash.
2. Nested SegWit (P2SH) format
Example: 3KF9nXowQ4asSGxRRzeiTpDjMuwM2nypAN
The address starts with "3". P2SH is the abbreviation of Pay To Script Hash, which supports more complex functions than Legacy addresses. Nested P2SH takes an existing P2SH address (starting with "3") and encapsulates it with a SegWit address.
3. Native SegWit (Bech32) format
Example: bc1qf3uwcxaz779nxedw0wry89v9cjh9w2xylnmqc3
BIP0173 introduced an address format starting with "bc1", which is used for native Segregated Witness (SegWit) addresses. This address format uses Bech32 encoding and is designed specifically for SegWit. The Bech32 format address was defined in BIP173 at the end of 2017. One of its main features is that it is case-insensitive, so it is easier to avoid confusion when entering, and it is also easier to read.
Compared with the traditional Base58 encoding, Bech32 uses Base32 encoding, so fewer characters are required in the address, the calculation is more efficient, and it can be stored more compactly in the QR code.
Additionally, Bech32 provides increased security and better optimized checksum error detection, minimizing the risk of invalid addresses.
Bech32 addresses are inherently compatible with SegWit. No extra space is needed to put a SegWit address into a P2SH address, so using Bech32 format addresses will result in lower transaction fees.
In general, Bech32 addresses have several advantages over traditional Base58 addresses: the generated QR codes are smaller, easier to prevent errors, more secure, case-insensitive, and only contain lowercase letters, making them easier to read, enter, and understand.
4. Taproot format (P2TR)
Bech32 has a shortcoming: 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.
In order to alleviate the above shortcomings of Bech32, Bech32m address was proposed in BIP0350:
For native segwit addresses with version 0, use the previous Bech32;
For native segwit addresses with version 1 (or higher), the new Bech32m is used.
For Bech32m addresses, when their version number is 1, they always start with "bc1p", which means they are Taproot addresses. Similar to local segwit, these addresses can be generated by a seed phrase and passphrase, which are used to generate the public and private keys of the extension suite, thus enabling the derivation of addresses of various paths in a hierarchical deterministic wallet.
This is mainly used to store digital assets such as BRC-20 tokens and Bitcoin’s NFTs.
