PSBT (Partially Signed Bitcoin Transaction) is a standard proposed by Andrew Chow, a BTC core developer, to improve the convenience of unsigned transactions. It enables the creation of an incompletely signed transaction and some other data to assist with the transmission of unsigned transactions. It promotes the portability of unsigned transactions, allowing multiple parties to sign the same transaction more conveniently at different times and in different situations (software or hardware wallets). In a multi-signature transaction, the Creator only needs to create a PSBT that identifies the UTXOs to be spent and the outputs that will receive the funds, and then copy this PSBT into a signable program. The Combiner integrates multiple PSBTs into one PSBT and sends it to each participant, and the parties can complete the entire transaction after signing.
In short, PSBT allows users to sign only part of the input to help achieve the de-trustization of BRC20 token transactions without smart contracts. UniSat and other Ordinals markets are using PSBT technology to enable buyers and sellers to trade in a trustless and non-custodial manner.
Why are BRC20 transactions special?
This is because when we parse Bitcoin address tags today, we mainly rely on the Common Spending and One-Time-Change principles based on the UTXO characteristics. The Common Spending principle states that if a BTC transaction has multiple input addresses, it can be considered 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.
However, when using PSBT for BRC-20 transactions, the buyer and seller will coordinate off-chain before the entire PSBT is broadcasted and the signing is completed. Therefore, there may be multiple roles in the input, including the buyer, seller, and platform, and there is a possibility that a specific participant (physically) performs multiple roles. Therefore, the tag model based on the Common Spending principle is not compatible with such transactions.
- Value Capture and Compliance Advance: An Exploration of the Application of the Three-Generation Token Model in China
- The Rationality of the Three-Generation Token Model from the Perspective of Tokenization Theory
- Long Push: Value Assessment of DeFi Dual Token Model
Take a specific BRC20 token transaction as an example. The common BRC20 transactions involve three main types: Token Contract Deployment, Minting, and Transfer.
(1) In the Deploy and Mint processes, token transfers do not have a sender address but only a receiver address, and their BTC transaction inputs and outputs can have at most one address. Therefore, the tag expansion based on the Common Spending principle cannot be used.
(ordi's deploy transaction-token transfer)
（ordi's deploy transaction - BTC transfer）
(2) In the Transfer process of BRC20 tokens, there are usually multiple input addresses. We can distinguish the buyer and seller addresses of this transaction by viewing 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 of the transaction, and the token receiver (bc1p…wftk) is the buyer of the transaction.
However, there may be multiple addresses in the Input of the BTC transfer transaction, including the seller address, the buyer address, and the address of a suspected third-party platform:
After analysis, we found that in the Transfer process of BRC20 tokens, although most of the input script types are single signatures (there are also a few multi-signature situations), due to the possible application of PSBT technology, the seller and third-party platform addresses are jointly added to the input to achieve multi-signature, which may cause multiple addresses in the input to appear to be single signatures, but in fact, they do not belong to the same entity/person, so the Common Spending principle cannot be used to judge.
In summary, the special nature of BRC20 transactions mainly lies in: only one input address will appear at most in the Deploy and Mint processes, which cannot meet the premise of the “Common Spending” principle. In the Transfer process, because the input addresses may contain multiple roles, if the UTXO model based on the “Common Spending” principle is used to expand the transaction address labels, the buyer, seller, and third-party platform may be labeled with the same label, which may lead to label errors, thus misleading other entities’ judgment of the BRC20 market, and even affecting the overall accuracy and credibility of Bitcoin address labels.
How to eliminate the impact of BRC20 on the UTXO label model?
In order to eliminate the negative impact of BRC-20 transactions, we can choose to identify and remove relevant transactions through specific filtering mechanisms in the process of expanding the BTC-UTXO label model, so as to ensure the accuracy of the entire BTC-UTXO label library. At the same time, considering the impact of multi-signature on the BTC-UTXO label expansion model based on the “Common Spending” principle, we also need to analyze the input and output scripts of relevant transactions to filter out multi-signature addresses, so as to theoretically support the expansion of UTXO labels without being affected.
When identifying a multi-signature, the main method is to check whether there are multiple public keys and corresponding signature conditions in its locking script. Multi-signature locking scripts usually contain opcodes similar to “OP_CHECKMULTISIG” or “OP_CHECKMULTISIGVERIFY”, and require multiple signature conditions to unlock funds. If multiple public keys and corresponding signature conditions are found in the output script, the output is a multi-signature output. Similarly, if the input script contains multiple signatures, the input is a multi-signature input.
It should be noted that when performing script type parsing, we first need to determine whether the transaction is a segregated witness transaction. If it is a segregated witness transaction, we need to parse the Witness information. The following are lists of common non-segregated witness transaction scripts and segregated witness transaction scripts:
Take the non-segregated witness transaction script Blockingy-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 recipient’s public key hash as the transaction output script. The recipient needs to provide the private key corresponding to the public key to unlock the output. When parsing P2PKH, the main rules are:
Input script: contains signature information and public key; script.getChunks().size() == 2;
Output script: OP_DUP + OP_HASH160 + pubkeyHash + OP_EQUALVERIFY + OP_CHECKSIG; check whether it starts with OP_DUP and ends with OP_CHECKSIG.
For segregated witness transactions, take P2WPKH as an example. This is a type of transaction that uses segregated witness technology, which can improve the efficiency and security of transactions. In a P2WPKH transaction, the sender needs to provide the recipient’s public key hash as the output script. When parsing this type of transaction, the rules are:
Input script: EMPTY
Witness: signature + pubkey; check if the input script is EMPTY first, and then check if witness.getPushCount() == 2
Output script: 0 + 20-byte witness program; first check whether it starts with 0, and then check whether the witness program length is 20 bytes. (Note: The output script of P2WPKH specifies that the witness program length is 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 related features. According to research, BRC20 transactions are completed through offline signatures using PSBT technology, and their segregated witness type is a semi-signature with 83 as the ending.
Just like the following transaction:
(https://www.oklink.com/cn/btc/tx/cbb6bbd6a828b15afe01ec77eab3e96a83be3d5ff56d99caf8185af79c3d1b53)
Address:bc1pd6pd4pdzx2an8w8pg8dlst8329ck8t8a6ehqqatglfstqmf3f9yss9yz7y
Winess：[“1b003b4099402cde95be79ab7f4b488c74058c0f620cf4cbeb37a90ca871c4a499334a1262f24fdbe484d7511a54a04aa0d693b02159b603021942cb74f55e9d83”]
There is a semi-signature with 83 as the ending in the Witness, so it should be considered as a BRC20-related transaction.
After identifying various multi-signature addresses and BRC20, we can exclude multi-signature addresses and BRC20 transactions according to certain rules to ensure the feasibility and credibility of the BTC-UTXO tag expansion mode. The basic idea is shown in the following figure:
It is worth noting that most of the world’s major on-chain data service providers consider the impact of multi-signature, but no other institution has paid attention to or raised the issue of BRC20 transactions may cause UTXO tag errors.
Bridging the Information Gap Seeking Value Increment in Massive On-Chain Data
The Web3 world is unfamiliar and mysterious to most people, and the most important tool for insight into the Web3 world is on-chain tags. Therefore, the ability to parse tags has become the core indicator for evaluating the competitiveness of on-chain data analysis merchants. However, when we really choose on-chain data service providers, in addition to paying attention to the number of on-chain tags, we must also pay attention to the quality of the tags: are the tags accurate? Is the update timely? … … The negative impact of an incorrect tag is sometimes far greater than the impact of not having a tag. Based on the previously accumulated tag technology capabilities and the deep understanding of the BRC20 market, the Ouke Cloud Chain team discovered and proposed the impact of BRC20 transactions on the UTXO tag model, with the aim of raising market attention, improving the credibility and availability of Bitcoin address tags, and making the quality of on-chain tags even better.
In addition to tag parsing, the global on-chain data service market has huge development potential of at least tens of billions of dollars , and also needs continuous innovation to improve product and service quality. On-chain data service providers cannot profit by selling real-time data and information directly like traditional financial data service providers such as Reuters and Bloomberg. They can only turn to explore more incremental value in massive on-chain information to attract users with better technology innovation and service innovation. Only by being rooted in on-chain data and effectively combining with off-chain information, realizing the organic combination of virtual and reality, and having sensitive market analysis and data insight capabilities, on-chain data analysis services can adapt to the development of encryption innovation and Web3 market.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
