Topic: CBRC-20: The successor of BRC-20 (Read 70 times)
The problem the Bitcoin network is congestion due to which high transaction fee have become common. If this new token can reduce congestion then automatically the fees would go down. As BRC-20, the new token CBRC-20 would do the same thing and that would be spamming the Bitcoin network. I am not against the development but I am not happy how they are making it look bad for Bitcoin.
brc-20 actually increased activity in relation to the blockchain before since cbrc-20 is a more developed version of this which will allow for more benefits such as less expensive fees i am guessing that this will allow for more user activity with the coin
CRBC20 will pump
Recently the CBRC-20 token format from the Cybord project was published. It is an improvement of BRC-20, the Ordinals-based token format, which is available on Bitcoin, Litecoin and some other chains like Groestlcoin (GRS).
On its website Cybord.org you can find lots of info, from technical data to examples.
What is CBRC-20?
CBRC-20 tokens work exactly like BRC-20 tokens. They can be minted and transfered with the Ordinals inscription mechanisms, which use a data item in a Taproot transaction.
However, they consume less data, and thus the fees that have to be paid are smaller. I have investigated a bit: On a standard inscription you can save about 10-15% of the bytes, and thus of the fees.
For example, a BRC-20 mint transaction pair with 400 bytes could be reduced to about 360.
How do CBRC-20 transactions save data?
BRC-20 transactions store the data in a very inefficient way: as JSON text. This means you have to use bytes for all brackets, colons, commas and other special characters. An example:
CBRC-20 uses a new field added in newer versions of the Ordinals protocol: the Metaprotocol field. There, the same values are stored in the following way:
It is obvious that this consumes much less bytes: 21 instead of 52.
But take into account this only makes the "content" part smaller, which in normal BRC-20 transactions had about 50-60 bytes. The rest of the transaction (inputs and any coin-transferring outputs), which are at least 250-300 bytes more, is identic.
Personal opinion
I still think that CBRC-20 is quite inefficient due to the overhead of ~50-110 bytes for the commitment transaction or output. For all ordinals-based protocols, you need two transactions (or a transaction and an additional output of another transaction). And I think on the Bitcoin chain only the most efficient token mechanisms, which put lots of the data offchain, like RGB and Taproot Assets should be used.
However, I would not be against to these tokens used on chains like LTC and GRS, where you can create these tokens almost for free.
It has to be noted however that even this format can still be improved, for example using Google's Protobuf format. In CRBC-20 you have to store the colons too as text, while in protobuf, you would use a binary data blob, which would save additional bytes (perhaps 5 to 10 depending on the operation).
On its website Cybord.org you can find lots of info, from technical data to examples.
What is CBRC-20?
CBRC-20 tokens work exactly like BRC-20 tokens. They can be minted and transfered with the Ordinals inscription mechanisms, which use a data item in a Taproot transaction.
However, they consume less data, and thus the fees that have to be paid are smaller. I have investigated a bit: On a standard inscription you can save about 10-15% of the bytes, and thus of the fees.
For example, a BRC-20 mint transaction pair with 400 bytes could be reduced to about 360.
How do CBRC-20 transactions save data?
BRC-20 transactions store the data in a very inefficient way: as JSON text. This means you have to use bytes for all brackets, colons, commas and other special characters. An example:
Code:
{
"p": "brc-20",
"op": "mint",
"tick": "TOKX",
"amt": "200"
}
"p": "brc-20",
"op": "mint",
"tick": "TOKX",
"amt": "200"
}
CBRC-20 uses a new field added in newer versions of the Ordinals protocol: the Metaprotocol field. There, the same values are stored in the following way:
Code:
cbrc-20:mint:TOKX=200
It is obvious that this consumes much less bytes: 21 instead of 52.
But take into account this only makes the "content" part smaller, which in normal BRC-20 transactions had about 50-60 bytes. The rest of the transaction (inputs and any coin-transferring outputs), which are at least 250-300 bytes more, is identic.
Personal opinion
I still think that CBRC-20 is quite inefficient due to the overhead of ~50-110 bytes for the commitment transaction or output. For all ordinals-based protocols, you need two transactions (or a transaction and an additional output of another transaction). And I think on the Bitcoin chain only the most efficient token mechanisms, which put lots of the data offchain, like RGB and Taproot Assets should be used.
However, I would not be against to these tokens used on chains like LTC and GRS, where you can create these tokens almost for free.
It has to be noted however that even this format can still be improved, for example using Google's Protobuf format. In CRBC-20 you have to store the colons too as text, while in protobuf, you would use a binary data blob, which would save additional bytes (perhaps 5 to 10 depending on the operation).
Jump to: