The original source is from Twitter, authored by @AurtrianAjian from BTCStudy; authorized reproduction, does not represent the viewpoint of Odaily.
I've heard outrageous things, but I didn't know you could be this outrageous. Please stop participating in the "BRC 20" token sale and boycott it.
You should not participate in it anymore, because technically speaking, this backward thing will definitely be eliminated. You should boycott it because it will cause the expansion of the UTXO set, and its practical consequences are approaching a dust attack.
I have previously written that something like BRC 20 cannot be called a "protocol" at all because it cannot protect the users who use it. But at that time, I didn't delve into it, and I didn't know that it was even more outrageous than I imagined.
On the surface, BRC 20 defines two operations for fungible tokens: "Mint" and "Transfer"...
In each step of each operation, a Bitcoin transaction needs to be initiated and an inscription needs to be written in the transaction input (through the witness script of the input, the data is written in the block). However, in BRC 20, the transaction outputs formed by the inscriptions written in do not have any meaningful value. That's the problem.
If you look carefully at the above document, you will find that it says:
"The balance state of BRC 20 can be obtained by aggregating the activities of all these functions"; however, the activities of all these functions are manifested through inscriptions, and none of them require spending specific UTXOs (or even specific satoshis). Whether you acquire some tokens through minting or transfer, when you need to transfer these tokens later, you do not need to spend the transaction that allowed you to obtain these tokens.
In other words, these tokens are not actually associated with Bitcoin UTXOs, and their state is completely determined by the inscriptions that have been written in blocks (as well as the order of these inscriptions); changing the state of these tokens does not require you to have the ability to unlock a specific UTXO.
(The only thing that requires UTXO association is the two steps of the transfer operation, see below for details)
This design has a significant impact on the security, economy (scalability), and decentralization of the protocol. First of all, because it is not associated with UTXOs, it naturally cannot rely on the anti-double spending mechanism of UTXOs themselves. BRC 20 is built entirely on the "first come, first served" principle based on the order of block transactions. Without this "first come, first served" as the final backing, it simply cannot prevent negative balances and other forms of double spending.
However, the validation mechanism based on blocks instead of UTXOs also makes it impossible to create a lightweight validation mechanism. Regardless, you still need the full block data to find the state of an account. (But protocols like RGB and Taro that are based on UTXOs do not require this. They only need the block headers.) This also means that nodes that can afford balance calculation and indexing will be fewer, resulting in poorer decentralization.
Perhaps to reduce the burden of calculating the latest state (detecting counterfeit coins), BRC 20 defines a strange transfer mechanism: no matter how you obtain tokens, your transfers must be divided into two steps: first, convert some tokens into a "transferable" state (and specify the receiver); second, actually transfer these tokens out and thereby invalidate the "transfer inscription" from the first step. Your recipients must do the same.
This mechanism certainly affects user experience and economic efficiency. No matter how much discount you can get from the inscription mechanism, making an extra transaction is enough to offset the benefits. In addition, this strange mechanism that does not utilize UTXOs also creates obstacles when using Bitcoin UTXO-based smart contracts such as Lightning Network and DLC, lagging behind the latest generation of protocols.
So I say, BRC 20 is a backward technology. When the next generation of token issuance protocols can achieve lightweight clients, lower economic costs, and easier integration with the existing Bitcoin ecosystem, BRC 20 still remains at the level of achieving programmability by consuming block space. You can imagine what awaits BRC 20 when protocols like RGB and Taro emerge in the ecosystem!
Ironically, although the minting and transfer of BRC 20 tokens clearly do not require associations on UTXOs, it has designed a "limit" mechanism for token minting—when minting tokens, the number of tokens that can be minted by a single UTXO can be specified as an upper limit. You should be able to guess what this is for.
That's right, it is to meet the fairness requirements in the "IPO" scenario.
It cannot allow one person to mint all the tokens with a single output, so it has this restriction. But think about it, when UTXOs are needed as placeholders, these UTXOs are bound to be small UTXOs—the more you divide your funds, the more new tokens you can get. The result is the inflation of the UTXO set.
These UTXOs used for IPOs are explicitly planned to be 546 satoshis (P2PKH output) / 330 satoshis (P2TR output), which is just at the level of Bitcoin Core's dust output limit. Spending them is uneconomical, and subsequent transfer operations do not require spending them, so they are likely to remain in the UTXO set forever, causing irreversible inflation of the UTXO set.
Transfer operations also leave behind UTXOs. Although theoretically these UTXOs are not needed because they are small amounts, in the current engineering implementation, small UTXOs are still used. And because BRC 20 does not require the characteristic of coherent spending of UTXOs, they are permanently left in the UTXO set.
The chart shows that since April 23, 2023 (when BRC 20 started trading), the UTXO set of Bitcoin has expanded from 5 GB to 6.8 GB. I cannot prove that all the expansion is related to BRC 20, but the growth curve during this period is much steeper than the original one. It needs attention.
Resist it. If you are a node, you can add a line like this to the node's configuration file: dustrelayfee=0.00005 , which will increase the threshold for dust outputs by 5 times (the default value of this value is 0.00001 , you can adjust it as appropriate). If your node used to forward BRC 20 transactions with dust outputs, now your node will no longer forward transactions with outputs below 2730 satoshis/1650 satoshis.
However, if these transactions can enter the block, your node will still keep these transactions and their outputs. If you are a developer, please consider developing filters that identify BRC 20 transaction outputs to help us remove these newly minted outputs and transfer outputs from our UTXO set. Personally, I would choose to run such a filter. Take action to protect the Bitcoin network.
IOS
Android