Jump to content
yxxyun

ripple is planning implement deletable accounts

Recommended Posts

40 minutes ago, tulo said:

Smart...

Quote

// We don't want to allow an account to be deleted as long as its sequence

// number is ahead of the current ledger since we use the ledger sequence

// as the account's initial sequence number, to avoid sequence number reuse.

if (ctx.tx[sfSequence] + 1 >= ctx.view.seq())

return tecTOO_SOON;

 

Edited by yxxyun

Share this post


Link to post
Share on other sites

If these objects are otherwise just AccountRoot objects, nearly(?) all current accounts would be deleteable under these rules too. Maybe a one-way flag (similar to NoFreeze) could be used instead of a new object type?

Share this post


Link to post
Share on other sites
14 minutes ago, Sukrim said:

If these objects are otherwise just AccountRoot objects, nearly(?) all current accounts would be deleteable under these rules too. Maybe a one-way flag (similar to NoFreeze) could be used instead of a new object type?

Nearly all current accounts WOULDN'T be deleteable. You need sequence number higher than current ledger. I think I have only one account with sequence > 47M, which reminds me that I burnt close to 40k XRP only on fees on that account :).

Share this post


Link to post
Share on other sites
20 minutes ago, tulo said:

Nearly all current accounts WOULDN'T be deleteable. You need sequence number higher than current ledger. I think I have only one account with sequence > 47M, which reminds me that I burnt close to 40k XRP only on fees on that account :).

I think you misunderstood this.

Share this post


Link to post
Share on other sites
4 hours ago, yxxyun said:

Accounts can only be deleted if they do not own any objects and if the current ledger sequence number exceeds the account's sequence number so that, if recreated, the account can be protected from transaction replay.

Can someone explain this risk please? and how the solution addresses the risk?

Edited by KarmaCoverage

Share this post


Link to post
Share on other sites
2 hours ago, Sukrim said:

If these objects are otherwise just AccountRoot objects, nearly(?) all current accounts would be deleteable under these rules too. Maybe a one-way flag (similar to NoFreeze) could be used instead of a new object type?

The commit doesn’t introduce a new object type. It works on any account and uses regular AccountRoot objects. 

Share this post


Link to post
Share on other sites

I'm not too happy about the default application of a flag that further removes XRPL from the "Ripple" concept of mutual credit (and I'm unsure how this would have to end up in the same amendment as making accounts deleteable), but it is great to see some progress on that front in general, even just as a weekend project. :-)

Share this post


Link to post
Share on other sites

@Sukrim: the reason it’s there is because, without it, someone can open a trust line to you (something that you can’t, otherwise, prevent) which will make the account impossible to delete.

The flag may actually evolve to do more than just prevent trust lines from being opened. Several things can create an owner directory entry.

As I said, this is just something I came up with and decided to just try and implement. It’s not final by any means, and I have no idea if it will ever be merged.

I didn’t intend to make this public; it was just an initial very quick implementation of an idea I had. I absent-mindedly pushed it on GitHub before calling it a day, and here we are.

So, I guess, I welcome comments.

Share this post


Link to post
Share on other sites

Ok, so "not owning objects" is not enough (I don't pay OwnerReserve for incoming trustlines), but it requires a completely clean state (potentially even with no Escrow or Check or PayChan objects out there that could potentially pay me).

Maybe a deleted issuer's account could also just mean that the trust line is frozen, with the additional restriction that not even sending IOUs back to the issuer is possible? That would still have the issue though that there might be accounts referenced that don't exist (any more/yet).

Share this post


Link to post
Share on other sites

Aside from the obvious "Why is this a good idea?" - is a collission issue created should those "old" accounts be recreated again (whether intentionally or 'naturally')?

(Also - uh - maybe I'm misunderstanding - but doesn't this affect account creation/destruction ("reserve") incentive mechanisms - making "reserve" = "xaction fee"?)

Edited by NightJanitor

Share this post


Link to post
Share on other sites
24 minutes ago, NightJanitor said:

Aside from the obvious "Why is this a good idea?" - is a collission issue created should those "old" accounts be recreated again (whether intentionally or 'naturally')?

The code is very carefully written to ensure that recreating an account is supported and will not cause any problems.

 

25 minutes ago, NightJanitor said:

(Also - uh - maybe I'm misunderstanding - but doesn't this affect account creation/destruction ("reserve") incentive mechanisms - making "reserve" = "xaction fee"?)

It does have implications and that’s why I’m not sure if this amendment will ever gain widespread support, or if I can even get enough support to merge it into the codebase.

I was thinking of making the DeleteAccount transaction require one incremental reserve (currently 5 XRP) as a fee.

Share this post


Link to post
Share on other sites

×