Jump to content
pftq

Lowering XRP Min Balance

Recommended Posts

@Professor Hantzen I like the idea of changing the reserve dynamically. It could be a cost related to the "speed", i.e. how many accounts per hour are created and on the total accounts created in a period (a month? a year? all the accounts ever created?). And given a current target in terms of maximum accounts in the ledger, those parameters can be tuned to obtain the behavior. But it would introduce more complexity to the system and for the users. Imagine a new user comes and sees he needs 50.234 XRP to create a wallet, when his friend the day before only needed 15.23 XRP. But it's doable IMO. It's sort of PD controller :lol:.

Edited by tulo

Share this post


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

The main problem with the account reserve is that it is a fixed value. It does not adjust dynamically.

It isn't fixed, it was already adjusted several times. It is just much slower than e.g. Bitcoin's 2 week difficulty target. Fixing to an USD/EUR/BTC/Whatever value might be possible with some handwaving and analysis of order books + liquidity on the ledger as well as actual trades happening, but I don't really see a big advantage for such a system (even if it is a bit slowed down, e.g. every month or so an expensive calulation is done how much an X USD reserve would be in XRP for the next month).

Accounts are just the most expensive objects on the ledger that also have the capability of even creating a lot more objects (unlike a trust line or an Escrow for example), but they are not the only ones. I would rather see a desired total AccountState size than a desired number of Account objects in there - and even then you open yourself up to algorithmic complexity attacks due to the design of the SHAmap trie.

Calculating a ideal rate of account creation is difficult, because usage has changed over the years together with Ripple Inc's direction: With gateways, a lot of accounts opened trust lines and tried trading, nowadays many of them are not much more than an "address:XRP_balance" mapping with some popular wallets (Ledger Nano S) not even exposing any features beyond the most basic payment transactions. In the future there might be a killer app that re-ignites the P2P trading aspect or focusses on payment paths or (ab-)uses transaction memos or something completely different (PayChan, Checks, Escrow...).

I like the idea of lawyering up, but it seems a bit silly to advertise low fees, high TX throughput and an open, public infrastructure while on the other hand threaten someone that uses the system according to its own rules. This is also why I would rather see the reserve go up (or even Ripple just publicly threaten to do so) because that's the built-in mechanism to solve these issues, not lawyers.

Cascading reserves are also a bit of a DoS vector since A has no influence over the actions of B in many cases. You shouldn't get punished for something you can't prevent imo.

16 minutes ago, Professor Hantzen said:

I haven’t thought about what other problems this may introduce.

You can no longer buy XRP at an exchange and withdraw to your own, unfunded account for example.

 

Stellar might be an interesting testbed for these questions by the way, as they recently reduced their reserve to a bare minimum and also allow merging accounts - spam attacks should be rather cheap there. I am just not sure if it would even be legal to try to bring their network down by sending valid transactions and I would also consider it relatively unethical (though profitable, if you short XLM before starting the experiment). Maybe on their testnet it might be an option...

Share this post


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

"be there" in the sense of "being present in the current ledger's AccountState", right? Because it would just get re-funded once I send some XRP to it. Maybe a different prefix would be useful for these accounts, but then again it might make the distinction between account types sharper than it maybe has to be and would make upgrades painful.

Yes, that's right. However, there are still issues with funding the account after it's been removed.

For example, suppose you know that an account once existed and you try to send 1 XRP to it. If it was a light account that was removed, that will fail.

Say you know that an account once existed and you send 20 XRP to it. If it was a light account that was removed, you'll create a regular account.

So it's not perfect. Our recommendation will be not to remove a light account unless you're relatively certain no more funds will be sent to it.

We thought about making a distinction between account types, but the problem with that is that all tools would have to change for light accounts to work properly. Everyone would have to understand the new account format.

Share this post


Link to post
Share on other sites

Nearly nobody seems to use custom tools anyways, most don't even seem to run their own rippled server...

Would removal be permanent? Why would a payment of 1 XRP to a removed light account fail instead of just re-opening it (is there a minimal initial balance to create one?)?

Share this post


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

Nearly nobody seems to use custom tools anyways, most don't even seem to run their own rippled server...

Would removal be permanent? Why would a payment of 1 XRP to a removed light account fail instead of just re-opening it (is there a minimal initial balance to create one?)?

I guess it depends on the rules we decide to go with. If the rule is that sending less than 20 XRP automatically creates a light account, then it would succeed. That's probably what we'll do, so it won't fail. But if the account was removed and 20 or more XRP is sent, then a regular account will be created and 20 XRP will be locked as the reserve. That might annoy people.

We could change it so that the Payment transaction always creates a light account by default. The account owner can promote it to heavy account if they wish. But we'd need a way to create a regular account with a Payment transaction because otherwise, existing flows for offline account creation will break. (Because you don't know the new account's starting sequence number and so can't prepare transactions offline.)

Share this post


Link to post
Share on other sites

It could be a flag in the payment transaction I guess... or something obscure, like sending a prime number of XRP to an unfunded address! :-P

Edit: Maybe _every_ funding of an account should create a light account that then can be promoted with a special AccountSet transaction? Allowing any amount of XRP to create light accounts still might lead to spam issues, with 20 XRP I could create more light accounts with 1 drop than full accounts that are currently existing. Light accounts probably would also need an initial balance of 1 OwnerReserve to make them a bit less spammy. Maybe make it even semi-permanent: Only the last transaction that sets the balance to 0 and removes the object is allowed to remove the reserve funds?

Edited by Sukrim

Share this post


Link to post
Share on other sites

Unfortunately, that blocks offline account creation flows. Since you don't know the starting sequence number for the account, you can't compose the transactions to configure it. That might not be fatal, but it is disruptive. But having your light account turn into a regular account after you wiped it out might be disruptive too.

Share this post


Link to post
Share on other sites

Then we're back into "add a flag to the Payment transaction to immediately create a full account" territory. This makes it impossible to accidentally create or promote a full account (especially if limits change over time) and still allows for the offline case.

What about having a semi-permanent OwnerReserve for light accounts though? Or should I really be able to create a million of them with 1 drop each?

Share this post


Link to post
Share on other sites
7 minutes ago, JoelKatz said:

Unfortunately, that blocks offline account creation flows. Since you don't know the starting sequence number for the account, you can't compose the transactions to configure it. That might not be fatal, but it is disruptive. But having your light account turn into a regular account after you wiped it out might be disruptive too.

Sounds good to me Kahuna! Just get that TPS number up a little closer to Visa; 1500 won't be fast enough for what we have planned! :spinlol:

Sri

Share this post


Link to post
Share on other sites

Let me see if I'm following the general idea here:

A light account would be limited to send/receive of XRP only and have a reserve amount < 20XRP.  (Could be upgraded to a heavy account at anytime)

A heavy account (current standard) would have a 20XRP reserve or higher.  If the reserve amount of heavy accounts go up to say 100XRP, the reserve requirements for light accounts would remain unaffected.

Am I understanding this correctly?

 

Share this post


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

@Professor Hantzen I like the idea of changing the reserve dynamically. It could be a cost related to the "speed", i.e. how many accounts per hour are created and on the total accounts created in a period (a month? a year? all the accounts ever created?). And given a current target in terms of maximum accounts in the ledger, those parameters can be tuned to obtain the behavior. But it would introduce more complexity to the system and for the users. Imagine a new user comes and sees he needs 50.234 XRP to create a wallet, when his friend the day before only needed 15.23 XRP. But it's doable IMO. It's sort of PD controller :lol:.

@Professor Hantzen I don't know how much my opinion matters but I really really don't like the idea of dynamic reserve. I think will make people feel cheated or jealous or even make people procrastinate. However, having a more or less constant reserve gives people the time and the inclination to 'build up' their decision making muscle rather than wait for stochastic opportunities.

Share this post


Link to post
Share on other sites
6 hours ago, hesque said:

@Professor Hantzen I don't know how much my opinion matters but I really really don't like the idea of dynamic reserve. I think will make people feel cheated or jealous or even make people procrastinate. However, having a more or less constant reserve gives people the time and the inclination to 'build up' their decision making muscle rather than wait for stochastic opportunities.

I agree with your psychological/social analysis - however, it is actually how things already are.  By fixing the account reserve as a set amount of XRP, it is then XRP's value against the dollar fluctuating creates the same situation.  Many here activated their stash of accounts for 12 cents each - newcomers need to pay $30. The difference I've suggested is tying the fluctuation to the account generation rate, where to me it belongs, instead of to the XRP/FIAT rate(s) which is a choice that has no relevance and makes no sense.

Share this post


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

I like the idea of lawyering up, but it seems a bit silly to advertise low fees, high TX throughput and an open, public infrastructure while on the other hand threaten someone that uses the system according to its own rules. This is also why I would rather see the reserve go up (or even Ripple just publicly threaten to do so) because that's the built-in mechanism to solve these issues, not lawyers.

This could be argued for many things.  The internet allows for people to get together and destroy a companies business via its website - does that mean those that do it can hide behind "the internet lets me do it" argument?

I like the stellar idea (the testnet version...!).

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