Stand-alone mode ignores reserves voting on fresh ledger (Version: 1.7.0-b10)

[mDuo13]

Issue Description

When starting a new ledger in stand-alone mode, the server uses the hard-coded default reserve settings of 200 XRP base + 50 XRP incremental reserve, ignoring the configured [voting] stanza.

This issue causes transactions that send, say, 21 XRP to a fresh account to result in tecNO_DST_INSUF_XRP when run against a server in stand-alone mode instead of succeeding, when they would be fine against mainnet/testnet/etc. I also have not figured out if there is a way to adjust and test different fee/reserve settings in stand-alone mode at all.

Steps to Reproduce

1. Add the following stanza to your rippled.cfg:

    [voting]
    account_reserve=20000000
    owner_reserve=5000000
   

   This is supposed to bring the recommended votes in line with the current mainnet values of 20 XRP / 5 XRP.

2. Start rippled in stand-alone mode:

    rippled -a --start
   

   (The --start is optional but causes supported amendments to be enabled from the start rather than waiting 2 weeks; it would make sense to apply fee voting settings the same way.)

3. Use server_info to check the reserve settings of the current ledger:

    rippled server_info
   

4. Optionally, close the ledger 256 times to give Fee Voting a chance to take effect:

    for value in {1..255}; do rippled ledger_accept ; done
   

5. Use server_info to check the reserve settings of the current ledger:

    rippled server_info
   

6. Check for a FeeSettings object using ledger_entry or ledger_data:

    rippled json ledger_entry '{"index": "4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651","ledger_index": "validated"}'
   

Expected Result

Server info (at step 3 or at least step 5) shows "reserve_base_xrp": 20 and "reserve_inc_xrp": 5.

Ledger's FeeSettings object indicates the reserve settings per the vote.

Actual Result

Server info shows that the base reserve is still the hard-coded value of 200 XRP:

    {"result": {
        "info": {
            ...
            "validated_ledger": {
                    "age": 0,
                    "base_fee_xrp": 0.00001,
                    "hash": "478B5A4B374ECE4D123E187F1EE9EA94E2AC831D26DE526C511E17D88B108FF0",
                    "reserve_base_xrp": 200,
                    "reserve_inc_xrp": 50,
                    "seq": 267
            },
        ...
        }
        "status": "success",
        "type": "response"
    }}

Ledger has no FeeSettings object.

Environment

Arch Linux x86_64
rippled v1.7.0-b10, self-compiled (unit tests passing)

[Anderson-Juhasc]

I have a similar bug on testnet: https://testnet.xrpl.org/accounts/rpShuzUW3HWR26GBuhBBq6dKwwHeiGy6fS

[mDuo13]

I have a similar bug on testnet: https://testnet.xrpl.org/accounts/rpShuzUW3HWR26GBuhBBq6dKwwHeiGy6fS

That's not a bug, that's working as designed. The payments in question are getting tecNO_DST_INSUF_XRP because they are sending 1 XRP to accounts that don't exist, when the minimum to create a new account on Testnet is currently the same as on Mainnet, 10 XRP.

[Anderson-Juhasc]

@mDuo13 thanks o/

[Anderson-Juhasc]

@mDuo13 well, I sent 11 XRP and try to sent to another address and I had the same problem...
https://testnet.xrpl.org/accounts/rQNosSmCKLtEipfW32UnqvfGvBCp2ngJ8h

[MarkusTeufelberger]

The reduced prices for reserves were implemented as default votes, not as default values. You'd need to close a couple ledgers until the first flag ledger gets closed, there should likely be a vote from the standalone validator in there that reduces fees.

I assume this is intended behavior?

[Anderson-Juhasc]

Hi @MarkusTeufelberger, well I want to receive a transaction in some wallet address and when I recognize the value I send to another central wallet address.

[MarkusTeufelberger]

Your Testnet problem is unrelated to this issue. Please read https://xrpl.org/reserves.html or get support elsewhere.

[intelliot]

note: this issue applies not only to standalone mode; even if you change reserves in config (example below), you still need to wait for a flag ledger (~15 min at the rate that Mainnet closes ledgers) for the settings to take effect.

[voting]
account_reserve=10000000
owner_reserve=2000000

[ximinez]

You can change the configured defaults using the mostly undocumented configuration sections [fee_account_reserve] and [fee_owner_reserve]. e.g.:

[fee_account_reserve]
20000000

[fee_owner_reserve]
5000000

The delay using fee [voting] settings is working as intended.

[drlongle]

I can change the code so that rippled can parse the [voting] config correctly.

Do we want to keep the mostly undocumented configuration sections [fee_account_reserve] and [fee_owner_reserve]? My working assumption is that we drop them. Too many alternatives tend to cause confusion.

@intelliot @ximinez @mDuo13 Let me know what you think.

[ximinez]

Do we want to keep the mostly undocumented configuration sections [fee_account_reserve] and [fee_owner_reserve]? My working assumption is that we drop them. Too many alternatives tend to cause confusion.

In fact, no I don't. My intent is to push some changes commits to #4319 which will basically do away with those settings, and read from [voting]. I've started working on it in https://github.com/ximinez/rippled/commits/ledgerinit-wip, but have paused it for a bit to handle higher priorities.