Source: EuChain Research Institute
Author: Jason Jiang
In the Web 3 world, the data generated by on-chain activities corresponds directly to the flow of value, and mastering on-chain data enables the discovery of more Alpha. In addition, personal and institutional users have become more sensitive to on-chain data as the cryptocurrency market has frequently encountered risk events in recent years. On-chain data has become an essential "tool" for understanding the crypto world. However, when analyzing the address labels of BRC-20 transactions, which have been gaining popularity recently, we found that the previous BTC-UTXO model does not seem to be fully applicable. What is the problem exactly? And how can it be resolved?
BRC-20 Transactions and PSBT
Before analyzing the problem, we need to understand the basics of BRC-20. In January 2023, Casey Rodarmor, a Bitcoin core contributor, proposed the "Ordinals Theory," which allows users to write arbitrary files (such as images, text, videos, etc.) on the smallest unit of Bitcoin called "sats" (up to 4MB). Subsequently, the anonymous analyst @domodata created the BRC-20 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 BRC-20 standard have created new use cases for the Bitcoin ecosystem beyond value transfer, giving it another attractive narrative logic after the halving. As the oldest blockchain ecosystem, Bitcoin has thus regained unlimited vitality, and BRC-20 tokens have become a highly regarded track in the first half of 2023: as of June 29, 2023, there are over 6000 BRC-20 related tokens with a total market value exceeding 600 million US dollars.
However, unlike Ethereum's ERC-20, which can immediately issue and transfer tokens after deploying smart contracts, BRC-20 is not literally tokens but "sats" that record specific texts. Therefore, a separate indexer is needed to understand the status or balance of BRC-20 tokens. At the same time, BRC-20 utilizes JSON data packets in public key scripts as carriers, and the deployment of related token contracts, token minting, and token transfers all need to use the Ordinals protocol to set the inscriptions as JSON data format.
Because Bitcoin's public key script only stores data and does not support the execution of smart contract instructions, BRC-20 tokens cannot be used to build related protocols for automatic delivery. In theory, transactions can only be completed through centralized custody or OTC. Both of these methods have unsatisfactory transaction efficiency and trust level. Therefore, PSBT (Partially Signed Bitcoin Transactions) has been used in BRC-20 related transactions.
PSBT, proposed by BTC core developer Andrew Chow, is a standard that improves the convenience of unsigned transactions. It can create a partially signed transaction and some other data to assist in the transmission of unsigned transactions, promote the portability of unsigned transactions, and allow multiple parties to sign the same transaction more conveniently at different times and in different scenarios (software or hardware wallets). In a multi-signature transaction, the Creator only needs to create a PSBT to identify the spent UTXO and the received UTXO, and then copy this PSBT to a signable program. The Combiner integrates multiple PSBTs into one and sends it to each participant, allowing all parties to complete the signatures and finalize the transaction.
In short, PSBT allows users to sign only part of the input to help achieve trustless trading of BRC-20 tokens without smart contracts. Both UniSat and other Ordinals markets are utilizing PSBT technology to facilitate trustless and non-custodial transactions between buyers and sellers.
Why do BRC-20 transactions have special characteristics?
This is because when we parse the Bitcoin address labels, we mainly rely on the principles of Common Spending and One-Time-Change based on the characteristics of UTXOs. Common Spending principle states that if a BTC transaction has multiple input addresses, it can be determined that these input addresses belong to the same entity because only he/she has all the private keys to put these addresses in the same transaction.
But when using PSBT for BRC-20 transactions, the entire PSBT will be coordinated off-chain before broadcasting, with the buyer and seller confirming the input and output before completing the signature. Therefore, there may be multiple roles in the input, such as buyer, seller, and platform, and there is a possibility that a specific participant (physically) can take on multiple roles. Therefore, the tag model based on the Common Spending principle cannot be compatible with such transactions.
Take BRC-20 Token transactions as an example. The common BRC-20 transactions currently involve three main types: Token contract deployment (Deploy), minting (Mint), and transfer (Transfer).
(1) In the Deploy and Mint processes, token transfers do not have a sender address, only a recipient address, and the BTC transaction's input and output addresses can have at most one. Therefore, it is not possible to extend the tag based on the Common Spending principle.
(ordi's deploy transaction-token transfer)
(ordi's deploy transaction-BTC transfer)
(2) In the process of transferring BRC 20 tokens, there are usually multiple Input addresses. We can identify the buyer and seller addresses of this transaction by inspecting the token transfer of the transaction. For example, in the following ordi Transfer transaction (https://www.oklink.com/cn/btc/tx/bc2ac0be40b33cfaf0dedf7bafc97de113ce56e2e6dc7caf67c116f00d1dc849), the token sender (bc1p...hdjn) is the seller, and the token recipient (bc1p...wftk) is the buyer.
However, in a BTC transfer transaction, there may be multiple addresses in the Input, including the seller address, the buyer address, and addresses possibly associated with a third-party platform:
Through analysis, we found that in the Transfer process of BRC 20, although most of the input script types are single-signature (with a few cases of multi-signature), due to the possible application of PSBT technology, the seller and third-party platform addresses are added together to the input to achieve multi-signature. This causes multiple addresses in the input to appear as single signatures, but they actually do not belong to the same entity/individual, making it impossible to judge based on the Common Spending principle.
Above all, the uniqueness of BRC 20 transactions is mainly reflected in the following aspects: during the Deploy and Mint processes, there will be at most one input address, which does not meet the prerequisite of the "Common Spending" principle. During the Transfer process, since the input address may contain multiple roles, if the UTXO model based on the "Common Spending" principle is used to extend the transaction addresses with labels, it may assign the same labels to the buyer, seller, and third-party platform, leading to label errors. This can mislead other entities' judgment of the BRC 20 market and even affect the overall accuracy and credibility of Bitcoin address labels.
How to eliminate the impact of BRC 20 on the UTXO label model?
In order to eliminate the negative impact caused by BRC-20 transactions, we can choose to identify and remove relevant transactions through a specific filtering mechanism in the process of extending the BTC-UTXO label model. This ensures the accuracy of the entire BTC-UTXO label library. Considering the impact of multi-signatures on the BTC-UTXO label extension model based on the "Common Spending" principle, we also need to parse the input and output scripts of the relevant transactions to filter out multi-signature addresses. This theoretically supports unaffected UTXO label extension.
Identifying multi-signatures is mainly done by checking whether their locking scripts contain multiple public keys and corresponding signing conditions. Multi-signature locking scripts usually contain opcode operations such as "OP_CHECKMULTISIG" or "OP_CHECKMULTISIGVERIFY" and require multiple signing conditions to unlock funds. If multiple public keys and corresponding signing conditions are found in the output script, it is a multi-signature output. Similarly, if the input script contains multiple signatures, it is a multi-signature input.
It should be noted that when parsing script types, we need to first determine whether the transaction is a Segregated Witness transaction. If it is, the Witness information needs to be parsed. The following are common non-Segregated Witness and Segregated Witness transaction scripts:
In this example, we will take the Pay-to-Public-Key-Hash (P2PKH) witnessing transaction script as an example. This is one of the most common types of Bitcoin transactions. In a P2PKH transaction, the sender needs to provide the recipient's public key hash as the transaction output script. The recipient needs to provide the corresponding private key to unlock the output. The main rules for parsing P2PKH are as follows:
Input script: It contains signature information and the public key; script.getChunks().size() == 2;
Output script: OP_DUP + OP_HASH 160 + pubkeyHash + OP_EQUALVERIFY + OP_CHECKSIG; Check if it starts with OP_DUP and ends with OP_CHECKSIG.
In Segregated Witness transactions, we will take the Pay-to-Witness-Public-Key-Hash (P2WPKH) as an example. This is a type of transaction that uses Segregated Witness technology, which improves transaction efficiency and security. In a P2WPKH transaction, the sender needs to provide the recipient's public key hash as the output script. The rules for parsing this type of transaction are as follows:
Input script: EMPTY
Witness: signature + pubkey; To check, first verify if the input script is EMPTY, then check if the witness.getPushCount() == 2;
Output script: 0 + 20 byte witness program; First, check if it starts with 0, then check if the length of the witness program is 20 bytes. (Note: P 2 WPKH output script requires the witness program to be 20 bytes in length.)
In addition to identifying multi-signature addresses based on the characteristics of different transaction input and output scripts, we can also filter out BRC 20 transactions based on related features. According to research, BRC 20 transactions are completed using PSBT technology through offline signatures, and their segregated witness type ends with 83 and is a semi-signature.
Just like this transaction:
(https://www.oklink.com/cn/btc/tx/cbb6bbd6a828b15afe01ec77eab3e96a83be3d5ff56d99caf8185af79c3d1b53)
Address: bc1pd6pd4pdzx2an8w8pg8dlst8329ck8t8a6ehqqatglfstqmf3f9yss9yz7y
Witness: ["1b003b4099402cde95be79ab7f4b488c74058c0f620cf4cbeb37a90ca871c4a499334a1262f24fdbe484d7511a54a04aa0d693b02159b603021942cb74f55e9d83"]
The witness ends with 83, so it should be considered as a BRC 20 related transaction.
After identifying various types of multi-signature addresses and BRC 20, we can exclude them based on certain rules to ensure the feasibility and credibility of the BTC-UTXO tag extension mode. The basic idea is shown in the diagram below:
It is worth noting that the current major on-chain data service providers consider the impact of multi-signature when expanding UTXO labels, but no other institution has yet paid attention to or raised the issue of UTXO label errors that may be caused by BRC-20 transactions.
Filling the information gap and finding value-added in massive on-chain data
Web 3 world is unfamiliar and mysterious to most people, and the most important tool for insights into Web 3 world is on-chain labels. The ability to parse labels has therefore become a core indicator for evaluating the competitiveness of on-chain data analysis businesses. But when we actually choose on-chain data service providers, in addition to paying attention to the number of on-chain labels, we also need to pay attention to the quality of the labels: Are the labels accurate? Are they updated in a timely manner? ... Sometimes the negative impact of an incorrect label is much greater than the impact of having no label at all. Based on the previously accumulated label technology capabilities and a deep understanding of the BRC-20 market, the Oke Cloud Chain team has discovered and proposed the impact of BRC-20 transactions on the UTXO label model, with the aim of drawing attention from the market, improving the credibility and usability of Bitcoin address labels, and making the quality of on-chain labels more robust.
In addition to label parsing, the global on-chain data service market not only has huge development potential with at least billions of dollars, but also needs continuous innovation to improve product and service quality. On-chain data service providers can no longer profit from selling real-time data and information directly, like traditional financial data service providers such as Reuters and Bloomberg. Instead, they must turn to explore more incremental value in massive on-chain information, and attract users through better technological and service innovation. Only by being rooted in on-chain data and effectively combining it with off-chain information, achieving an organic combination of virtual and reality, while having sharp market analysis and data insight capabilities, can on-chain data analysis services adapt to cryptographic innovation and the development of the Web 3 market.
As a global leading Web 3 data technology company, Oke Cloud Chain currently possesses industry-leading label parsing capabilities: not only has the largest number of address labels in the world (3 billion+), and the most comprehensive black-gray address labels (27 million+), but also updates and expands the address label library in a timely manner according to market development to meet the latest user needs. However, whether it is address label parsing or other on-chain data analysis, it cannot be separated from interaction and connection with the market. The Oke Cloud Chain team also maintains an open attitude and looks forward to in-depth communication and cooperation with more industry partners in address label parsing and other on-chain data topics, to jointly promote the prosperity of the Web 3 ecosystem.
