1. Bitcoin background

Bitcoin adopts 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. The record ID of this step is tid1. The second step is to deposit 100 yuan into B's account. The record ID of this step is tid2. The third step is to record a transfer record, which links tid1 and tid2, indicating that account A decreases by 100 yuan and account B 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 Output" (UTXO). Each UTXO contains a certain number of Bitcoins, as well as information about the owners of these Bitcoins, and indicates whether they are available. Think of it like a cash check with the holder's name on it, and as long as the holder signs it, the usage rights can be transferred to someone else. For a specific address, the sum of all UTXO amounts is the balance of the address's wallet. By looping through all UTXOs, we can get the current balance of each address. Add the total amount of all UTXOs to get all the Bitcoins currently in circulation.

In the Bitcoin transaction structure, 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 UTXO referenced by its input part is temporarily locked to prevent reuse until the transaction is completed. Only when the transaction is successfully packaged into a block by miners and confirmed by the network, the related UTXO status will change. Specifically, the UTXOs used as inputs to the transaction are removed from the UTXO list, indicating that they have been consumed, while the outputs of the transaction generate new UTXOs and are added to the UTXO list. It can be understood that after the old cash check is used, it becomes invalid and a new cash check is generated, whose ownership belongs to the new holder.

It is worth emphasizing that each UTXO can only be used once in a transaction. Once it is consumed as 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 list of UTXOs 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.

Additionally, a transaction's total input amount will usually slightly exceed its total output amount. This difference, called a transaction fee or network fee, is given as an incentive to the miners responsible for packaging transactions into blocks. The size of the network fee is directly proportional to the complexity of the transaction, so a transaction with more inputs and outputs will generally require a higher network fee.

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

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

We can randomly select a transaction record on blockchain.com to analyze. The figure below 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:

{"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 the transaction output is called an unspent transaction output (UTXO). Whoever owns the private key corresponding to the public key in UTXO has the right to use (that is, spend) this UTXO.

Let's observe the information in "vin" in the above code. It indicates that the UTXO spent by this transaction comes from the 0th output (the output of a transaction can have multiple, the index is from 0 starting number), we can find the amount of this UTXO from historical transactions (for example, 0.1), so in this transaction, the user spent 0.1 BTC, and the value 0.1 does not need to be written explicitly in the transaction, but through the search UTXO information is obtained. The "vout" of this transaction has two outputs. These two outputs are two new UTXOs, corresponding to the new balance and holder, 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 in which A pays B an amount of n Bitcoins. The figure below shows the process of user A sending 3 Bitcoins to user B.

  1. For user A, first of all, it is necessary to determine the set of all UTXOs it owns, that is, all the Bitcoins that user A can control;

  2. A selects one or more UTXOs from this set as the input of the transaction. 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);

  3. 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 m-n-fee (3.3-3-0.001= 0.299 BTC). A user's wallet usually consists of multiple addresses. Generally, each address is only used once, and change is returned to a new address by default;

  4. After the miner packages the transaction and uploads it to the chain for confirmation, B can receive the transaction information. Because the block size has an upper limit (approximately 1 MB), miners will prioritize transactions with high transaction rates (fee_rate=fee/size) to obtain the highest fee returns. We can see the real-time mining transaction fee situation in mempool. If we want the fastest confirmation during the transfer process, we can choose High Priority or customize a suitable transaction rate;

2. Cong numbering and tracking

The total number of Bitcoins is 21 million, and each Bitcoin contains 10^8 Satoshi (Satoshi, Sat). Therefore, there are a total of 21 million*10^8 satoshis on the Bitcoin network. The Ordinals protocol distinguishes these satoshis and gives each satoshi a unique number. This section will introduce how this protocol uniquely numbers each Satoshi and how it tracks the account it belongs to. In addition, the rarity classification of Satoshi will also be introduced.

Satoshi's number

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

There are many ways to express Satoshi:

  • Integer symbol: For example, 2099994106992659, which represents the serial number assigned to the satoshi according to the mining order.

  • Decimal notation: For example, 3891094.16797, the first number indicates the height of the block where the satoshi was mined, and the second number indicates the number of satoshi in the block.

  • Degree symbol: For example, 3°111094′214″16797‴, the first number is the period, numbered starting from 0, the second number is the block index of the halving epoch, and the third number is the block index during the difficulty adjustment period , the last number is the index of sat in the block.

  • Percent symbol: For example, 99.99971949060254% indicates the position of the Satoshi in the Bitcoin supply, expressed as a percentage.

  • Name: For example Satoshi. A name that encodes the sequence number using the characters a through z.

We will use an example to explain how to number newly mined Bitcoins. Looking at block 795952 of the Bitcoin blockchain, we can see that the first transaction Tx 3a1f...b177 records the miner's reward (coinbase transaction). This transaction includes the newly mined Bitcoins, which are used as packaging rewards for the miners, as well as the handling fees paid to the miners by the transaction initiator. By looking at the input in the figure below, we can find that its UTXO 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 sum of the above rewards and handling fees.

If we look further into the output to miners, we can see the distribution of addresses, amounts, and contained satoshis. As mentioned earlier, these include mining rewards and fees. Among them, the green sats number information 1941220000000000–1941220625000000 is the new satoshi generated by the mining reward, and the remaining 712 satoshi records correspond to all handling fees in the block.

We can verify the number Sat 1941220000000000. Its block number is 795952, and the decimal notation (decimal) is 795952.0, which means that the block height of mining this Satoshi is 795952, the number of Satoshi in this block is 0, and the subsequent rarity (rarity) mark is uncommon. We This will be explained in detail in a later section.

The circulation of Cong

Because every BTC is generated through mining rewards, they are all traceable. Bitcoin accounts use the UTXO model. Assume that user A obtains the 100th-110th satoshi through mining (10 satoshis are stored as a whole in the same UTXO with the ID adc123). When user A wants to pay 5 satoshis to user B, he chooses to use the ID abc123 as the input of the transaction, of which 5 satoshis are given to user B, and 5 satoshis are returned to user A as change. These two copies of 5 satoshis are a whole and are stored in two UTXOs with IDs abc456 and abc789 respectively. The above UTXO id and the number of satoshis are only shown as examples. In actual situations, the minimum number of satoshis sent is limited to 546 and the UTXO id is not expressed in this form.

In the above transaction, the circulation path of user A’s 10 satoshis is:

  1. Mining produces 10 satoshis, numbered [100, 110). It means that the 100th to 109th satoshis are stored in the UTXO with the id abc123, and its owner is user A.

  2. When A transfers money, 10 satoshis are divided into two parts, each with 5 satoshis. The "first in, first out" principle is used here, that is, the number ordering of satoshis is determined according to their index in the transaction output. Assume that the order of output is user A first, then user B, then the serial number of user A’s remaining 5 satoshis is [100, 105), stored in the UTXO with ID abc456, and the serial number of user B’s 5 satoshis is [105 , 110), stored in the UTXO with id abc789.

Rareness (Rare Satoshi)

As a spin-off of the Ordinals protocol, the rarity of satoshis 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 the block (total supply is 2,100 trillion)

  • uncommon: first satoshi in every block (total supply is 6,929,999)

  • rare: first satoshi each difficulty adjustment period (total supply 3437)

  • epic: the first satoshi after each halving (total supply is 32)

  • legendary: the first satoshi every 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

Ordinals are significantly different from NFTs on other non-Bitcoin chains. The main difference is that Ordinals metadata is not stored in a specific location. Instead, this metadata is embedded into the transaction’s witness data (witness data, witness field), which is why we call it an “inscription” because this data is “engraved” into Bitcoin like an inscription. On a specific part of the transaction, the data is attached to a specific Satoshi. This inscription process is implemented through Segregated Witness (SegWit) and Pay-to-Taproot (P2TR), which includes two stages: commit and reveal, which can Any form of content (such as text, images or videos) is inscribed on the designated Satoshi. We will introduce another more direct storage method OP_RETURN below and explain why it is not used as a means of inscription. At the same time, we will introduce what Segregated Witness and Pay-to-Taproot are, and what roles they play in Inscription. Finally we will introduce the method of inscription.

OP_RETURE

In Bitcoin Core client version 0.9, the compromise was finally achieved through the adoption of 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 that does not need to be stored in a UTXO set. RETURN outputs are recorded on the blockchain. They consume disk space and increase the size of the blockchain. However, they are not stored in the UTXO set, so they will not expand the UTXO memory pool and will not increase the number of full nodes. Expensive memory costs.

While OP_RETURN is a very straightforward means of storing information into the Bitcoin blockchain, it is also a potential method of inscription. But the limitations of OP_RETURN make it face some challenges when dealing with metadata storage. First of all, OP_RETURN can only store 80 bytes of data. For situations where larger amounts of data need to be stored, this limitation is obviously unsatisfactory. Secondly, OP_RETURN data is stored in the transaction output part. Although this data is not stored in the UTXO set, they occupy the storage space of the blockchain, leading to an increase in the size of the blockchain. Finally, using OP_RETURN results in higher transaction fees because it requires paying more to post these transactions.

Segregated Witness

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

The main benefit of separating signatures from transaction-related data is reducing the size of the data stored in a Bitcoin block. This has extra capacity per block to store more transactions, which also means the network can handle more transactions and senders pay lower fees. Technically speaking, it means taking the script signature (scriptSig) information out of the basic structure (base block) and placing it in a new data structure. The nodes and miners doing the verification work will also verify the script signature in this new data structure to ensure that the transaction is valid. The Segwit upgrade introduces a new witness field in transaction outputs to ensure privacy and performance. While witness data is not designed for data storage, it actually gives us an opportunity to store things like inscription metadata. We use the following figure to understand Segregated Witness more vividly:

Taproot

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

First, due to the way Taproot scripts are stored, we can store inscription content in Taproot script path expenditure scripts, which have almost no restrictions on content, while also receiving discounts on witness data, making storing inscription content relatively economical. Since consumption of Taproot scripts can only be done from already existing Taproot output, Inscription uses a two-stage commit/reveal process. First, in the commit transaction, a Taproot output is created that promises a script containing the inscription content. Then, in a reveal transaction, the output created by the commit transaction is consumed, thereby revealing the inscription content on-chain.

This approach greatly reduces the consumption of resources. If P2TR is not used, the witness information will be stored in the output of the transaction. In this way, as long as this output is not consumed, the witness information will always be 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 to the UTXO set. Only when this UTXO is consumed will the witness information appear in the transaction input during the reveal phase. P2TR enables 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 can save a lot of resources.

inscription

The Ordinals protocol takes advantage of SegWit to relax the size limit on content written to the Bitcoin network, storing the inscription content in the witness data. Allowing it to store up to 4MB of metadata. Taproot makes it easier to store arbitrary witness data in Bitcoin transactions, allowing Ordinals developer Casey Rodarmor to repurpose old opcodes (OP_FALSE, OP_IF, OP_PUSH) into what he describes as "envelopes" for what he calls "inscription" storage Arbitrary data.

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

  1. First, you need to create a commit transaction to the Taproot output of the script containing the inscription content. The storage format is Taproot, that is, the output of the previous transaction is P2TR (Pay-To-Taproot), and the input of the next transaction is embedded in a specific format in the witnessed Taproot script; first, the string ord is pushed onto the stack, to eliminate ambiguity that the inscription had 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 the few limitations of taproot is that a single data push cannot be larger than 520 bytes. At this time, the inscription data has been mapped to 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 time, the corresponding inscription content was made public to the entire Internet.

Through the above two steps, the inscription content has been bound to the inscribed UTXO. According to the positioning of Satoshi introduced above, inscription is performed on the first Satoshi corresponding to the UTXO input, and the content of the inscription is included in the input of the displayed transaction. According to the introduction to the circulation and tracking of satoshis introduced above, this satoshis engraved with special content can be transferred, purchased, sold, lost and recovered. It should be noted that repeated inscriptions are not allowed, otherwise subsequent inscriptions will be invalid.

We will explain this process in detail through the example of engraving a small BTC NFT image. This process mainly includes the two stages of commit and reveal mentioned before. 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 information in the web page.

Next, we check the second stage record, whose Hash ID is e7454...7c0e1. Here, we can see the information of Ordinals inscription, which is the content of the inscription of the testimony. The input address of this transaction is the output address of the previous transaction, and the output 0.00000546BTC (546 Satoshi) is to send this NFT to your 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 send it directly to other people's addresses, that is, send this UTXO, thus completing the transfer of the inscription.

4. Bitcoin Wallet

After we understand what is the Ordinals ecology, the circulation of satoshis, and the related 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, which require We 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.

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 Bitcoin directly to their own wallets. From a security perspective, Bitcoin addresses do not contain anything sensitive. It can be posted anywhere without compromising the security of your account. Unlike email addresses, new addresses can be created at any time as needed, all of which will deposit funds directly into your wallet. In fact, many modern wallets automatically create a new address for every transaction to maximize privacy. A wallet is simply a collection of addresses and keys that unlock the funds within it. First we need to know how the Bitcoin wallet address is generated.

Bitcoin private and public keys

Bitcoin uses elliptic curve Secp256k1. The "private key" is a random number between 1 and n-1. n is a large number (256 bits). n is expressed in scientific notation as follows:

This range is extremely large, and it is almost impossible for us to guess other people's private keys. This random integer private key can be represented by 256 bits, and there are multiple encoding methods. If the private key in WIF or WIF-compressed form is not encrypted, the original "random integer" can be obtained by decoding it. Another way is BIP38, which proposes to use the AES algorithm to encrypt the private key. The private key obtained by this method starts with the character 6P. This kind of private key must enter a password before it can be imported into various Bitcoin wallets. This is what we usually do. Commonly used private keys.

Then we will use the elliptic curve formula K = kG to generate the Bitcoin public key K from the private key k. G is the Base Point, which is a parameter of secp256k1. The two coordinates of K can be obtained, which are the two expressions of the public key, namely "Uncompressed format" and "Compressed format".

  • The Uncompressed form is to directly connect the two coordinates x and y together, and then add a 0x04 prefix in front;

  • Compressed form means that when y is an even number, the encoding is 02 x, and when y is an odd number, the encoding is 03 x;

Bitcoin address

Various types of Bitcoin addresses are shown in the figure below. There are four representation methods:

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

1. Legacy (P2PKH) format

Example: 1Fh7ajXabJBpZPZw8bjD3QU4CuQ3pRty9u

Addresses starting with "1" are the original address format of Bitcoin and are still used today. It is calculated from the public key through Hash, also known as P2PKH, which is the abbreviation of Pay To PubKey Hash (payment to public key hash).

2. Nested SegWit (P2SH) format

Example: 3KF9nXowQ4asSGxRRzeiTpDjMuwM2nypAN

The address starts with "3" and P2SH is the abbreviation of Pay To Script Hash, which supports more complex functions than Legacy addresses. Nested P2SH, takes the existing P2SH address (starting with "3") and encapsulates it with the SegWit address.

3. Native SegWit (Bech32) format

Example: bc1qf3uwcxaz779nxedw0wry89v9cjh9w2xylnmqc3

Addresses starting with bc1 are proposed in BIP0173, which are native SegWit addresses. Bech32 encoded address is an address format specially developed for SegWit. Bech32 was defined in BIP173 at the end of 2017. One of the main features of this format is that it is case-insensitive (the address only contains 0-9, a-z), so it can effectively avoid confusion when inputting and is more readable. Since fewer characters are required in the address, the address uses Base32 encoding instead of the traditional Base58, making calculations more convenient and efficient. Data can be stored more tightly in QR codes. Bech32 provides greater security, better optimized checksum error detection code, and minimizes the chance of invalid addresses.

Bech32 addresses themselves are compatible with SegWit. No additional space is required to put the SegWit address into the P2SH address, so using the Bech32 format address, the handling fee will be lower. Bech32 addresses have several advantages over older Base58 (Base58Check encoding is used to encode byte arrays in Bitcoin into human-encodable strings) addresses: QR codes are smaller; better error-proof; more secure; indistinguishable Uppercase and lowercase; consists of only lowercase letters, so it's easier to read, type and understand.

4. Taproot format (P2TR)

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

To alleviate the above shortcomings of Bech32, the Bech32m address was proposed in BIP0350:

  • For version 0 native SegWit addresses, use previous Bech32;

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

For Bech32m addresses, when version is 1, they always start with bc1p (i.e. Taproot addresses). Specifically, just like native SegWit, a wallet can be composed of a seed phrase and a passphrase. These are used to generate extended public and private keys used to derive addresses for arbitrary paths in a hierarchical deterministic wallet. It mainly stores BRC-20 and BTC NFT, etc.