Jump to content
yxxyun

ripple is planning implement deletable accounts

Recommended Posts

33 minutes ago, Sukrim said:

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).

Yeah, it’s not easy. What would it mean to have an escrow to an account that doesn’t exist, for example? The existing code is written with the assumption that can’t happen.

Allowing an account root to be deleted while still owning objects is a non-starter, in my opinion. 

Share this post


Link to post
Share on other sites
12 minutes ago, nikb said:

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.

Yeah, the way I read it, the "unintended implication" was a backdoor around "reserve"... so.. glad you see that one. :)

I'm still curious what problem it was that you were trying to solve with this change to dynamics;  what's the big idea?

Share this post


Link to post
Share on other sites
Just now, NightJanitor said:

I'm still curious what problem it was that you were trying to solve with this change to dynamics;  what's the big idea?

Tons of people have created multiple accounts that they probably don't want or need any more (including bad actors like Poloniex, but that's besides the point). There should be a way to recoup some XRP and also to get the AccountState size a bit down again to more realistic levels that actually reflects active participants, not collected cruft over the years.

Share this post


Link to post
Share on other sites
22 minutes ago, nikb said:

Yeah, it’s not easy. What would it mean to have an escrow to an account that doesn’t exist, for example? The existing code is written with the assumption that can’t happen.

Allowing an account root to be deleted while still owning objects is a non-starter, in my opinion. 

What's the problem of deleting an account which has trustlines "against" ("toward" maybe?) him. Can't the trust lines be deleted automatically what that happen?

Share this post


Link to post
Share on other sites

Oh... ok... this is like "I was sitting around on friday night de-fragging my hard drive - as you do - and it came to me... what if..."

Got it... Not sure I think it's a good idea (leaning the other way, in fact), but think I got it... :)

Share this post


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

What's the problem of deleting an account which has trustlines "against" ("toward" maybe?) him. Can't the trust lines be deleted automatically what that happen?

No, they can’t. If a trust line goes into its default state, it’s automatically deleted. Since the trust line exists, it means it’s in a non default state.

Share this post


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

Oh... ok... this is like "I was sitting around on friday night de-fragging my hard drive - as you do - and it came to me... what if..."

Got it... Not sure I think it's a good idea (leaning the other way, in fact), but think I got it... :)

Kind of. Actually, the key insight came to me in a dream. :lazy:

Share this post


Link to post
Share on other sites

I don’t know what Stellar is doing or how they’re doing what they’re doing, to be honest.

I have my hands quite full with my own work to go spelunking around other projects’ code repos.

Share this post


Link to post
Share on other sites
7 hours ago, tulo said:

Smart...

Yes, tying account creation to (dream-)sequence number is something I can see as being helpful/protective (over Time).

I like that part.

ETA:  There's some humor in this coming up just before Daylight Savings Time kicks in...  (Always looking for the joke...)

Edited by NightJanitor

Share this post


Link to post
Share on other sites

I have only ever glanced at XRPLedger code so I know nothing...  but...

I understand that the reserve is to stop heavy object spam.  And yet the reserve also means that heavy objects persist long after they are no longer required.

I also see the desire to have a deletion fee to stop the backdoor create/delete circle spam.  But a deletion fee related to the reserve could become problematic for small account holders if the price of XRP rises and the reserve remains constant thereby making the deletion fee higher in value than intended.

What if the ledger maintains a count of accounts created over last n blocks (n is some number of blocks to give a rolling average) and then at account creation sets a cantBeDeletedBeforeBlock value for that account which is (the rolling average X some factor to be decided by you guys) + the current block number.

Simultaneously introducing code to remove the capacity to partially reserve an account would mean that if a spam attempt was made the possible cycle of create/delete would get slower and slower limiting the spam velocity via spacing of deletes and the cost of the reserve.

 

On reflection I can see that a bad actor, who is also a large holder, could afford to still spam and recoup much later.  Also innocent account creators in that period are permanently affected especially if the delay factor goes exponential.

 I leave this here in case my foolishness is a trigger for a better thought in one of you.

Share this post


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

I also see the desire to have a deletion fee to stop the backdoor create/delete circle spam.  But a deletion fee related to the reserve could become problematic for small account holders if the price of XRP rises and the reserve remains constant thereby making the deletion fee higher in value than intended.

What if the ledger maintains a count of accounts created over last n blocks (n is some number of blocks to give a rolling average) and then at account creation sets a cantBeDeletedBeforeBlock value for that account which is (the rolling average X some factor to be decided by you guys) + the current block number.

1) @nikb suggested using the incremental fee (5 xrp instead of 20). At such time that XRP is worth enough to reconsider reserves, both will likely get modified. Supposing a reserve change doesn't happen, then even recouping 15 XRP would still be a win. Someone gets 75% of their value back and ledger health improves.

2) One of the things I find most elegant about XRPL is that it doesn't require the full history to determine state. The n+1 ledger should only require the nth ledger and a set of transactions that occurred since. To maintain an integer representing account creations over n blocks, you'd actually need to store an array of n values, and only one of those values can be verified from a given ledger. I suppose it's possible to assume an even distribution of account creations and do a weighted average of the last number and the proposed ledger's account additions. That is, if you're worried about creations over ten ledgers, then take  .9 * old value + .1 * new accounts. Still, it seems unnecessary. There's a precedent for enforcement by pulling at the purse-strings of would-be attackers (fee scaling, reserves), and it's done the job so far.

@Sukrim - I'm glad someone else's mind went straight to Poloniex. They've been a blight on the ledger for far too long. In a less enlightened time, I sent funds to Poloniex to access a specific alt market. I cringe to think that I'm part of the problem. I couldn't care less about an extra 20 XRP, but I have dreamed of a day where Poloniex would stop abusing the ledger and improve their customer experience in one go. Nik's creating the opportunity.

Share this post


Link to post
Share on other sites
7 hours ago, nikb said:

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

 

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.

I like this,  prevent use DeleteAccount feature to spam ledger. But how to delete this account? Will this change make this account undeletable?

eg I have 4 accounts,  I delete A,B and send XRP to C, then C have to reserve 30XRP,  what will happen when I delete C and transfer XRP to D?

Edited by yxxyun

Share this post


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

1) @nikb suggested using the incremental fee (5 xrp instead of 20). At such time that XRP is worth enough to reconsider reserves, both will likely get modified. Supposing a reserve change doesn't happen, then even recouping 15 XRP would still be a win. Someone gets 75% of their value back and ledger health improves.

2) One of the things I find most elegant about XRPL is that it doesn't require the full history to determine state. The n+1 ledger should only require the nth ledger and a set of transactions that occurred since. To maintain an integer representing account creations over n blocks, you'd actually need to store an array of n values, and only one of those values can be verified from a given ledger. I suppose it's possible to assume an even distribution of account creations and do a weighted average of the last number and the proposed ledger's account additions. That is, if you're worried about creations over ten ledgers, then take  .9 * old value + .1 * new accounts. Still, it seems unnecessary. There's a precedent for enforcement by pulling at the purse-strings of would-be attackers (fee scaling, reserves), and it's done the job so far.

@Sukrim - I'm glad someone else's mind went straight to Poloniex. They've been a blight on the ledger for far too long. In a less enlightened time, I sent funds to Poloniex to access a specific alt market. I cringe to think that I'm part of the problem. I couldn't care less about an extra 20 XRP, but I have dreamed of a day where Poloniex would stop abusing the ledger and improve their customer experience in one go. Nik's creating the opportunity.

I appreciate your feedback but disagree with parts of your conclusion...  but I am not really competent to be debating this...  So probably I'm wrong...  :) 

Point 1.  Yes it's "only" 5 XRP...   but that could represent a months pay to a third world person even in the near to mid term future.  That's the issue...    Of course it's all variable but these things tend to gather inertia...  So although they could be adjusted,   a lot of (let's call it) unfairness can happen in the meanwhile or perhaps they won't be adjusted even though it is hurting lower income people.  (Not saying that's the case now...  But it could become like that)

Regarding your point 2.   To know the number of ledger creates over some period you only need to carry the counts forward and add in each new ledgers' contribution dropping the oldest.  You do not need a large array....  So that's not much of an overhead and will scale because it doesn't grow (perhaps only if the speed of ledger closes increases...  And then the growth will only be linear and limited to infrequent speed scale steps) so again not a significant cost.  As elegant as it all is,  you do have some overheads and this is not much of an addition.

Quote

There's a precedent for enforcement by pulling at the purse-strings of would-be attackers (fee scaling, reserves), and it's done the job so far.

If that were true then we wouldn't be having this conversation.

 

But as I said at the end of my post...  on reflection it's not really a good solution...  I just proffer it in case it has any elements that might be used for a better solution.

Share this post


Link to post
Share on other sites

×
×
  • Create New...