Jump to content
yxxyun

Why Checks Amendment haven't been enabled after a year?

Recommended Posts

The Checks Amendment was introduced by rippled 0.90.0

Ripple expects the DepositAuth and Checks amendments to be enabled on 2018-03-15.

The DepositAuth & fix1513 Amendments became available on the XRP Ledger in ledger sequence number 37,753,345 (2018-04-06T01:44:42Z).

but one year passed,  Checks still not enabled. Why ?

@nikb @mDuo13 

Share this post


Link to post
Share on other sites

Because not enough validators are voting to enable them. Specifically, Ripple is not voting to enable them; others may or not be. But it’s not for any nefarious reason.

It is another feature that I don’t know if anyone will ever use so why enable it? Remember once something is activated it can’t ever really go away—it would take another amendment to prevent new checks, but the code couldn’t ever be removed as long as more than a single check existed uncashed on the ledger.

An amendment is basically for life and imposes a certain cost. I think we should weigh that cost against what it buys us instead of just paying it. 

Look at TickSize. It’s enabled and nobody is using it…

Share this post


Link to post
Share on other sites

Well, I think DepositAuth&DepositPreauth, Escrow or PayChan had covered Checks use case.

But for no one use TickSize, there are only 4 gateway left on XRP ledger: bitstamp,  gatehub, ripplefox, ripplechina, lack of gateway cause no one use of TickSize.

Share this post


Link to post
Share on other sites
8 hours ago, nikb said:

Because not enough validators are voting to enable them. Specifically, Ripple is not voting to enable them;

You mean Ripple is explicitly vetoing them, since by default a validator would vote in favor anyways, as long as it knows the proposed amendment, right?

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

Quote

Each version of rippled is compiled with a list of known amendments and the code to implement those amendments. By default, rippled supports known amendments and opposes unknown amendments.

 

Share this post


Link to post
Share on other sites
Posted (edited)
17 hours ago, Sukrim said:

You mean Ripple is explicitly vetoing them, since by default a validator would vote in favor anyways, as long as it knows the proposed amendment, right?

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

 

That’s exactly what I said: “Ripple [validators] [are] not voting to enable them” but if you prefer the term “explicitly vetoing” then I guess Ripple’s validators are among the validators explicitly vetoing this amendment.

I can’t speak for anyone else, but in Ripple’s view, activating a new feature on the ledger is not something to be undertaken lightly; once you activate it, you have to to carry it forever and so the cost-benefit analysis matters; the pros that come with an amendment must outweigh the cons. Maybe this isn’t an important consideration for some but it is for others, myself included.

With that said, my personal preference would be to further enhance checks before enabling the feature, so that we can:

(1) support “certified” checks —that is checks which actually “hold” the amount internally instead of being like “drafts”.

(2) allow a check to be “cashed” in a different currency; for example, I can “cut” a check for 100 USD/Bitstamp and you can cash it, at your convenience, to receive XRP or any available IOU you want by doing a real-time exchange.

Edited by nikb
Apparently I can’t number... it’s 1, 2, 3... not 1, 3.

Share this post


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

You mean Ripple is explicitly vetoing them, since by default a validator would vote in favor anyways, as long as it knows the proposed amendment, right?

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

 

20% or more dominance in the UNL gives a party the veto right. Currently Ripple has a dominance of 25%

Quote

The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support before those changes go into effect. An amendment normally requires 80% support for two weeks before it can apply.

Is Ripple planning to keep this right, or are they ok to also give this out of hand? (in which case you would e.g. no longer be able to block the checks amendment..) 

Share this post


Link to post
Share on other sites
8 hours ago, nikb said:

That’s exactly what I said: “Ripple [validators] [are] not voting to enable them” but if you prefer the term “explicitly vetoing” then I guess Ripple’s validators are among the validators explicitly vetoing this amendment.

I just think there's a difference between opt-in and opt-out (amendment voting is "opt-out" currently). Currently every amendment in the code would become enabled if enough people just update their node software, there needs to be explicit action taken by enough validators at each update that introduces a new amendment to the code base to keep it from being enabled.

Making amendments "opt-in" (instead of maintaining a "[veto_amendments]" section, validators would maintain an "[amendments]" section until the threshold is reached) might make it easier to have more experimental/controversial amendments out there - and changing the default voting behavior wouldn't even require an amendment itself. Isn't it simply crazy that probably most validators out there (that just aren't in the Ripple recommended UNL) vote in favor of SHAmapv2?!

About your features:

1) is possible by doing an Escrow instead. There could also be a field added to Checks that doesn't allow the sender to cancel before expiry. This could be added on top of the current implementation later with little impact (consider all current Checks to not have this field).

2) is possible by doing a single transaction paying myself in a different currency instead which also wouldn't hinder any further extensions of a CheckCash transaction to make this transaction atomic and save a transaction fee of a few drops.

If your fear is that these features won't be used anyways, I'm not sure if adding even more features on top before knowing if they are even popular is worth it. About TickSize for example my issue with it is that I want to set this per currency, not per issuing account. I assume this might be similar for others. Also as yxxyun said, gateways are rare these days. Checks would be a feature that they need.

This features is in purgatory for over a year now, even though it would have real benefits for gateway operators (would ease the huge pain of bootstrapping customers - "first get 25+ XRP, then create a trust line, THEN I can give you the money you sent me!"). It is great to hear that you have ideas to improve it further (I have some ideas too for Checks) - is there some place or process to discuss this further or is that only documented in JIRA? Taking this amendment as example: https://github.com/ripple/rippled/pull/2245 implemented the ticket RIPD-1487 which is not public (https://ripplelabs.atlassian.net/secure/BrowseProjects.jspa is empty), so it kinda came out of the blue (from a non-Ripple perspective) with a full implementation of an undisclosed spec/design, was discussed/reviewed by Ripple employees and then merged. Yet Ripple (amongst others) vetoes it for over a year now for undisclosed reasons (prior to your explanation that you want more features in Checks first).

Share this post


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

I just think there's a difference between opt-in and opt-out (amendment voting is "opt-out" currently). Currently every amendment in the code would become enabled if enough people just update their node software, there needs to be explicit action taken by enough validators at each update that introduces a new amendment to the code base to keep it from being enabled.

Making amendments "opt-in" (instead of maintaining a "[veto_amendments]" section, validators would maintain an "[amendments]" section until the threshold is reached) might make it easier to have more experimental/controversial amendments out there - and changing the default voting behavior wouldn't even require an amendment itself. Isn't it simply crazy that probably most validators out there (that just aren't in the Ripple recommended UNL) vote in favor of SHAmapv2?!

About your features:

1) is possible by doing an Escrow instead. There could also be a field added to Checks that doesn't allow the sender to cancel before expiry. This could be added on top of the current implementation later with little impact (consider all current Checks to not have this field).

2) is possible by doing a single transaction paying myself in a different currency instead which also wouldn't hinder any further extensions of a CheckCash transaction to make this transaction atomic and save a transaction fee of a few drops.

If your fear is that these features won't be used anyways, I'm not sure if adding even more features on top before knowing if they are even popular is worth it. About TickSize for example my issue with it is that I want to set this per currency, not per issuing account. I assume this might be similar for others. Also as yxxyun said, gateways are rare these days. Checks would be a feature that they need.

This features is in purgatory for over a year now, even though it would have real benefits for gateway operators (would ease the huge pain of bootstrapping customers - "first get 25+ XRP, then create a trust line, THEN I can give you the money you sent me!"). It is great to hear that you have ideas to improve it further (I have some ideas too for Checks) - is there some place or process to discuss this further or is that only documented in JIRA? Taking this amendment as example: https://github.com/ripple/rippled/pull/2245 implemented the ticket RIPD-1487 which is not public (https://ripplelabs.atlassian.net/secure/BrowseProjects.jspa is empty), so it kinda came out of the blue (from a non-Ripple perspective) with a full implementation of an undisclosed spec/design, was discussed/reviewed by Ripple employees and then merged. Yet Ripple (amongst others) vetoes it for over a year now for undisclosed reasons (prior to your explanation that you want more features in Checks first).

My position is that upgrading to a newer version of the software which supports a specific amendment is tacit approval of that amendment, hence why the default opt-in behavior makes sense to me. Your mileage may vary.

If you believe (as you seem to) that the default behavior isn’t ideal, by all means submit a pull request making the necessary changes. Submit it as an amendment, and lets allow the network to decide the semantics that it prefers.

I disagree that you can do what I’m proposing with an Escrow. First, escrows don’t support IOUs. Second, escrows lack some of the features that checks have (e.g. the ability to partially cash a check). Lastly, a future extension to allow a check to be cashed out in a different currency by doing a live trade is superior to the multi-step process you describe.

On this topic, don’t fall prey to the logic of “well, X is almost the same as Y, so just use Y and let’s not do X.”

As for ideas: please open issues on GitHub for your ideas. It’s where we want to migrate our internal tracking board, so that we are all working from the same page.

Also, my explanation wasn’t that Ripple is vetoing the feature because it wants more features. You may want to read what I wrote one more time.

 

Share this post


Link to post
Share on other sites
Posted (edited)

@nikb I'm very interested in your comment that "once you activate [the amendment], you have to to carry it forever ...". It is very unclear to me why this is the case. Why can amendments not be entirely undone via a new amendment? What is the fundamental issue here? Is this property of amendments documented somewhere?

I hope you have the time to respond, and would appreciate a detailed explanation :-)

Edited by Dsimmo

Share this post


Link to post
Share on other sites

Imagine for example Checks being enabled for a while and then removed again.

In that case, there would still be ledgers out there that contain Check objects which rippled should be able to (de-)serialize and display ideally instead of crashing or showing just some random-looking hex numbers instead of nicely formatted JSON when you ask for the contents of these objects. The transaction processing part probably could be ripped out, the object descriptions etc. not so much (at least not without causing some pain later).

Share this post


Link to post
Share on other sites
2 hours ago, jn_r said:

20% or more dominance in the UNL gives a party the veto right. Currently Ripple has a dominance of 25%

Is Ripple planning to keep this right, or are they ok to also give this out of hand? (in which case you would e.g. no longer be able to block the checks amendment..) 

There isn't "the UNL".

If you're not happy with Ripple's dominance in your UNL, remove them.

Share this post


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

Imagine for example Checks being enabled for a while and then removed again.

In that case, there would still be ledgers out there that contain Check objects which rippled should be able to (de-)serialize and display ideally instead of crashing or showing just some random-looking hex numbers instead of nicely formatted JSON when you ask for the contents of these objects. The transaction processing part probably could be ripped out, the object descriptions etc. not so much (at least not without causing some pain later).

Ok, so this is specific to checks, rather than a general property of amendments (although, presumably many amendments may have to be treated this way)

Share this post


Link to post
Share on other sites

Amendments are usually introduced if transaction processing is impacted, so a replay of all transactions in a certain ledger might come to a different result with or without the amendment. I don't think that there was a lot of care taken that pre-amendment ledgers are processed with pre-amendment code if replaying them once a certain amendment has passed, so you might already get different results now.

Putting "opt-in-to-Amendments" behind an Amendment by the way would be slightly weird, since that only concerns an implementation detail of rippled, not the protocol itself (I assume that validators actually send votes/vetos, not imply that a missing vote means "yes"?).

Share this post


Link to post
Share on other sites
3 hours ago, dik said:

There isn't "the UNL".

If you're not happy with Ripple's dominance in your UNL, remove them.

I know it is possible to deviate from Ripple's UNL, but as I see it, you either stick with it for the greater part, or you don't. If you don't (with no overlap with the original UNL) you choose for a hard fork and start a new network with a UNL that is managed by another party. Small deviations are possible, but I would be careful not to deviate too much, or you will fork or halt.

In my view Ripple - as manager of the current UNL we all use - is the guardian of what we now call the XRPLedger.  The UNL is the central part of it and you can choose to follow that UNL or not. 

Within this sphere of the Ripple UNL decisions have to be made that require governance. Apparently one of the governance rules that currently apply is that Ripple has veto rights in the process of accepting amendments. The choice of keeping this rights might be a good one or it might not. I think at this stage the better choice is to still keep these rights at Ripple as I trust them in making the better decisions, but that might change if the validators become more mature in their decision making (- maybe I am underestimating the validator holders in that regard)  

N.B. with veto rights I mean one party that has the power to say 'no' such that it can not be overruled. I am not sure why the stanza is called 'veto_amendments' in the rippled.cfg. In my view there it means just a 'vote against' from that specific validator and not a 'veto'. Only Ripple can make the veto as they currently hold >20% of the validators

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