Bitcoin OG Viewpoint: Please stop participating in the lagging BRC-20 innovation

The original text is from Twitter, author @AurtrianAjian from BTCStudy; reproduced with authorization, does not represent the views of Odaily

I've heard outrageous things, but didn't know you guys could go this far. Please stop participating in the "BRC 20" campaign and, boycott it.

You should no longer participate, because technically such backward things are bound to be eliminated. You should resist it, because it will cause the expansion of the UTXO set, and the practical consequences of its application are close to dust attacks.

I've written before that something like BRC 20 can't be called a "protocol" at all because it simply doesn't protect the users who use it. But at the time I didn't get to the bottom of it, and I didn't know it was even more outrageous than I thought it would be.

On the surface, BRC 20 defines two operations for fungible tokens: “Mint” and “Transfer”…

In each step of each operation, it is necessary to initiate a Bitcoin transaction and write an inscription (Inscription, write data in the block through the input witness script) in the transaction input. However, in BRC 20, these inscribed transactions form transaction outputs that hardly mean anything. This is where the problem lies. If you look carefully at the document above, you will find that it says:

"BRC 20's balance state can be derived by aggregating the activity of all these functions"; however, the activity of all these functions is manifested through inscriptions, and none of the functions require spending a specific UTXO (or even a specific Satoshi) to be valid. ). Whether you get some tokens through minting or transfer, when you need to transfer these tokens later, you don't need to spend the transaction that allows you to get these tokens.

That is to say, these tokens are not actually attached to the Bitcoin UTXO, and their status is completely determined by the inscriptions (and the order of these inscriptions) that have been written into the block; changing the status of these tokens does not require you to have the ability to unlock a certain UTXO ability. (The only thing that requires a UTXO association is the two steps of the transfer operation, see below for details)

This design has major implications for the security, economics (scalability) and decentralization of the protocol. First of all, because it is not attached to UTXO, naturally it cannot rely on the anti-repeat spending mechanism of UTXO itself. BRC 20 is entirely based on the "first-come, first-served" principle based on block transaction ordering. Without this "first-come, first-served" as the final backing, it cannot prevent the double spending form of negative balance at all.

However, having a verification mechanism based on blocks rather than UTXOs also makes it impossible to create a lightweight verification mechanism. In any case, you need the full block data to find out the state of an account. (However, UTXO-based protocols such as RGB and Taro do not need it. They only need block headers) This also makes the number of nodes that can afford balance calculation and indexing less in comparison, that is, the characteristics of decentralization are worse .

Perhaps in order to reduce the burden of calculating the latest state (identifying counterfeit currency), BRC 20 defines a strange transfer mechanism: no matter how you get some tokens, your transfer must be divided into two steps: the first step is to convert some tokens It is in the "transferable" state (and specify the recipient); the second step is to actually transfer these tokens out, and thus invalidate the "transfer inscription" in the first step. The same goes for your next home.

Such a mechanism of course also affects user experience and economics. No matter how much discount you can get from the inscription mechanism, sending one more transaction is enough to eat back the benefits you get. In addition, this strange mechanism that does not utilize UTXO also makes such tokens inherently increase obstacles when using Bitcoin UTXO-based smart contracts (Lightning Channel, DLC, etc.), and lag behind the latest generation of protocols.

**So I say, BRC 20 is a backward technology. When the new generation of token issuance protocols can achieve lightweight clients, lower economic costs and easier access to the existing Bitcoin ecosystem, BRC 20 is still stuck in the process of obtaining programmability by consuming block space. degree. You can imagine, when the ecology of protocols such as RGB and Taro emerges, what is the end of waiting for BRC 20! **

Paradoxically, although the minting and transfer of BRC 20 obviously do not require the association on UTXO, it has designed a "limit" mechanism for minting - when minting tokens, the number of tokens that can be minted by a single UTXO, It is possible to specify an upper limit. You should be able to guess what this is for.

That's right, this is to adapt to the fairness requirements in the "play new" scenario.

It cannot allow one person to mint all tokens with one output, so such a restriction is designed. But think about it, when you need to use UTXO to occupy the space, these UTXOs must be small UTXOs - the more you cut the funds, the more new tokens you can get. The result is inflation of the UTXO set.

These are used to create new UTXOs, which are clearly planned to be 546 Satoshi (P2P KH output)/330 Satoshi (P 2 TR output), which is only equal to the dust output limit of bitcoin core. It is not economical to spend them, and the subsequent transfer operation does not require them to be spent, so they are likely to stay in the UTXO set forever, causing irreversible expansion of the UTXO set.

Transfer operations also leave UTXO behind. Although these UTXOs are not required to be small in theory, in the current engineering implementation, small UTXOs are still used. And, because BRC 20 does not require UTXO to spend consistently, it is left in the UTXO set forever.

The chart shows that since April 23, 2023 (when BRC 20 opened transactions), Bitcoin's UTXO set has ballooned from 5 GB to 6.8 GB. I can't prove that all the inflation is related to BRC 20, but the growth curve during this time has been much steeper than the original growth curve. Needs attention.

resist it. If you are a node, you can add this line in the node configuration file: dustrelayfee= 0.00005, which will increase the dust output threshold by 5 times (the default value of this value is 0.00001, you can add or subtract as appropriate). If in the past your node would forward BRC 20 transactions with dust outputs, now, your node will no longer forward transactions with outputs lower than 2730 Satoshi/1650 Satoshi.

However, if these transactions make it into the block, your node will still save these transactions and their outputs.

If you are a developer, please consider developing a filter that recognizes BRC 20 transaction outputs to help us remove these new and transfer outputs from our UTXO set. Personally I would choose to run such a filter.

Take action to protect the Bitcoin network.