Asset Pruning/Burning

[UkolovaOlga]

Open questions:

1. Which term to use?
2. Do we need the ability to prohibit Burning/pruning?
3. Do we need to restrict burning rights to a single UTXO only?
4. Do we need to add proofs metadata to the pruning transaction?
5. Do we need to allow the removal or pruning rights at all?

Possible Options:

1. Disallow procedure for all RGB-20 fungible assets (remove from Schema).
2. Leave as is.
3. Add ability to add custom (of many possible types) proofs Allow asset issuers to mark them required in Genesis.
4. Add epochs mechanism with eventual validation.
5. Combination of 3 & 4.

[UkolovaOlga]

Related to 'Accountable pruning procedure for fungible assets schema (RGB-20)'
#27

[BitcoinErrorLog]

1. To Bitcoiners, "burning" means to send BTC somewhere it can never be retrieved or used again. Pruning is better.
2. If an asset can be issued that users know cannot be pruned, it could be useful, but I am not sure that usefulness overlaps with anyone wanting share that much history. Nice to have the option, not sure if it will get used a lot.
3. I don't understand. Basically a function that requires issuers to reveal current state? prove current issuance, or?
4. Ah ok I recall this conversation now. Generally, any feature that would allow an issuer to prove honesty and issuance will be useful.

[dr-orlovsky]

My epochs proposal:

[dr-orlovsky]

Some USDT stats:

• tens of millions of past owners; be prepared for hundreds of millions (= possible number of nodes in history DAG)
• graph structure with hubs: better to have prunning at that point, otherwise we will quickly end up with one "global" graph of enormous size
• average size of state transition with two outputs (change and payment) will be ~1kb
• historically on Ethereum USDT had >10m transitions, implying >10gb of proof data in a year if we will have no prunning at hub level

[dr-orlovsky]

Outdated by RGB-WG/rgb-node#19