The latest discovery: BRC-20 transactions do not apply to the BTC-UTXO label model

Produced｜Okey Cloud Chain Research Institute

Author｜****Jason Jiang

In the Web3 world, the data generated by activities on the chain directly corresponds to the value flow, and more Alpha can be discovered by mastering the data on the chain. Coupled with frequent risk events in the encryption market in recent years, individual and institutional users are becoming more sensitive to on-chain data. On-chain data has become an indispensable “sharp tool” for insight into the encrypted world. However, in the face of the BRC20 transactions that have been in the limelight recently, when we analyzed their address tags, we found that the previous BTC-UTXO model did not seem to be fully applicable. Where is the problem? How to solve it?

BRC20 Transaction with PSBT

Before analyzing the problem, we must first understand the basic situation of BRC20. In January 2023, Bitcoin core contributor Casey Rodarmor proposed “Ordinals Theory”, which allows users to write arbitrary files (images, texts, videos, etc. not exceeding 4MB) on the smallest unit of Bitcoin “Satoshi”. Subsequently, anonymous analyst @domodata created the BRC20 token standard based on the Ordinals protocol. This is an experimental token standard that allows anyone to issue tokens on the Bitcoin network.

The Ordinals protocol and the BRC20 standard have created a new use case for the Bitcoin ecosystem other than value transfer, giving it another attractive narrative logic after the halving. As the oldest blockchain ecology, Bitcoin is therefore full of infinite vitality, and BRC20 tokens will also become a track that has attracted wide attention in the first half of 2023: as of June 29, 2023, there are more than 6,000 BRC20-related tokens, The market cap exceeds $600 million.

However, unlike Ethereum ERC20, which can issue and transfer tokens immediately after deploying smart contracts, BRC20 is not a token in the actual sense, but a “Satoshi” that records specific text, so a separate indexer is required to understand the status of BRC20 tokens or balance. At the same time, BRC20 uses the JSON data package in the public key script as the carrier, and the deployment of related token contracts, as well as token casting and transfer, all need to use the Ordinals protocol to set the inscription in JSON data format to achieve.

Because the Bitcoin public key script only stores data and does not support the execution of smart contract instructions, BRC20 tokens cannot build relevant agreements to achieve automatic delivery. In theory, transactions can only be completed through centralized custody or OTC. These methods are not satisfactory in terms of transaction efficiency and trust, so PSBT (Partially Signed Bitcoin Transactions) began to be used in BRC20-related transactions.

The so-called PSBT is a standard proposed by BTC core developer Andrew Chow to improve the convenience of unsigned transactions. It can create an incompletely signed transaction and some other data to assist the transmission of unsigned transactions, promote the portability of unsigned transactions, and make it easier for multiple parties to use the same transaction at different times and on different occasions (software or hardware wallets). Sign the transaction. In a multi-signature transaction, the Creator only needs to create a PSBT to identify the UTXO to be spent and the output to receive the UTXO, and then copy the PSBT into a program that can be signed, and integrate multiple PSBTs into one PSBT through the Combiner. For each participant, the full transaction is complete after all parties complete their signatures.

In short, PSBT allows users to sign only part of the input to help BRC20 tokens achieve trustless transactions without smart contracts. Markets including UniSat and other Ordinals are utilizing PSBT technology to enable buyers and sellers to conduct transactions in a trustless and non-custodial manner.

**Why is the BRC20 transaction special? **

This is because, when we analyze the Bitcoin address label, we mainly trace it based on the principles of Common Spending and One-Time-Change of UTXO characteristics. Among them, the Common Spending principle means that if a BTC transaction has multiple input addresses at the same time, it can be determined that these input addresses belong to the same entity, because only he/it has all the private keys to put these addresses in the same entity. in transaction.

However, when using PSBT for BRC-20 transactions, before the entire PSBT broadcast, the buyer and seller will be coordinated off-chain to complete the signature after confirmation of Input and Output. Therefore, there may be multiple roles such as buyer, seller, and platform in the input. And there is the possibility of a specific participant (physically) taking on multiple roles at the same time, so the label model using the Common Spending principle is not compatible with this type of transaction.

Take the specific BRC20 Token transaction as an example. Currently common BRC20 transactions involve three main types: Token contract deployment (Deploy), minting (Mint) and transfer (Transfer).

(1) In the process of Deploy and Mint, the token transfer does not have the address of the sender but only the address of the receiver. There is at most one input and output address for the BTC transfer transaction, so the model based on the Common Spending principle cannot be used for label expansion.

(ordi’s deploy transaction - token transfer)

(ordi’s deploy transaction - BTC transfer)

(2) During the transfer process of BRC20 tokens, there are usually multiple Input addresses. We can identify the buyer and seller addresses of this transaction by checking the token transfer of the transaction. For example, in the transfer transaction of ordi below (in which the token sender (bc1p…hdjn) is the seller of the transaction, and the token receiver (bc1p…wftk) is the buyer of the transaction.

However, there will be multiple addresses in the Input of the BTC transfer transaction, including the seller’s address, the buyer’s address and the address of a suspected third-party platform:

After analysis, we found that in the transfer process of BRC20, Although most of the input script types are single-signature (there are also a few multi-signature cases), due to the possible application of PSBT technology, the address of the seller and the third-party platform are jointly added to the Multi-signature is implemented in the input, so although multiple addresses in the input appear to be a single signature, they actually do not belong to the same entity/individual, so the Common Spending principle cannot be used for judgment.

To sum up, the particularity of BRC20 transactions is mainly reflected in the fact that at most one input address will appear in the process of Deploy and Mint, which cannot meet the prerequisites of the “Common Spending” principle. In the transfer process, since the input address may contain multiple roles, if the UTXO model based on the “Common Spending” principle is used to expand the label of the transaction address, the buyer, seller and third-party platform may be labeled with the same label. This will lead to label errors, which will mislead other entities to judge the BRC20 market, and even affect the overall accuracy and credibility of Bitcoin address labels.

**How to eliminate the impact of BRC20 on the ****UTXO tag model? **

In order to eliminate the negative impact of BRC-20 transactions, in the process of expanding the BTC-UTXO tag model, we can choose to identify and eliminate related transactions through a specific screening mechanism to ensure the accuracy of the entire BTC-UTXO tag library. At the same time, considering the impact of multi-signatures on the BTC-UTXO label expansion model based on the “Common Spending” principle, we also need to analyze the input and output scripts of related transactions to filter multi-signature addresses, so as to theoretically support UTXO labels Extensions are not affected.

Among them, the identification of multi-signature is mainly by checking whether the locking script contains multiple public keys and corresponding signature conditions. Multisig lock scripts typically contain opcodes like “OP_CHECKMULTISIG” or “OP_CHECKMULTISIGVERIFY” and require multiple signatures to be met in order to unlock funds. If multiple public keys and corresponding signature conditions are found in the output script, then the output is a multi-signature output. Likewise, if an input script contains multiple signatures, then the input is a multi-signature input.

It should be noted that when parsing the script type, we must first determine whether the transaction is an isolated witness transaction. If it is an isolated witness transaction, the Witness information needs to be parsed. The following is a list of common non-segwit transaction scripts and segregated witness transaction scripts:

Take the non-segregated witness transaction script Pay-to-Public-Key-Hash (P2PKH) as an example. This is one of the most common types of Bitcoin transactions. In a P2PKH transaction, the sender needs to provide the receiver’s public key hash as the transaction output script. The receiver needs to provide the private key corresponding to this public key to unlock the output. When analyzing P2PKH, the main rules are:

Input script: contains signature information and public key; .getChunks().size() == 2;

Output script: OP_DUP + OP_HASH160 + pubkeyHash + OP_EQUALVERIFY + OP_CHECKSIG; determine whether it starts with OP_DUP and ends with OP_CHECKSIG.

In segregated witness transactions, take P2WPKH as an example. This is a type of transaction that uses Segregated Witness technology, which increases the efficiency and security of transactions. In a P2WPKH transaction, the sender needs to provide the receiver’s public key hash as an output script. When parsing such transactions, the rules are:

Enter script: EMPTY

witness: signature + pubkey; when judging, first obtain whether the input is EMPTY, and then judge that witness.getPushCount() == 2

Output script: 0 + 20byte witness program; when judging, first judge whether it starts with 0, and then judge whether the length of the witness program is 20byte. (Note: The length of the witness program in the output of P2WPKH is specified as 20 bytes.)

In addition to identifying multi-signature addresses based on the input and output script characteristics of different transactions, we can also filter BRC20 transactions based on relevant characteristics. According to research, BRC20 transactions are completed in the form of offline signatures using PSBT technology, and the isolated witness type is a half-signature ending with 83 in Witness.

Like this transaction:

（

Address:bc1pd6pd4pdzx2an8w8pg8dlst8329ck8t8a6ehqqatglfstqmf3f9yss9yz7y

Winess：[“1b003b4099402cde95be79ab7f4b488c74058c0f620cf4cbeb37a90ca871c4a499334a1262f24fdbe484d7511a54a04aa0d693b02159b603021942cb74f 55e9d83”]

There is a semi-signature ending in 83 in Witness, so it should be regarded as a BRC20 related transaction.

After identifying various multi-signature addresses and BRC20, we can eliminate multi-signature addresses and BRC20 transactions according to certain rules, so as to ensure the feasibility and credibility of the BTC-UTXO label expansion model. The basic idea is shown in the figure below:

It is worth noting that most of the world’s major on-chain data service providers now consider the impact of multi-signatures when expanding UTXO tags, but no other organization has paid attention to or raised the issue that BRC20 transactions may lead to UTXO tag errors . **

Bridging the information gap** Looking for value increments in massive chain data**

The Web3 world is unfamiliar and mysterious to most people, and the most important tool for insight into the Web3 world is the on-chain tag. Therefore, the tag resolution capability has become a core indicator for evaluating the competitiveness of on-chain data analysts. But when we really choose an on-chain data service provider, we should not only pay attention to the number of tags on the chain, but also pay attention to the quality of tags: Are the tags accurate? Are the updates timely? …a wrong label can sometimes have far greater negative impact than no label at all. Based on the previously accumulated label technology capabilities and in-depth understanding of the BRC20 market, the Okey Cloud Chain team discovered and proposed the impact of BRC20 transactions on the UTXO label model. The purpose is to attract market attention and improve the credibility of Bitcoin address labels The quality and usability of the chain make the quality of the label more excellent.

In addition to label analysis, while the global on-chain data service market has a huge development potential of at least $10 billion, it also needs continuous innovation to improve product and service quality. ** It is impossible for data service providers on the chain to make profits by directly selling real-time data and information like traditional financial data service providers such as Reuters and Bloomberg. Good technological innovation and service innovation attract users’ attention. Only when it is rooted in on-chain data and effectively combined with off-chain information, realizes the organic combination of virtual and reality, and has keen market analysis and data insight capabilities, can on-chain data analysis services adapt to encryption innovation and Web3 market development.