Jump to content
Sukrim

Time to increase the owner reserve?

Recommended Posts

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.

Edited by Sukrim

Share this post


Link to post
Share on other sites
52 minutes 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.

Wow, in that case Gatehub can close doors...

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
5 minutes 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

I used to despise the account activation fees because it deters consumer adoption, but there's no other way to stop people to use account creation as a spam attack. They've successfully solved the storage issue of not having to store every transaction by only storing account balances - it's how they scale so well. I don't think removing the account reserves is in the cards as it is the core of protecting the ripple network.

Share this post


Link to post
Share on other sites
6 minutes ago, zerpdigger said:

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

Well, the idea is that the accounts won't grow indefinitely, or at least they will grow linearly with time, but prices of storage hardware should also decrease linearly (Moore's law) or even faster (quadratically?). Also I think we are close to some breakthrough in atomic electronics (IBM is researching in nano-storage) which could give a huge kick to storage cost.

If that doesn't work, then the whole ledger structure has to be re-thought (lightweight XRPL?).

Share this post


Link to post
Share on other sites

It was once explained somewhere that Bitcoin is a long chain of history links but RCL is a cross cut of current state.  Hence its speed. I wasn't sure if that was fully correct because I wondered about my cold wallet.  It's sat idle for weeks so does it appear in any way in the current block?

Assuming it does...  Can you tier the accounts so that recent activity makes it appear in current blocks but inactive ones after a time do not appear and so transactions on them would need to go back and read the chain to retrieve the state info.  Inactivity on an account will cause slower than normal response times but the ledgers data volume reduces.

It's just a thought...   Is that all nonsense?   I won't be upset if it is....   :) 

Share this post


Link to post
Share on other sites
25 minutes ago, M-X said:

I used to despise the account activation fees because it deters consumer adoption, but there's no other way to stop people to use account creation as a spam attack. They've successfully solved the storage issue of not having to store every transaction by only storing account balances - it's how they scale so well. I don't think removing the account reserves is in the cards as it is the core of protecting the ripple network.

i have wondered if theres some ideas they can borrow from iota, just for activation purposes, to trade account fees for low-energy PoW validation of some kind, just to activate on the network, some kind of hybrid -- but my technical knowledge is rubbish so i am likely spouting gibberish

Share this post


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

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

Because as already discussed many times there is not much to gain from this - accounts have permanent state attached to them and if they get re-created that state must also be re-created.

Share this post


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

If that doesn't work, then the whole ledger structure has to be re-thought (lightweight XRPL?).

theres a topic buried somewhere where someone asked @JoelKatz about whether there were any performance gains (worth the trade off for losing the added features) in removing the exchange/trustlines aspects of XRPL -- i believe Mr Schwartz said it wasnt worth it

EDIT: ah, looks like @Sukrim sort of confirmed that too!

Edited by zerpdigger

Share this post


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

Because as already discussed many times there is not much to gain from this - accounts have permanent state attached to them and if they get re-created that state must also be re-created.

I'm for non-reusability of closed accounts, such that no extra states have to be saved per account (well, only the information that it was closed). And I think that also in the case or reusability of closed accounts, you can save more than half of the space, isn't it?

EDIT: maybe I asked you already before, but how much is the space needed for trust lines and offers w.r.t. the space needed for the accounts?

Edited by tulo

Share this post


Link to post
Share on other sites
50 minutes ago, zerpdigger said:

theres a topic buried somewhere where someone asked @JoelKatz about whether there were any performance gains (worth the trade off for losing the added features) in removing the exchange/trustlines aspects of XRPL -- i believe Mr Schwartz said it wasnt worth it

EDIT: ah, looks like @Sukrim sort of confirmed that too!

Well, depends on which performance you consider. If you want to increase the TPS, probably it is not worth it, but for ledger memory usage, trust lines and offers consume quite a lot.

Share this post


Link to post
Share on other sites

could escrow replace account reserves somehow, like, it gets locked up until you delete/close the account and trigger the escrow release?

EDIT: probably a stupid idea i know, i'm just brainstorming

Edited by zerpdigger

Share this post


Link to post
Share on other sites

Happy to discuss this stuff in a different thread. At the moment, no such measures are in place or even publicly discussed by Ripple employees afaik, so the one thing that is in place right now to disincentivize spam and excessive growth are reserves.

Share this post


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

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.

Do you not think this would have a significant (negative) affect on price? The graphs in this thread (back in July, so outdated, but it's an indication) show that over 78% of wallets had less than 1000 XRP in them. The announcement of the reserve increase would surely drive a lot of people to sell, as you're making their wallets worthless or at least significantly reducing their value? There would also be no way to guarantee that the reserve would ever be decreased again later. It would very much be a case of punishing the people for the crimes of the companies. And even if that 78% is a tiny percentage of total XRP, it's a lot of people that would be angered, and people is what we're trying to win over to our side, right?

8 hours ago, Sukrim said:

Businesses using XRPL correctly wouldn't be affected since they don't constantly have to fund new accounts anyways.

Businesses like Gatehub (where you have a choice: they'll either store your XRP in a shared wallet, or create you a unique wallet and also give you the secret key) would surely be affected in a similar way, as existing users with dedicated wallets will suddenly lose access to a lot of their funds (for small wallets). New and uninformed users would surely get angry at Gatehub, cause their support costs to rise, and to some extent cause damage to its reputation (via online posts etc.), when Gatehub is doing nothing wrong. Same goes for any company that generates unique wallets (hardware, desktop...). A huge amount of negativity would result, greatly reducing sentiment towards Ripple.

With respect, I do not think this is the way to go about it. If the quantity of new wallets is actually problematic for the servers, that is a technical issue, not one to be solved by punishing the users (either the companies or their customers) for acting in a way that the system allows.

The fact that the companies are not behaving ethically is a different problem IMO, and one that probably needs regulation to fix (so will be a long time coming).

I realise that I'm not suggesting any fixes - I agree it's a tough problem and not trying to shout you down, just wanted to put across my differing view.

8 hours ago, Sukrim said:

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

It would be interesting to hear if Ripple employees still expect that this will be achievable - and how critical is it to XRP's success that it remains achievable?

Share this post


Link to post
Share on other sites

×