Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document how to control starting amendments in standalone mode #1762

Open
mDuo13 opened this issue Feb 16, 2022 · 8 comments
Open

Document how to control starting amendments in standalone mode #1762

mDuo13 opened this issue Feb 16, 2022 · 8 comments
Labels
bug Typo or other small documentation error

Comments

@mDuo13
Copy link
Collaborator

mDuo13 commented Feb 16, 2022

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.

Related links:


Original title: Can't control starting amendments in stand-alone mode anymore (Version: 1.8.2)

I can't start a stand-alone mode server with the CheckCashMakesTrustLine amendment pre-enabled anymore.

(I'm not talking about force-enabling via the [features] stanza: I mean controlling which amendments are "officially" enabled in the stand-alone ledger.)

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

  1. 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
     }
    
  2. Shut down the server.

  3. Start the server in stand-alone mode, like this:

     rippled -a --start
    
  4. 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.

@mDuo13 mDuo13 added the bug Typo or other small documentation error label Feb 16, 2022
@ximinez
Copy link
Contributor

ximinez commented Feb 16, 2022

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
Copy link
Collaborator Author

mDuo13 commented Feb 24, 2022

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
Copy link
Contributor

ximinez commented Feb 24, 2022

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
Copy link
Contributor

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 intelliot changed the title Can't control starting amendments in stand-alone mode anymore (Version: 1.8.2) Document how to control starting amendments in standalone mode Feb 23, 2023
@intelliot intelliot transferred this issue from XRPLF/rippled Feb 23, 2023
@intelliot intelliot moved this from 🏗 In progress to 📋 Backlog in Core Ledger Feb 23, 2023
@intelliot intelliot removed this from Core Ledger Feb 23, 2023
@intelliot
Copy link
Contributor

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

@mDuo13
Copy link
Collaborator Author

mDuo13 commented Aug 8, 2023

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
Copy link
Contributor

JST5000 commented Aug 24, 2023

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
Copy link
Collaborator Author

mDuo13 commented Nov 17, 2023

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 XRPLF/rippled#4198 I shared another example of a "doctored" JSON file with amendments enabled, as well as some of my findings from experimenting with --ledgerfile.

@coderabbitai coderabbitai bot mentioned this issue Dec 6, 2024
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Typo or other small documentation error
Projects
Status: Backlog
Development

No branches or pull requests

8 participants
@intelliot @ckniffen @ximinez @mDuo13 @JST5000 and others