Jump to content
Sukrim

Time to increase the owner reserve?

Recommended Posts

XRPUSD price is irrelevant in the short term and the reason there are so many low value wallets out there is not that there are so many individual users on XRPL. The reason is that companies spam the ledger with user funds. Instead of looking at rich lists, look at how many accounts have made even just a handful of transactions in total. Ever. There are millions of XRP already locked up by this for no reason at all.

I am also not looking to win people over by offering a cheap public resource that can be spammed and clogged at will while making it impossible without a high investment to even run a node. I would rather win them over with the best blockchain and decentralizes exchange out there. This is presently at risk.

Gatehub is free to vote against this with their validator(s) by the way.

In the end I doubt that it would come that far anyways, but there is no other way at the moment to increase pressure to bad actors since it is not something that can be solved by regulation. Reserves are a market mechanism. Time to use it.

Share this post


Link to post
Share on other sites

I think raising the wallet opening fee to 1000 XRP would be ludicrous. Especially as we are expecting the value of XRP to increase over time. I know it could be dropped again, and I know you mention this could just be a temporary thing... but I think the adverse publicity would far outweigh any benefits.

I've been talking to a startup about potentially using Ripple for their reward points scheme. As it stands I'm not quite sure how we'd swing it as it would cost us the current ~$5/wallet just to onboard a new customer. Let alone if the cost was ~$200.

-Matt

Share this post


Link to post
Share on other sites

Ledger account spam is a known issue, believe me. (Some exchanges are more, uh, communicative than others.)

There are several barriers standing in the way of deleting accounts, the main one being transaction replay. If you fully delete an account, you lose track of its sequence number and so you could send old transactions again if you re-created it. (And of course, if you fully delete the account, you have no idea whether it used to exist or not.)

And even if there was a way to delete or compact accounts, that mechanism couldn't refund people the account reserve, or else people could spam the ledger with accounts for as long as they wanted, then get all their money back (effectively losing nothing) whenever they decided they were done.

Share this post


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

Why not allowing deleting the accounts as already discussed many times? It's a much more elegant way IMO.

Uhm... forget, the real technical issues with deleting AccountRoot objects. But how does it help to delete them?

Share this post


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

To quote https://ripple.com/build/reserves/:

"The goal is to constrain the growth of the ledger to match improvements in technology so that a current commodity-level machine can always fit the current ledger in RAM and the full ledger history on disk."

Full ledger history is at around 6 TB (of SSD storage, but that's mainly an architectural limitation of SHAmap) which is already at the higher end of HDDs. RAM usage after starting up rippled with --load is around 4 GB, which also is a bit on the higher end (after all, the operating system also needs some space and once the server starts caching a few nodes it'll get crammed in there).

Yet even with increasing prices in USD, https://xrpcharts.ripple.com/#/accounts still increases at an unsustainable rate (note that the y-axis is NOT linear for "accounts created"). Most of these accounts seem to belong to entities that force their customers to pay for account activation while not giving them access to the private keys of these accounts. This needs to be disincentivized.

I propose for validator operators to announce to harshly increase the owner reserve in 3 months time for at least a month to 1000 XRP until new account spam visibly has decreased and malicious businesses have changed their practices. The announcement alone might already be enough to cause these malicious actors to cease their bad practices, as it likely would be cheaper for them to just implement XRPL integration correctly (with destination tags instead of unique addresses) than to stem the tide of support tickets and angry customers that are now forced to lock up a few hundred USD worth of XRP. Businesses using XRPL correctly wouldn't be affected since they don't constantly have to fund new accounts anyways.

To change fee settings, set the following parameter in your rippled.cfg file:


[voting]
# 1000 XRP in drops =  1 billion drops
account_reserve 1000000000

Stuff like https://github.com/ripple/rippled/commit/e81f3eb1d2e6ca31f68a35eb5abf88520b8b5541 apparently did not help. It is time to take more drastic measures.

Ive always been slightly suspicious and apprehensive about coming onto the technical part of this forum, for fear of not understanding whats going on...  

So i just wanted to say, thank you for confirming my suspiscions... i'll let myself out.  

 

Edited by tartankiwi

Share this post


Link to post
Share on other sites
9 hours ago, mDuo13 said:

If you fully delete an account, you lose track of its sequence number and so you could send old transactions again if you re-created it. (And of course, if you fully delete the account, you have no idea whether it used to exist or not.)

And even if there was a way to delete or compact accounts, that mechanism couldn't refund people the account reserve, or else people could spam the ledger with accounts for as long as they wanted, then get all their money back (effectively losing nothing) whenever they decided they were done.

You keep 1 byte to know that the account was already created and deleted, and you refund the reserve accordingly, i.e. if a full account requires 100 bytes and that is 20XRP, when closing an account users can recover up to 20-20/100 (19.8XRP) or we can say 15XRP. I know there are some philosophical problems with closing accounts as already discussed with @nikb but I think it is not really a big deal.

BTW in general increasing the reserve fee is a bad idea. IMO a DLT as this should be open to everybody, without paying any fee. The reserve is already an entry barrier. Otherwise Bitcoin (and all others DLT) has another advantage over XRPL. Maybe a completely different mechanism should be used.

Share this post


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

Uhm... forget, the real technical issues with deleting AccountRoot objects. But how does it help to delete them?

It would shrink down the LedgerState Trie.

10 minutes ago, tulo said:

You keep 1 byte to know that the account was already created and deleted, and you refund the reserve accordingly, i.e. if a full account requires 100 bytes and that is 20XRP, when closing an account users can recover up to 20-20/100 (19.8XRP) or we can say 15XRP. I know there are some philosophical problems with closing accounts as already discussed with @nikb but I think it is not really a big deal.

No, that's not possible, since validators don't have to keep state of the past currently. You would force every node operator to invest thousands of USD in SSD storage. Even if you keep a node with a single byte (how?! The address alone is far far larger than 1 byte...), you still have the trie overhead too. Also this could incentivize algorithmic attacks where accounts are created and deleted to produce very degraded SHAmap layouts.

I agree that it is easy to think it is not a big deal, but this is not a "just do it, figure out details later" scenario.

10 minutes ago, tulo said:

BTW in general increasing the reserve fee is a bad idea. IMO a DLT as this should be open to everybody, without paying any fee. The reserve is already an entry barrier. Otherwise Bitcoin (and all others DLT) has another advantage over XRPL. Maybe a completely different mechanism should be used.

Which other mechanism for state minimization do you have in mind? BTC (and other TXO based currencies) by the way has a similar problem of "dust UTXOs" - effectively unspendable fractions of a coin that are more expensive to move than to just keep them around...

Share this post


Link to post
Share on other sites
1 hour ago, Sukrim said:

Even if you keep a node with a single byte (how?! The address alone is far far larger than 1 byte...), you still have the trie overhead too.

How much is the trie overhead? 

BTW overhead or not overhead you'll change the AccountRoot from 

Quote

{ "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "AccountTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D", "Balance": "148446663", "Domain": "6D64756F31332E636F6D", "EmailHash": "98B4375E1D753E5B91627516F6D70977", "Flags": 8388608, "LedgerEntryType": "AccountRoot", "MessageKey": "0000000000000000000000070000000300", "OwnerCount": 3, "PreviousTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D", "PreviousTxnLgrSeq": 14091160, "Sequence": 336, "TransferRate": 1004999999, "index": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8" }

to

Quote

{ "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",  "Flags": 8388608 }

It's several bytes saved per account.

Edited by tulo

Share this post


Link to post
Share on other sites
23 hours ago, zerpdigger said:

i knew this would come back to bite ripple in the ***... ridiculous the high account fees, and now we have to go higher?! this model isnt working well

plus you'd assume ripple, who talk up micropayments and accessibility of money/payments, wouldnt have an acocunt reserve that basically prevents 90% of the world from ever opening a ripple account... poor people in africa can't afford $5, which is for all purposes lost, for the 'privilege' of playing with ripple, goes against everything they say they stand for

sorry, bit of a bugbear this one for me, IMO the worst aspect of ripple tech these stupid sloppy account fees -- hope theres a way around it in future, some new tech/method

The model is still OK. What Sukrim suggests it to FORCE gateways & exchanges (by the extreme high activation) to the hosting model where one has only XRP kept by the Gateway/Exchange. I more prefer the model @gatehub having both as an option. Unfortunately the hosted cannot trade. I'm sure if they added trading for hosted accounts, it would prevent the creation of a lot of on ledger accounts... even with the 20XRP activation

Share this post


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

The model is still OK. What Sukrim suggests it to FORCE gateways & exchanges (by the extreme high activation) to the hosting model where one has only XRP kept by the Gateway/Exchange.

No, I want to force them to not create new accounts on the ledger if they don't hand their users the private keys to these accounts. This is currently too cheap, users seem to be OK with 20 XRP as "starting fee" but don't realize they are actively paying to spam the ledger. If the amount were higher (doesn't have to be 1000 XRP, but an amount that "hurts"), there would be incentive for users to use or switch to exchanges that don't charge this fees because of their bad implementation or for bad actors to delist XRP. Both cases are beneficial for the network health.

1 hour ago, tulo said:

It's several bytes saved per account.

It also lets you replay all transactions of that account as soon as it becomes active again.

The overhead scales with O(log16) as far as I understand it, but since spamming the ledger is free in this case, you could produce nearly arbitrarily large state. Again: The issue is that SOMETHING needs to be stored, not necessarily how much of that something.

Share this post


Link to post
Share on other sites

Ok, I really don't want to say this.  But... it's honestly about the only thing I can think of that really might work.  (Raising the account reserve to be so high, while a simple and quick solution - I mean it'd work, right? - is also can of worms IMO, and probably wouldn't gain traction.)

So, could this be solved with... (be kind, I'm averse to what I'm about to say as much as you)...

...regulation?

Ok, so hear me out!  As an attack vector, account spam is obviously not going to be hindered much by regulation.  Nefarious attackers don't care about regulations so much.  But with account reserves being what they are, to me that attack is just so expensive I don't see it as an issue.  So, given that as I understand it, most of the spam comes from "legitimate" businesses, doing business, with Ripple's uhh, "business"... and given these businesses are effectively stealing from their own users and punishing all of the existing nodes/users of the network as a whole in order to do it, wouldn't the solution seem to fit quite nicely into a regulatory framework?  Businesses using the XRP Ledger are already governed by a bunch of existing laws in order to do so.  So how about just tell them that what they charge their users for setting up an account has to match the reserve?  Maybe also set some reasonable limits around amount of customers vs amount of accounts?  And if they don't they get fined to hell or something?

Share this post


Link to post
Share on other sites
32 minutes ago, Professor Hantzen said:

So, could this be solved with... (be kind, I'm averse to what I'm about to say as much as you)...

...regulation?

If we were in a government position that is able to regulate: sure.

There is no world government (yet?) though and no global regulatory environment. There are various bad actors in the XRPL ecosystem, including some well meaning ones like the Ledger wallet makers. Also there is no way that laws or regulations are going to get passed on a global scale just because some obscure Fintech startup community member has concerns about some database getting filled too quickly. You can tell these bad actors that they should change, but as I (and Ripple employees) already said: they were contacted, they know what they should do, they don't do it. It is not up to us to write regulations or hand out fines and any regulation to fix this issue would be hyper specific.

The specific solution outlined in the protocol for exactly this situation are owner reserves. They have already been ignored for too long, it is time for Ripple Inc. to get active in taking care of their own blockchain, especially in light of the upcoming decentralization strategy that they want to implement.

Share this post


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

If we were in a government position that is able to regulate: sure.

There is no world government (yet?) though and no global regulatory environment. There are various bad actors in the XRPL ecosystem, including some well meaning ones like the Ledger wallet makers. Also there is no way that laws or regulations are going to get passed on a global scale just because some obscure Fintech startup community member has concerns about some database getting filled too quickly. You can tell these bad actors that they should change, but as I (and Ripple employees) already said: they were contacted, they know what they should do, they don't do it. It is not up to us to write regulations or hand out fines and any regulation to fix this issue would be hyper specific.

The specific solution outlined in the protocol for exactly this situation are owner reserves. They have already been ignored for too long, it is time for Ripple Inc. to get active in taking care of their own blockchain, especially in light of the upcoming decentralization strategy that they want to implement.

I may somewhat agree on the specificity, but not in the general case.  Regulations are going to need to be made - across the world - for exactly these kinds of "new" problems.

One way to categorise such an issue is that its some database getting filled too quickly.  Another may be that bad actors are stealing from users by hiding the true cost of providing a  service and charging their customers for something they shouldn't, whilst also preventing a customer from having appropriate control of their funds.  The database issue is then an "effect" that just happens to be solved by regulating the main issue which might be considered dodgy business practice - ie, exactly what regulations are for.

I don't think the owner reserves were intended to create prohibitively high entry cost.  To me, a 1000XRP reserve is in a sense "hacking" the account reserve function to solve the problem.  And as you've acknowledged, its not a permanent solution.  The problem may simply reappear when the reserve is lowered again.

I do agree something needs to be done.

I wonder if something could be done with dynamic account reserves in the same way opening a trustline places an additional reserve requirement?  What if along with the account activation fee sent to activate an account, another, more-punitive - but temporary - hold was placed on the parent accounts reserve requirement?  Exchanges might think twice about opening many accounts if they actually have to hold a requisite amount of XRP for a significant period of time.  I'm not sure what would condition could constitute reversing the hold however?  Perhaps a sufficiently lengthy time-lock?  Just thinking on the spot here - I'm sure there are a bunch of problems with this, do please tear away.

Share this post


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

No, I want to force them to not create new accounts on the ledger if they don't hand their users the private keys to these accounts. This is currently too cheap, users seem to be OK with 20 XRP as "starting fee" but don't realize they are actively paying to spam the ledger. If the amount were higher (doesn't have to be 1000 XRP, but an amount that "hurts"), there would be incentive for users to use or switch to exchanges that don't charge this fees because of their bad implementation or for bad actors to delist XRP. Both cases are beneficial for the network health.

It also lets you replay all transactions of that account as soon as it becomes active again.

The overhead scales with O(log16) as far as I understand it, but since spamming the ledger is free in this case, you could produce nearly arbitrarily large state. Again: The issue is that SOMETHING needs to be stored, not necessarily how much of that something.

They are not "paying to spam the ledger"... they are paying to be part of the ledger what gives them the advantage to store cold. Or warm, but than at least not on an exchange.
I understand your "problem", but this shouldn't be solved by chasing away users who WANT to go for the advantages coming with on ledger storage. Those, 20XRP, FOREVER locked up, hurts enough for most I guess.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...