BRC-20 and "client verification": you should not continue to buy tokens issued with these "protocols"

2023-05-09 16:01

Read this article in 8 Minutes

AI summary

View the summary

Original source: @AurtrianAjian, BTCStudy content contributor

BRC-20, the meaning of on-chain and "client verification" : Why you shouldn't keep buying tokens issued with these "protocols" - they can't be called protocols at all.

There is only one thing in the Bitcoin protocol: UTXO, the output of Bitcoin transactions, its amount represents its value (in "Satoshi" as the unit ), its "ScriptPubKey (script public key)" represents its spending conditions (unlocking conditions).

Opcodes that can be used to script public keys are provided by Bitcoin's consensus rules. The significance of these opcodes is to program verification conditions (such as single signature, multi-signature, time lock, etc.), so as to set the spending conditions (locks) for a bitcoin UTXO; but it cannot be used to define any we want the rule of.

In other words, Bitcoin script cannot be used to create a UTXO that is not Bitcoin, nor can it be used to make arbitrary security mechanisms (in fact, the two are the same thing). Therefore, if you want to issue assets on the Bitcoin chain, you can only rely on the "off-chain protocol", and Omni, Counterparty, RGB, Taro, and Ordinals are no exceptions.

The key point is that since the script public key (the verification program understood by the Bitcoin network) cannot be programmed arbitrarily, the assets issued by these off-chain protocols, no matter what data is written to the chain, cannot be transformed into the security of these assets. mechanism. For example, if you issue an asset, no matter what data you write to the chain, it is impossible to require the Bitcoin network to control the inflation of this asset.

The Omni protocol uses OP_RETURN output to record transaction data, and Ordinals NFT uses a specific format (inscription) to load content, but none of these things can enter the script public key and cannot be a meaningful security mechanism. So, how to add these custom rules?

The answer is:

( 1) We need the buyer of the asset to run an additional verification procedure (evidence provided by the buyer) to verify the attributes of the asset sold by the seller. This is the so-called "client validation". For example, the buyer verifies that the asset sold by the seller has the signature of the asset issuer to verify that it is a "genuine currency";

(2) Assets should be "attached" to a certain UTXO, so that Bitcoin transactions can become evidence of off-chain transactions (witness), and prevent the same asset from being spent repeatedly (because it is impossible for a UTXO to be spent twice).

These custom rules, assuming it can support a secure protocol based on client verification, can of course be written into the Bitcoin blockchain, but such operations cannot increase security, because real security From client authentication. What the Bitcoin protocol does is to prevent UTXO from being spent repeatedly, while allowing the use of Bitcoin scripts to write methods for such assets to be transferred on the Bitcoin chain.

The current Inscription method of exposing content through witness scripts only plays the role of (2) above, that is, marking special bitcoin transactions and preventing double spending, but as long as it does not require the client to run additional verification , it is impossible to add customized rules for these NFTs or FTs.

(1) Attaching assets to UTXO does not require you to fully publish the content of the assets on the chain;

(2) Writing the data provided for asset transfer to the chain will consume a lot of space, and the economy is extremely poor. This is meaningless, and the same effect can be achieved by providing these data to the buyer off the chain (the idea that putting it on the chain can prevent loss is also suspicious, and its existence does not mean that you can get it back)

So, please stop buying Tokens issued using the Inscription method until the developers of these Tokens provide rules that allow client-side verification, otherwise you buy All that enters is air, without any protection. Developers, if you really care about your users, please first imagine such a client validation rule and implement such a client.

Many friends entered this ecology from other communities, often with inherent cognition to understand Bitcoin, But things that make sense on other chains may not necessarily make sense on Bitcoin. Please understand Bitcoin well, understand the client verification paradigm, and understand the wisdom of handing over all other assets to off-chain protocols. Gaining programmability by consuming block space (consensus resource) is doomed to a sad end in terms of scalability and privacy.

If you want to find the most complete idea on "client verification", please understand the RGB protocol: https://btcstudy.org/tags/RGB/ ,

RGB wallet and tool library: https://rgb.info/zh/home/

Another RGB website: https://t.co/8SG3T1ld6k