EIP-33: Token burning during rent collection

[scalahub]

Basic description of the potential problems we have with freeing up locked tokens and how to solve it.

[K-Singh]

Just posting what I put in discord -

This removes a potential path for miner profitability when claiming low value utxos for storage rent. It also ensures that valuable tokens left in dead addresses are unable to reap some of the benefits of Ergo's storage rent mechanism. Is there anyway to reconcile these problems with this EIP?

[glasgowm148]

I don't think burning value is wise/efficient. Could it be placed in a box only redeemable by an address generated by the same private key? Or in a DAO who could opt to burn any tokens which pose a security risk before it was passed back to the miners.

[aslesarenko]

I don't think burning value is wise/efficient. Could it be placed in a box only redeemable by an address generated by the same private key?

Blockchain storage is scarce resource and should be payed (this is the idea of storage rent).
If the asset is valuable, just put enough ergs for 50 years. (note the demurage happens only once in 4 years and percent is small).
This is important for ERG tokenomics.

Also, taking care of rent can be done automatically by wallets, i.e. every wallet can automatically take care of the boxes, and create renewal transactions ready for user signature.

On the other hand if the key is lost, one cannot prove ownership of the address and hence ownership of NFT. (Like everybody claiming he is Satoshi, is asked to spend his box, and nobody did it yet)

Thus, if ownership is lost, then NFT effectively becomes public, in fact provably-public.
Such NFTs can be sold again and the whole history will remain in blockchain.
This is similar to what would happen to real valuable assets in case owner is lost/unknown.

[glasgowm148]

Blockchain storage is scarce resource and should be payed (this is the idea of storage rent).

I agree, but storage is also cheap and charging a premium to redeem after storage rent collection could fund the storage during this time and give people a last opportunity to reclaim if they had assets in a UTXO which got collected unknowingly (ie, they moved erg often, but an NFT had remained unmoved since first bought). Although I suppose this is maybe overcomplicated and wallets will solve this problem ideally and promptly notify people when this is the case.

Thus, if ownership is lost, then NFT effectively becomes public, in fact provably-public. Such NFTs can be sold again and the whole history will remain in blockchain.

So they could be put up for auction automatically, with the proceeds going back into emissions? I agree this would be advantageous to burning, and if I understand correctly, the fact that it has been collected via storage rent will allow us to mitigate any risk by checking if it has been recycled? (ie; DAO tooling could ignore votes from vote tokens that had been recycled via storage rent)

[aslesarenko]

So they could be put up for auction automatically, with the proceeds going back into emissions?

Maybe not auction. The asset can be sent by the miner to a special contract controlled by EF or community DAO. The miner will not get ERGs immediately, but the contract will require compensation for the miner at the time EF or DAO spending the box.
How EF/DAO spending will be done is independent issue and can be solved elsewhere.

[aslesarenko]

the fact that it has been collected via storage rent will allow us to mitigate any risk by checking if it has been recycled?

Yes, for any token which was burned we can calculate wasBurnedOn date and time (transaction and height) from blockchain data so this is part of consensus.
I'm not sure if this can be done easily using existing explorer data for example, but it can be done.

[aslesarenko]

Also, another idea is to extend EIP4 so that asset issuer can specify special lifecycleConfig, which can in particular contain burnOnRentCollection flag.
When such flag is set, then the asset can be just burned.
All existing assets will not have this flag, and hence will not be burned and their lifecycle should be regulated by some predefined defaultLifecycleConfig (which is also not stored for all existing assets)
If the burnOnRentCollection is explicitly set to false, then lifecycleConfig properties should also be set explicitly and then miners will just follow the configuration.

So transfering box to EF/DAO can be one case of lifecycleConfig settings.

[kushti]

So they could be put up for auction automatically, with the proceeds going back into emissions?

Maybe not auction. The asset can be sent by the miner to a special contract controlled by EF or community DAO. The miner will not get ERGs immediately, but the contract will require compensation for the miner at the time EF or DAO spending the box. How EF/DAO spending will be done is independent issue and can be solved elsewhere.

Introducing EF/DAO/any other trusted party into the core protocol should be no-go I suppose

[glasgowm148]

While that's a good rule of thumb, they would have no backwards control over the protocol, the only thing they’d get is the output which is burned in the alternative scenario. EF, I would agree shouldn’t be included, it would be easy for them to collude and snatch all the rare ergnomes. However a DAO of all ergo holders (via anon's collective spending approach)? Or doing anything but burning it - stashing it away somewhere until we can figure out what to do with it, would be a better idea IMO.

Unless there is some scenario I'm missing?

The DAO could evaluate the asset and liquidate it and pass it on to miners if appropriate, or if it was something like a bank quorum key or oracle NFT, they’d probably opt to return it. Better as a DAO of every ergo stakeholder could decide that rather than mining pools. Maybe we could even distribute DAO tokens to addresses proportional to their mining rewards over time if we wanted a miner DAO.

[kushti]

From comments, I do not see enough support

[kushti]

Also, another idea is to extend EIP4 so that asset issuer can specify special lifecycleConfig, which can in particular contain burnOnRentCollection flag. When such flag is set, then the asset can be just burned. All existing assets will not have this flag, and hence will not be burned and their lifecycle should be regulated by some predefined defaultLifecycleConfig (which is also not stored for all existing assets) If the burnOnRentCollection is explicitly set to false, then lifecycleConfig properties should also be set explicitly and then miners will just follow the configuration.

So transfering box to EF/DAO can be one case of lifecycleConfig settings.

EIP-4 is not a part of the core validation protocol.

[glasgowm148]

(Edit: nvm realise why this is dumb - we could send them an NFT in hopes they seen it though.)

With block 1,051,200 fast approaching (~July 20th) and in lieu of any concrete proposal. I suggest scanning all boxes that will be due to pay storage rent and airdropping ones that are likely to cause issues with a small amount of ERG. This could be raised by the community and maybe an inconsequential amount anyway compared to the harm it would cause for people to lose access to valuable assets.

While we have TokenJays Box consolidation tool, safeguards aren't integrated seamlessly enough yet to ensure active users don't get burned.

[glasgowm148]

Rough list of tokens that will be available

https://docs.google.com/spreadsheets/d/1UWwtBXup8gmbjEZNDwuhb7uW8HLdKqh8ofl80Vy7Xjc/edit?usp=sharing

[kushti]

(Edit: nvm realise why this is dumb - we could send them an NFT in hopes they seen it though.)

With block 1,051,200 fast approaching (~July 20th) and in lieu of any concrete proposal. I suggest scanning all boxes that will be due to pay storage rent and airdropping ones that are likely to cause issues with a small amount of ERG. This could be raised by the community and maybe an inconsequential amount anyway compared to the harm it would cause for people to lose access to valuable assets.

While we have TokenJays Box consolidation tool, safeguards aren't integrated seamlessly enough yet to ensure active users don't get burned.

Box is immutable entity, you can not modify it (by e.g. adding Ergs). Storage rent is the only exception for the immutability