Document how to control starting amendments in standalone mode

mDuo13 commented 2 years ago

ckniffen wrote: (copied from comment below)

According to the changelog in 1.7.0 [features] was removed. I was able to set default:no amendments by adding the [amendments] stanza.

[amendments]
32A122F1352A4C7B3A6D790362CC34749C5E57FCE896377BFDC6CCD14F6CD627 NonFungibleTokensV1_1

This stanza will only be used on the creation of the genesis ledger when using --start but not when running in regular standalone mode.

Issue Description

It used to be that you could control which amendments are enabled in the ledger when you start a stand-alone mode server: anything that's not vetoed in the config file would get enabled in the fresh genesis ledger and apply starting with ledger 2.

It seems that due to either default amendment votes, or the combination with disabling config-file voting, it's not possible to enable amendments that have a "no" default vote.

Steps to Reproduce

With your server either synced to any network or in stand-alone mode, connect to an admin WebSocket connection (ws://localhost:6006 if you're using the default config) and send this command to enable CheckCashMakesTrustLine:
```
{
  "command": "feature",
  "feature": "CheckCashMakesTrustLine",
  "vetoed": false
}
```
Shut down the server.
Start the server in stand-alone mode, like this:
```
rippled -a --start
```
From an admin WebSocket connection, check amendment statuses again:
```
{
  "command": "feature"
}
```

Expected Result

The response from step 4 above should show a variety of amendments in the "enabled": true state including CheckCashMakesTrustLine.

Actual Result

Most other (non-retired) amendments are enabled, but the CheckCashMakesTrustLine amendment is still not enabled, e.g.

"98DECF327BF79997AEC178323AD51A830E457BFC6D454DAF3E46E5EC42DC619F" : {
         "enabled" : false,
         "name" : "CheckCashMakesTrustLine",
         "supported" : true,
         "vetoed" : true
      }

Environment

Arch Linux, self-compiled, v1.8.2-rc1.

ximinez commented 2 years ago

What's the last version that you are aware of that this feature worked? Can you post the startup messages from your logs having to do with Amendments?

mDuo13 commented 2 years ago

Can't remember if the last time it worked was 1.7 or 1.6. For the amendments, do you mean for the new or the old one? And what debug level?

ximinez commented 2 years ago

For the amendments, do you mean for the new or the old one? And what debug level?

Both?

The messages I'm thinking about are written before the default level gets changed.

ckniffen commented 1 year ago

I found a way to do this without modifying the code. According to the changelog in 1.7.0 [features] was removed. I was able to set default:no amendments by adding the [amendments] stanza.

[amendments]
32A122F1352A4C7B3A6D790362CC34749C5E57FCE896377BFDC6CCD14F6CD627 NonFungibleTokensV1_1

This stanza will only be used on the creation of the genesis ledger when using --start but not when running in regular standalone mode.

Related links:

intelliot commented 1 year ago

I think this is ready to be documented. I added this issue to the XRPL Docs project.

mDuo13 commented 1 year ago

Is there a way to exclude "default:yes" amendments from the starting ledger? The old amendment voting settings allowed for that, but I don't know of a way to do that ever since voting using the config file was removed.

JST5000 commented 1 year ago

Not sure if it's fully relevant, but this is the config we use to start ledgers with all the given amendments enabled in xrpl.js & xrpl-py as part of our CI. https://github.com/XRPLF/xrpl-py/blob/master/.ci-config/rippled.cfg

It's used as a parameter to the rippled container here: https://github.com/WietseWind/docker-rippled

(Specific instructions on how we use it for that are in CONTRIBUTING.md)

mDuo13 commented 10 months ago

The config using [feature] to control default amendments is not really what's intended, because [feature] does not "properly" enable amendments. It just forces the server to behave as if the amendments were enabled without actually enabling them. This is distinct in a few ways:

It's not communicated in network mode. Other servers have no way of knowing what amendments you've got in your [features] stanza. Unless every server is configured with the exact same set, you'll build divergent ledgers any time the amendments are relevant. Servers won't know if they "should" be amendment-blocked based on what the rest of the network is doing.
The feature API method and the Amendments ledger entry won't show the amendments as enabled. (Because, officially speaking, they aren't.)
You can take an amendment out of the [features] stanza and the server will stop acting as if it's enabled. When you enable an amendment "officially", it can never be disabled. Weird, unexpected behaviors may occur if you build ledgers with an amendment force-enabled, then disable it and try to continue the chain with the pre-amendment logic.

Using the [amendments] and [veto_amendments] stanzas only works if your wallet.db file has no amendment voting data in it (if you don't have a wallet.db file, a fresh one is created on server startup). This is because those stanzas are deprecated but the server reads them once to import the data into the new format (which is stored in the sqlite wallet.db file) as a migration step.

I like MaestroLegato's solution using --ledgerfile with a doctored ledger to define the starting amendments (and potentially other things like the genesis account). It might be nice to have a tool that helps set up an internally-consistent JSON with the values you want. (I also still think the default starting ledger should be more useful.)

In https://github.com/XRPLF/rippled/issues/4198 I shared another example of a "doctored" JSON file with amendments enabled, as well as some of my findings from experimenting with --ledgerfile.

XRPLF / xrpl-dev-portal