UNL and divergence

[ZzZerper]

So if a bunch of nodes adopt the same UNL that does not include any nodes outside their group, does that allow them to do the equivalent of a fork?

[JoelKatz]

Yes, that would be one way to do an intentional fork. The forked off group could then make any code and amendment changes that they wanted.

[kanaas]

Reasons enough to be prudent and this one perhaps in particular a very good reason for the “low” value of XRP as well
Risk will always be imminent you know....

[Sukrim]

8 hours ago, ZzZerper said:

So if a bunch of nodes adopt the same UNL that does not include any nodes outside their group, does that allow them to do the equivalent of a fork?

This is how e.g. the TestNet works.

Note that there are 2 scenarios: You start on the Mainnet and just adopt a new, common UNL. Once >20% validators on that UNL disagree for whatever reason (can be just network fluctuations) with Mainnet, your bunch of nodes will stop working because they can't agree. In the rare case that >80% of these new validators agree on something else, they will create a (hard)fork in the chain, meaning that you start with a lot of state already (Ripple owns Escrow objects, a million+ Accounts exist...). Think BCH/BTC or ETH/ETC.

The other scenario is to start from scratch. Create a genesis block, tell your bunch of nodes to build on top of it and start validating. This would be a full restart of the chain. Think TestNet/MainNet, Ripple/Stellar, BTC/LTC.

[Rey]

If you want to know more about this, read the documentation about the consensus protocol used by the XRPL ...

You can find that information at https://xrpl.org/intro-to-consensus.html

[Guest]

3 hours ago, kanaas said:

Reasons enough to be prudent and this one perhaps in particular a very good reason for the “low” value of XRP as well
Risk will always be imminent you know....

I don’t believe that is the case at all.  

This ‘imminent’ risk that you mention is that some group of people will do their own thing and in the process create another coin to add to the thousands that exist.  

They will not have any of the exchange or institutional support that the XRPL currently enjoys, and having forked will no longer be part of the ecosystem around the XRP Ledger.

So that doesn’t really seem to be an “imminent risk” to the XRPL to me.  And accordingly has no part in any pricing of XRP.

[jn_r]

Sorry for a bit off-topic question, but is amendement really the only way to have others accept breaking changes to the rules of updating the ledger?

Just thinking of a scenario where the UNL owner (Ripple in the case of vl.ripple.com) is hacked and a new UNL is published with a bunch of malicious validators. Nearly all nodes will blindly take the new UNL for granted - at least for a short time - in which incorrect ledgers could be published. 

In that short time, I am not sure what will happen. Will the other nodes sort of 'stutter' but soon enough 'give up' and find agreement to use the new proposed ledgers from the malicious validators, or will they just not accept because the rules are not applied?

[kanaas]

I don’t believe that is the case at all.  
This ‘imminent’ risk that you mention is that some group of people will do their own thing and in the process create another coin to add to the thousands that exist.  
They will not have any of the exchange or institutional support that the XRPL currently enjoys, and having forked will no longer be part of the ecosystem around the XRP Ledger.
So that doesn’t really seem to be an “imminent risk” to the XRPL to me.  And accordingly has no part in any pricing of XRP.

Have this doubt as well myself. But ..... one just never knows.

For instance IMF likes to fork XRPL and creates.... 100B (X)SDR... on that new ledger because.... (central) banks asked them to circumvent “huge currency reserves by private sector”? Unthinkable? Guess not...


Verzonden vanaf mijn iPhone met Tapatalk

[Guest]

Interesting discussion. I love reading Sukrim's posts, always a good read.

By the way, Stellar's David Mazières co-authored 2 new papers (https://www.scs.stanford.edu/~dm/home/papers/)

Really a good read, "Deployment experience" and "Evaluation" sections of the latest paper are very interesting.

They actually have written a section about a formal verification of SCP (https://www.scs.stanford.edu/~dm/home/papers/lokhava:stellar-core.pdf) . To eliminate design errors, they formally verified SCP’s safety and liveness properties (https://github.com/stellar/scp-proofs) .

Does something like this exists for Ripple? A quick look at Ripple's github says "nope".

On top of that they compare SCP with Cobalt in a teasing way:

"Ripple also more recently proposed an open-membership Byzantine agreement protocol called Cobalt. SCP’s safety is optimal, so SCP is safe in any failure scenario where Cobalt is, while the converse is unclear. However, Cobalt claims its safety condition is easier to understand and thus less prone to misconfiguration , which will be interesting to evaluate if Cobalt gets deployed."

It's funny to read that Ethan MacBrough actually started to work/research Cobalt mid 2017 and that 2 years later not much happened.

To me this was as expected and not so surprising as to some (twitter) folks. Mainly because of this:

• The fact that there was only one author of the paper. Satoshi and Albert (you'll guess which ones I mean) occasionally do that too. Note that I respect Ethan very much but " one man Ripple research team" is just too weird for me
• It was not a paper that's published in a peer-reviewed journal, the white papers let you get away with the claims that might not always be true
• Nik, to name one,  likes to remind us on twitter that it is not some kind of magical pixie dust but just a research paper. Well 2 years later it turns out that it was just catching dust.

Now that we know that Cobalt will (most likely) never happen, let's see what kind of other (radical) upgrades to consensus algorithm will Ripple team/XRPCommunity come up with.

 

Edited September 8, 2019 by Guest

[Guest]

Assuming the following. "In the XRP Ledger Consensus Protocol, each participant p is responsible for configuring its own UNL, which is a list of other participants that p will accept messages from. Moreover, p will accept as a quorum any set of participants consisting of more than a fixed fraction (defined system-wide by the protocol, e.g. 80%) of its UNL. Maintaining agreement in Ripple’s protocol rests on the assumption that participants will provide sufficiently overlapping UNLs (roughly 90% for every pair of participants, in the most adversarial model of Chase and MacBrough".

How many people/validators have actually tweaked the recommended validators list (UNL)? What's the optimal number for that set i.e. how many validators should I have in my own UNL? What's the best approach to remove and/or add validators to the list while still maintaining a sufficient overlap?  Will it be possible, in the near future, to have several lists, with potentially different # of participants, so that the user can assign a priority to that list in case of a recent Stellar-like halt? Something like high, medium, low UNLs to switch between in case of issues...

 

[Guest]

7 hours ago, kanaas said:

For instance IMF likes to fork XRPL and creates.... 100B (X)SDR... on that new ledger because.... (central) banks asked them to circumvent “huge currency reserves by private sector”? Unthinkable? Guess not...

If IMF wanted to use the XRPLedger code because of its excellent technical properties they almost certainly would not ‘fork’ the ledger.  

They would clone the repository and create a brand new IMFCOIN with potentially different settings regarding consensus ratios and timeouts and  total number of coins etc.  Their use case could be slightly different than XRPL because if they were doing it themselves they would be using a permissioned and centralised model.  So they would make a coin like Stellar and CSC did.

If on the other hand they wanted to make use of the existing ledger with its existing nature and participants then they would probably approach Ripple about their stack (liquidity pool if transferred to IMF).

The latter case would probably be a great net gain for all of us.

The former case would be direct competition for the cross border use case,  but would not negate the other micro-payments use cases.  So that is a one of the many risks I suppose, but it doesn’t have any indications of happening so far that I know of.

 

But none of that would be an ‘imminent risk’ of a fork of XRPL as you described.

 

[kanaas]

If IMF wanted to use the XRPLedger code because of its excellent technical properties they almost certainly would not ‘fork’ the ledger.  
They would clone the repository and create a brand new IMFCOIN with potentially different settings regarding consensus ratios and timeouts and  total number of coins etc.  Their use case could be slightly different than XRPL because if they were doing it themselves they would be using a permissioned and centralised model.  So they would make a coin like Stellar and CSC did.
If on the other hand they wanted to make use of the existing ledger with its existing nature and participants then they would probably approach Ripple about their stack (liquidity pool if transferred to IMF).
The latter case would probably be a great net gain for all of us.
The former case would be direct competition for the cross border use case,  but would not negate the other micro-payments use cases.  So that is a one of the many risks I suppose, but it doesn’t have any indications of happening so far that I know of.
 
But none of that would be an ‘imminent risk’ of a fork of XRPL as you described.
 

You’re right, it would not kill XRPL, rather vapor some 589 dreams going around here [emoji3]

[mDuo13]

There are several important topics being discussed in this thread and it's hard to address all of them adequately, but I'll try.

First, the scenario @jn_r described is my personal biggest concern for the XRP Ledger. If Ripple's recommended UNL was changed maliciously, I think it's an open question how the ecosystem would react. I don't think the technology has been specifically tested for this scenario, but it seems plausible to me that servers that trust the recommended UNL could report manipulated data until their operators realized what was happening. Now, it wouldn't be that easy for someone outside of Ripple to change the recommended UNL maliciously (you'd need control over both the domain and the key used to sign the UNL) but it's not out of the question that a rogue Ripple employee with privileged access or a government-level power applying pressure to Ripple could make it happen. This is a risk I'd really like to see addressed. So far as I've seen, the approach with the best potential would be to have a list that's either multi-signed, or requires agreement for some M-of-N lists. (Right now there are two kind of closely related entities publishing recommended UNLs—Ripple and Coil—so there's still some need for the ecosystem to grow for that to happen.)

Meanwhile, others can and have created forks of the XRP Ledger, generally using the "from scratch" approach Sukrim described. Several have also forked the software itself, like Stellar, CasinoCoin (who forked our old docs), RADAR (who forked our even older docs, lol), etc. These projects don't quite have the same combination of credibility (including continuity!), technical expertise, regulatory expertise, and existing business relationships that Ripple has. (It's probably unfair to group Stellar with those other two, but, whatever.) Now, maybe a big company or organization could try to do the same thing, but at this point, I think it's not too likely. Either they can accept that many of the world's leading blockchain experts already work at Ripple so they may as well just work with us, or they don't like what we've done and they may as well lift a few of the good ideas while rebuilding the code from scratch (basically what Facebook did with Libra).

[ZzZerper]

On 9/8/2019 at 4:57 PM, crypto_deus said:

Now that we know that Cobalt will (most likely)

Why?

[codex]

On 9/11/2019 at 3:30 PM, mDuo13 said:

There are several important topics being discussed in this thread and it's hard to address all of them adequately, but I'll try.

First, the scenario @jn_r described is my personal biggest concern for the XRP Ledger. If Ripple's recommended UNL was changed maliciously, I think it's an open question how the ecosystem would react. I don't think the technology has been specifically tested for this scenario, but it seems plausible to me that servers that trust the recommended UNL could report manipulated data until their operators realized what was happening. Now, it wouldn't be that easy for someone outside of Ripple to change the recommended UNL maliciously (you'd need control over both the domain and the key used to sign the UNL) but it's not out of the question that a rogue Ripple employee with privileged access or a government-level power applying pressure to Ripple could make it happen. This is a risk I'd really like to see addressed. So far as I've seen, the approach with the best potential would be to have a list that's either multi-signed, or requires agreement for some M-of-N lists. (Right now there are two kind of closely related entities publishing recommended UNLs—Ripple and Coil—so there's still some need for the ecosystem to grow for that to happen.)

Is there a limit to the number of UNL changes a server will accept when using a dynamic list published by someone else? If a server refused to add or remove more than a handful of validators per day (unless done manually), it seems that would reduce the damage a rogue Ripple employee could cause with a mass change. I suppose the same thing could still happen, but it would have to occur over a longer period of time and would be detected by many in the community before things got out of hand.