There is no specific consensus on the destruction of BRC-20; it is generally believed that transferring the asset to an address with a publicly recognized unknown private key constitutes destruction. We hope to recommend a universal method for the destruction of BRC-20 assets, which is to:
Send the TRANSFER transaction to an OP_RETURN script that contains no data, to achieve destruction.
There are two main advantages to this method of destruction:
OP_RETURN transactions can be proven to be unspendable within the Bitcoin protocol.
It is the least expensive method since the OP_RETURN script only requires a single 6a byte and merely needs an inclusion of 1 satoshi.
For the BRC20 assets that have been burned, they cannot be minted again. The meaning of ‘max’ is the total upper limit of all minted assets, not the upper limit of the existing number of assets.
The downside of this approach is the lack of widespread consensus and the absence of ready-made tools to facilitate this destruction process.
Using conventional special addresses for asset destruction would result in significant waste.
For Bitcredit Protocol, we want to emulate the Issue/Burn mechanism of the BISQ coloured coin. This gives a perpetual method to reward a project’s developers for maintenance and improvements. ‘Burnt’ tokens will simply be redistributed to devs at the end of the epoch.
I propose to implement this by sending ‘burnt’ tokens to the address of the inscriber of a "self-mint’ BRC-20. All this means that any treasury tokens held by that address must be deducted from actual supply, kind of like a treasury stock. As soon as the tokens are sent from the inscriber address to a dev, they reappear in active supply.
“In 2013, an easy way to add data to any Bitcoin transaction was introduced. By making standard a previously invalid script instruction, OP_RETURN, a Bitcoin user could add up to 40 bytes of data to his transactions. The introduction this new output allowed Bitcoin nodes to prune this kind of output from their memory as they cannot be spent thereby limiting what developers called blockchain bloat. And since its introduction, more than 3.66 BTC have been spent in OP_RETURN outputs and the number of these outputs keeps growing.”
On another topic, have there been any proposals regarding how transfer inscriptions could potentially become unnecessary?
that’s what will happens after unisat modular, because you will not need to send inscriptions using sats, you can just use off sheet balances to settle these transitions, like the banks do.
its what the off shore banks likes, and what they used to do :D.
alot of thinking on brc20 and ordainls just normal and regular banking and metal market indexes. " but its on bitcoin ".
That would be somewhat analogous to how the Lightning Network functions from a conceptual standpoint, but have there been any discussions regarding how we could directly and fundamentally eliminate them altogether?
1- ordinals as it stand, is not decentralized - Meaning that, they are few people do the changes and control the GitHub.
2- there is no clear consensus on ordinals or brc20 - few selected people make the changes.
3- there is no incentive to make discussions on anything related to ordinals, like tokens or any form of money - they are using donations.
4- only people who are interested in working on ordinals are the wallets or indexers, not the normal community contributor, making alot of decisions around them.
Sadly there are few people who are working on brc20 or have the skills.
for me personal, I hope we can move forward so ordinals become more popular and more funding to get skilled people join and have more discussions to fix these problems.
Has a consensus been reached on the destruction mechanism for BRC-20 tokens? I’m working on a one-way bridge, and I want to transfer the some of the BRC-20 transactions to an OP_RETURN script that contains no data, but I want to make sure that the indexers will classify that as a burn so that the supply data of the given BRC-20 token decreases accordingly on the various marketplaces.
or read ~