Change the "default for" voting on amendments to an explicit choice

[MarkusTeufelberger]

https://developers.ripple.com/amendments.html#amendment-voting

"By default, rippled supports known amendments and opposes unknown amendments."

I would like to suggest that validators that have amendments in their code which are not (yet) enabled won't start sending validations unless they add them to an [amendments] or [veto_amendments] list. This makes it more like a voting process.

Alternatively add an "abstain" vote type by default and require a high enough threshold of active aye or nay votes.

[nbougalis]

We have considered the "abstain" type vote and were planning on introducing a proposal to that exact end.

Let's have a discussion about this on this issue here.

[MarkusTeufelberger]

Hm, that might still run into issues if many people truly don't care about an amendment (though in that case I'd rather default to not adding the amendment, since most people don't have commit rights here) but that position is indistinguishable from "I haven't decided yet".

Another thing to consider is a "wait a bit, we first need to audit the code or its implications before we voice our opinion"-vote.

So in essence 4 choices: "Undecided", "No", "Yes", "Don't care either way" with the default being "Undecided" and various (maybe lowering over time?) thresholds how many votes need to be "Y","N" or "D" vs. "U" to accept/refuse an amendment, maybe with the additional stipulation that once you leave the "U" state, you can't go back to it.

[MarkusTeufelberger]

A similar discussion might be had on numerical votes (like fees/reserves), which pose huge coordination hurdles compared to a yes/no vote on amendments - but that's probably better discussed in a separate issue.

[nbougalis]

I'm not sure that having an "abstain" makes sense. If such a vote is completely excluded (that is the server's vote doesn't count) it's effectively a "YES" and if it is counted, then it basically counts as a "NO".

Perhaps the existing default ("YES") should be changed, but adding a third option doesn't really seem useful to me.

[MarkusTeufelberger]

As I said, there could be a way to lower the necessary ratio of "Y/N" vs. "D" over time, so it would initially count as a "NO" and then over time as a "YES".

This would also make it more expressive what validator operators want. Abstaining from a decision is also a decision.

Lastly, it would be a useful state to be in initially, if you are making voting on amendments mandatory (e.g. rippled won't start any more until you write your votes for all current amendments in the config file explicitly) but haven't had the time yet to vet the code. Having any default votes is in my opinion not very fair, since it either shows too much trust or too little trust in the people that can merge commits to this repository. This means votes should be explicit, but then again that means that they must be taken in an informed and conscious way, not just "oh, the server won't start, let's just type in whatever to make it run again!". If validators then consistently show no interest in actually voting on amendments, I would remove them from my UNL for example, because they clearly have no interest in developing the network further and I would view that as an indication of lack of competence. This would not be possible with just "Yes" and "No" votes, because these can't express actual indifference.

Alternatively make it much easier for anyone to propose and write amendments that end up in this repository, to see if people actually care - if someone always votes "Yes" whatever the cause this would also be relatively easy to expose that way.

[nbougalis]

I had several conversations about a new "abstain" vote type, which I'd make the default. Ultimately, @JoelKatz convinced me that it doesn't buy you anything.

Consider regular political elections. People can choose not to vote (where that is legal) or to cast a blank (or "None of the Above") ballot. It doesn't really affect the result either way.

Remember, that voting "No" isn't permanent. The servers could all vote "No" on some amendment X for several months, perhaps years, before deciding that "you know what, it's pretty darn good; we ought to have this" and they start voting "Yes". All a "No" means is "I don't want this activated yet" and it must be sustained over time.

You certainly have a point that the presence of a third option could be an effective messaging mechanism, that shows third parties which validators are "paying attention" and which aren't). Maybe that's an important consideration in itself; I'm not sure either way.

Creating new amendments is fairly trivial, and we wouldn't object to merging them if they were associated with a value-added feature. But there would be pushback to the notion of adding amendments for the sake of adding amendments to see how servers vote on them.

[mDuo13]

I'm going to take Nik's word as the final word on this issue and close it for now.

[MarkusTeufelberger]

Nik's word was on extending the vote from "default Yes/explicit No" to "default Abstain/explicit Yes/explicit No".

I'd stil like to either see: "default No/explicit Yes" (just look at how many of your recommended(!) validators vote FOR CryptoConditions!) or "explicit Yes/explicit No" to be sure to have an informed and intentional vote by validators. I'm not so sure if people are understanding that if they (auto-)update their server software, they immediately start voting for new features right away.

Edit: Ripple themselves vote "No" on most amendments that are currently possible and explicitly choose to say "Yes" to some. This should be the norm.

[intelliot]

Good points @MarkusTeufelberger , I think that is worth considering.

[JoelKatz]

The original assumption was that a person who chose to upgrade their code to understand an amendment and have the code to implement it most likely wanted the amendment to operate on the network.

[MarkusTeufelberger]

Upgrading the software has been nearly mandatory after a few weeks after a software release, since both more "feature" amendments and "bugfix" amendments are enabled through the same mechanism. This makes it nearly impossible to stay on older versions of the software while being in sync with mainnet.

Also if code updates would be an implicit opt-in anyways, there would be no real need for amendments other than maybe a bit of coordination about enablement.

I'd argue that this initial assumption was maybe OK at the time, these days it would be more important to make sure validator operators are actually good stewards of the ledger and take concious decisions about its future.

[scottschurr]

No one has commented on this issue in three years or so. In the intervening time the landscape has changed. The [amendments] and [veto_amendments] stanzas of the config file have been deprecated (https://xrpl.org/understanding-log-messages.html#veto_amendments-section-in-config-file-ignored). Local amendment voting preferences are now preserved in the wallet.db file.

Beyond that, the latest code by default votes down most new amendments. Each individual amendment has its own default vote value. But, for most amendments, the server defaults to voting no: https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/Feature.cpp#L443-L454

The only time VoteBehavior::DefaultYes should be used on the initial release of an amendment, is if the developers find a bug that is so important that it's worth amendment blocking many users. So we expect most amendments will be DefaultNo, at least for their initial release.

Given that servers will tend toward DefaultNo for new amendments, I think the benefit of the proposed change is less obvious.

I think the suggested change would also require a protocol-level adjustment. As it stands today, no-votes on amendments are implicit. Each validator assembles a list of amendments that it both...

1. Up-votes, and
2. It does not think are enabled yet.

See AmendmentTableImpl::doValidation(): https://github.com/XRPLF/rippled/blob/develop/src/ripple/app/misc/impl/AmendmentTable.cpp#L590-L615

Any amendment that is left out of that list is implicitly down-voted by that validator.

We could replace the single array with two separate arrays: one for up-votes and one for down-votes. But, since the default state for most new amendments is currently to down-vote, I'm not convinced that the added complexity brings much value to the table.

My inclination is to close this. The idea and intention were good. But I think the code is currently at a place that accomplishes many of the ends intended by the suggestion.

[MarkusTeufelberger]

The issue is still that it is not clear if validator operators make conscious choices when it comes to amendment (and fee!) votes or if they blindly follow defaults of whoever supplies their binaries. It is great that nowadays amendments are usually introduced as a "DefaultNo" vote into the code base, forcing at least dUNL validators to explicitly enable those, but that is just a current policy, not a feature of the system or software itself.

A protocol level change might be nice to have, but I don't see it as necessary. I just don't want rippled to start validating unless there is a clear choice supplied by the operator(!) how to vote on which amendment and which fee amounts are desired. In fact, I'd like the "Default..." voting feature to be gone from the code base alltogether (or at least be hard-coded to be always "DefaultNo").

I find the idea of storing voting choices during runtime a bit dangerous and highly unintuitive, but it is what it is - still better than defaulting to some/any values. If you operate a validator, you're making choices. Mainly about your UNL, your fee preferences and your amendment preferences. Having these pre-filled with defaults (however sensible - in fact, sensible defaults might be even more dangerous since it promotes trusting them blindly!) is kinda leading to complacency and not participating in the actual progress and direction of the system (hence the initial suggestion of also adding "abstain" votes, so it is at least clear to others who does not actually care or take part in which choice).

Yes, abstaining doesn't make the decisions faster/slower/more transparent or prevents/enables anything, but it would at least give additional information compared to the current situation where default and explicit votes are indistinguishable from each other.

[intelliot]

Due to the benefits of protocol stability and not requiring node operators to frequently take on the overhead, work, and risk of updating rippled, it's worth noting that there are many good reasons to vote against any given amendment simply because it is new, and the risk/reward tradeoff means it's better to activate the amendment later rather than sooner. Notice that this has nothing to do with whether you want (or agree with) the change itself; it's purely a function of amendment blocking: the fact that any protocol change requires the entire network to unanimously have the necessary code installed and running.