Implement pruning with a secondary issuance for fungible assets RGB schema (RGB-20)

[afilini]

The current schema for the RGB1 and 2 protocols treats pruning and secondary issuances differently: in order to make a secondary issuance, the issuer would have to spend some "special" seals that would make it obvious to any external observer that a secondary issuance had happened, to prevent the issuer from inflating the supply of an asset undetected.

Pruning, which is essentially a burn-and-then-secondary-issuance, instead is implemented in a different way, that doesn't require the issuer to spend the "secondary issuance" seal, probably to avoid "alterting" all the external observer every time the pruning occurs.

However, since there's no cryptographic "constraint" that forces the issuer to burn and then re-issue the exact same amount of tokens, the issuer could use a pruning operation to inflate the supply of the asset, with the added bonus that it would be able to clain, and cryptographically prove, that it had never spent the secondary issuance seals.

[dr-orlovsky]

So am I right that with this proposal in practice when we have pruning enabled the issuer have to define that the supply is unlimited and nobody will know how many assets were actually issued and how many was pruned?

[dr-orlovsky]

Outdated by RGB-WG/rgb-node#27

See also:

• Possible proofs for fungible assets pruning in RGB-20 #28
• Accountable pruning procedure for fungible assets schema (RGB-20) #27