Suggestion: Deletable Accounts

[JoelKatz]

The 20 XRP reserve requirement has proved to be a bit of an obstacle to some use cases for the ledger. This proposal would provide a path to delete existing accounts, recovering all but one incremental reserve (currently 5 XRP). This would also allow owners of unwanted accounts to clean them up and recover approximately 15 XRP in the process.

There is a judgment call involving what to permit an account to have and still be deleted. In principle, you could allow an account to be deleted regardless of what ledger objects it owned and clean up any problems after the fact. For example, if code later encountered an order, trust line, or escrow for a non-existent account, it would simply handle it appropriately at that time. Orders, for example, would be deleted when discovered to be orphaned. However, that’s probably not optimal. It’s probably sensible to require that some amount of cleanup be done prior to allowing an account to be deleted.

In addition, all code that looks up accounts for trust lines, offers, escrows, and the like must be carefully audited to ensure it sanely handles a non-existent account. Due to the severe harm aberrant behavior could cause to those relying on the ledger, this audit is essential even if the implementation intent is that an account cannot be deleted while those objects exist.

There is a standard draft for this suggestion: https://github.com/xrp-community/standards-drafts/issues/8

This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/

You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 

[Guest]

I'd love to get the reserve XRP from my old accounts. Enough money to invite some friends to dinner in a good restaurant.

[RareData]

For code simplicity and reducing the risk of severe harm to the XRP ledger, in case the audit does miss something, I strongly suggest the account has to do a full cleanup. If the intention is to delete an account, the owner typically wants to recover locked XRP above the minimum account reserve anyway.

[mDuo13]

The public spec defines a transaction that the account owner sends, which tracks down everything tied to the account that can or can't be deleted, and does that if possible. I think that's a great approach. (Actually, the spec itself is just fantastic work. Thanks especially to Scott Schurr for putting a ton of research effort into the thing.)

[Sukrim]

54 minutes ago, RareData said:

For code simplicity and reducing the risk of severe harm to the XRP ledger, in case the audit does miss something, I strongly suggest the account has to do a full cleanup. If the intention is to delete an account, the owner typically wants to recover locked XRP above the minimum account reserve anyway.

It would be trivial to DoS someone then by opening an Escrow of 1 drop until the year 9000 towards the victim.

[Hodor]

3 hours ago, JoelKatz said:

The 20 XRP reserve requirement has proved to be a bit of an obstacle to some use cases for the ledger. This proposal would provide a path to delete existing accounts, recovering all but one incremental reserve (currently 5 XRP). This would also allow owners of unwanted accounts to clean them up and recover approximately 15 XRP in the process.

 

I really like this idea (in principle) and I'm amazed at the amount of deep 'scenario' thinking that @nikb has put into it here: https://github.com/xrp-community/standards-drafts/issues/8

If it's safe and well-planned, then I support this amendment.  But if it puts the ledger at any degree of significant risk, I'd probably opt to pass on it. 

 

[nikb]

52 minutes ago, Sukrim said:

It would be trivial to DoS someone then by opening an Escrow of 1 drop until the year 9000 towards the victim.

Yes, there are "creative" ways to prevent an account from being deleted—at a cost. It's an unfortunate reality. There are potential workarounds, but it's a cat-and-mouse game which, ultimately, affects usability.

[nikb]

On 10/2/2019 at 8:57 AM, Hodor said:

 

I really like this idea (in principle) and I'm amazed at the amount of deep 'scenario' thinking that @nikb has put into it here: https://github.com/xrp-community/standards-drafts/issues/8

I appreciate the kind words, but most of the "deep 'scenario' thinking" is by my coworker, Scott Schurr.

[RareData]

1 hour ago, Sukrim said:

It would be trivial to DoS someone then by opening an Escrow of 1 drop until the year 9000 towards the victim.

I was mostly referring to objects placed by the account under deletion. Performing the DoS you described would cost an attacker >= 5 XRP + 1 drop per account.

[kanaas]

Doesn't this hold a bit more risk of bloating the ledger? Easy delete invites to easy create....
As even after being deleted... the account forever will stay in the ledger.
Not? 

Edited October 2, 2019 by kanaas

[Sukrim]

4 hours ago, RareData said:

I was mostly referring to objects placed by the account under deletion. Performing the DoS you described would cost an attacker >= 5 XRP + 1 drop per account.

Ripple sells a multiple of the XRP amounts necessary too block every existing account so far every single month.

[Jerrybo]

I assume "delete" means "balance of 0". What is the problem that needs to be solved here? Your suggestion of deletable account sounds more like a concrete solution for a specific problem to me. I don't know exactly the problem that needs to be solved. Could you elaborate the problem please? I aim to keep all participants to speak of the same problem.

If I assume the problem is the locked 20 XRP, I don't see any need for a change for the ledger. As a solution for that problem, I think we should discuss possibilities to reduce that fee. Why don't the validators just vote and change for a reduction to 5 XRP for example?

[yxxyun]

39 minutes ago, Jerrybo said:

I assume "delete" means "balance of 0". What is the problem that needs to be solved here? Your suggestion of deletable account sounds more like a concrete solution for a specific problem to me. I don't know exactly the problem that needs to be solved. Could you elaborate the problem please? I aim to keep all participants to speak of the same problem.

If I assume the problem is the locked 20 XRP, I don't see any need for a change for the ledger. As a solution for that problem, I think we should discuss possibilities to reduce that fee. Why don't the validators just vote and change for a reduction to 5 XRP for example?

delete not just means balance of 0, it can reduce the memory usage, node don't need to load deleted accounts state to memory. 

Edited October 3, 2019 by yxxyun

[XRP-JAG]

I suspect the real challenge is how to keep the reserve high enough to make account creation for the purposes of spam at bay, but yet with a reserve realistic for use all over the world.

At ATH prices, talking $80 USD in reserve, which is some money. If you talking about serving the unbanked in Ghana... that’s roughly 6 months salary - ouch.

[Guest]

3 hours ago, XRP-JAG said:

I suspect the real challenge is how to keep the reserve high enough to make account creation for the purposes of spam at bay, but yet with a reserve realistic for use all over the world.

At ATH prices, talking $80 USD in reserve, which is some money. If you talking about serving the unbanked in Ghana... that’s roughly 6 months salary - ouch.

I’ve always thought that the end game situation would probably not be individual wallets except in less usual circumstances.

That ultimately,  institutional storage in a pooled wallet would be the most common way that people store their XRP.  So Reserve is not applicable.  I mean, after all,  that’s what we do with our Fiat funds.

Of course that leaves a gap for the unbanked that will need to be resolved.  I suspect inexpensive providers using apps on phones doing the XRP equivalent of Internet Banking will be the solution there.  
 

In a way it depends largely on whether Moore’s Law is truly broken down for the future.  Heavy on-chain objects are not so much of a problem if the hardware is advanced enough.