XRP FORK

[BobMoneybags]

Could somebody break this down to a somewhat abridged explanation for the average interested layman such as myself? I am getting the impression that 80% of the UNLs would have to come to an agreement for a fork to happen? Thank you in advance to anyone that contributes. I'm not suggesting it could fork, just saw some FUD on Twitter about it and wanted clarity.

[Flintstone]

I respect Sukrim’s opinions as he can be a bit critical (for want of a better word) of the XRPL sometimes and has a much better understanding than most as he’s been around a good while. Here’s a similar question on Reddit where he responds. https://i.reddit.com/r/Ripple/comments/bs6kr2/security_concern/

He’s also a member here if you want to discuss it more in depth. Throw him or mDuo an @tag if you can’t find your answer.

To try and answer your question, I think you need 80% agreement of all validators to make changes to the code base.

For a fork, I think you only need a few trusted validators, but if your transactions differ from the main ledger, they will be excluded. (I have no clue what happens here regarding the fork and how it works ledger-wise)

Trying to gain an 80% majority by trying to convince the rest of the network that your fork is better would be extremely difficult.

I could be totally wrong so don’t go on what I’ve said.

[dik]

12 hours ago, Flintstone said:

Trying to gain an 80% majority by trying to convince the rest of the network that your fork is better would be extremely difficult.

In XRP ledger you can define your network. Your network starts with your own UNL. So you can simply only include validators that agree with you, and there's your 80% majority.

You just won't be able to transact on chain with the other guys.

It surprises me that nobody has done it yet, I think it is a good idea. It will illustrate two things:

1. forking XRP Ledger is super easy, it is designed that way.

2. making the market believe your fork is valuable is very hard. 

3. unless you've got a really better idea. which this probably isnt. but if it is: all the better! then it will be illustrated how easy it is to migrate to a better version of itself. as designed.

[Pablo]

20 minutes ago, dik said:

1. forking XRP Ledger is super easy, it is designed that way.

2. making the market believe your fork is valuable is very hard.

The above seems to contradict the consensus whitepaper in a fundamental way. Here's the relevant passage which takes as an assumption a clique of nodes that has created its own, self-referential UNL to "fork" the network:

Quote

This upper bound assumes a clique-like structure of UNLs, i.e. nodes form sets whose UNLs contain other nodes in those sets. This upper bound guarantees that no two cliques can reach consensus on conflicting trans-actions, since it becomes impossible to reach the 80% threshold required for consensus...

https://ripple.com/files/ripple_consensus_whitepaper.pdf

On this basis, trying to fork the current XRP network will fail the agreement requirements of the consensus protocol because you can't achieve 80% consensus of the network from which you took the originally correct ledger. Here's the intro of the paper confirming this design feature of the XRP ledger:

Quote

Since each node in the network only votes on proposals from a trusted set of nodes (the other nodes in its UNL),and since each node may have differing UNLs, we also show that only one consensus will be reached amongst all nodes, regardless of UNL membership. This goal is also referred to as preventing a “fork” in the network: a situation in which two disjoint sets of nodes each reach consensus independently, and two different last-closed ledgers are observed by nodes on each node-set.

 

[dik]

15 minutes ago, Pablo said:

The above seems to contradict the consensus whitepaper in a fundamental way. Here's the relevant passage which takes as an assumption a clique of nodes that has created its own, self-referential UNL to "fork" the network:

https://ripple.com/files/ripple_consensus_whitepaper.pdf

On this basis, trying to fork the current XRP network will fail the agreement requirements of the consensus protocol because you can't achieve 80% consensus of the network from which you took the originally correct ledger. Here's the intro of the paper confirming this design feature of the XRP ledger:

 

 

[Pablo]

1 hour ago, dik said:

 

Thanks @dik - David's tweet and @Sukrim's reddit posts don't line up with how I (and others) have read the whitepaper. I assumed (probably wrongly) that XRP was never forked because it was near impossible to do so. The fact it hasn't is still very interesting to me because it means the economics of forking XRP simply aren't there... yet.

The forks on PoW coins definitely brought a lot more liquidity to BTC and ETH. Even the insane bitcoin cash split created additional value for holders of Bitcoin and Bitcoin Cash ABC.

Which brings me back to Cryptolord's suggestion of forking XRP as a way of cutting ties with Ripple. I wonder if there's something more going on with his proposal that's tied to boosting value/liquidity.

[Guest]

2 hours ago, dik said:

 

I believe you have misunderstood what David is saying.  Those rules he mentions are coded in...  you won’t have forked the XRPLedger into two chains,  you will have created a new one starting from the existing code.  Just as XLM did.

As I understand it,  consensus can move forward or it can halt but can’t head off in multiple directions.  I will admit I’ve only casually read up on it and could be wrong.

This might be a learning opportunity for those of us who don’t have it correct...  (that could easily be me).

[Sukrim]

22 minutes ago, Tinyaccount said:

Those rules he mentions are coded in...  you won’t have forked the XRPLedger into two chains,  you will have created a new one starting from the existing code.  Just as XLM did.

Nope, validators manage to fork off all the time if they can't fetch their centrally hosted UNL and only trust themselves. You can take any state on the ledger and start building on top of it. The difficulty is to convince others to join you in your efforts.

Stellar started a new chain from scratch (just like the Testnet vs. Mainnet - both running from the same code base and on the same network), what OP is also hinting at is that it would also be possible to coordinate and e.g. say "starting from ledger 50.000.000 we'll enable the Checks amendment, no matter what!" Then it would likely lead to a situation where some validators are for and some against this. As long as 80%+ of the UNLs of these validators consist of other validators that agree with their opinion, both can exist. One might be the "Checknet" and the other the "Nochecknet". Which one has more value and is more viable to run in the long term remains to be seen, but similar to ETH and ETC or BCH and BTC both might have some value. Replay protection might be an issue, so I wouldn't recommend doing this right now - it definitely is possible to do so though.

Another potential fork example could be to take an existing ledger, remove Ripple's Escrow objects and move forward from there if you are concerned about their wealth.

36 minutes ago, Pablo said:

I assumed (probably wrongly) that XRP was never forked because it was near impossible to do so.

It is impossible to do so under the assumptions that UNLs of validators overlap with more than 20(?)%, so no fork can get validated. If it is also impossible that the network makes forward progress and there can't be cascading failures (validator 1 can't find a majority on its UNL and stops, so validator 2 can no longer find a majority etc.), UNLs need to overlap more than 90(?)% - I'm not totally sure about the numbers, but somewhere in this ballpark. The way to guarantee/ensure this overlap is currently by proposing centralization, it is a bit unclear what would happen if Ripple stops being reliable or trustworthy with their vl.ripple.com service (e.g. they seem to keep some slightly wonky validators on there and don't publish ANY inclusion or exclusion criteria).

[Flintstone]

@Sukrim

Edited August 27, 2019 by Flintstone
Damn, that was fast. You even turned up before I hit Go!

[Guest]

7 minutes ago, Sukrim said:

Nope, validators manage to fork off all the time if they can't fetch their centrally hosted UNL and only trust themselves. You can take any state on the ledger and start building on top of it. The difficulty is to convince others to join you in your efforts.

Ah thanks so much for clearing that up.  

One of the reasons I thought I was correct and didn’t think it was possible was the sanity check of “if it was possible then surely the haters would have done it already just to muddy the waters”.  

Which now begs the question...  why haven’t they?  It would be a pathetic coup of sorts if they could ‘fork’ into a haters chain and create the nonsense that’s multiple times muddied Bitcoin waters.

[Sukrim]

You need operational expertise and a single server forking off is not really exciting at all. It is also very hard to profit from this, typically people prefer forking from genesis, so they can own a certain amount of coins themselves (e.g. Stellar, Casinocoin...).

You'll waste a month or more of time and a few hundred/thousand USD to show... that you can run rippled. So you'll also need a good story and some momentum. It would be doable, but it requires a lot more work than just hating something. Also, if you really hate XRPL, why would you build on top of it?

[kanaas]

30 minutes ago, Sukrim said:

Also, if you really hate XRPL, why would you build on top of it?

Good Q.... Probably Jed knows? 

[Coolio]

vokez.io

SystemD

[Guest]

Scroll all the way through these tweets. Ethan made some good points.

https://xrpl.org/consensus-protections.html

In general, consensus can continue without problems as long as only a small percentage (less than about 20%) of trusted validators are misbehaving at a given time. (For the exact percentages and the math behind them, see the latest Consensus Research.)

If more than about 20% of validators are unreachable or not behaving properly, the network fails to reach a consensus. During this time, new transactions can be tentatively processed, but new ledger versions cannot be validated, so those transactions' final outcomes are not certain. In this situation, it would become immediately obvious that the XRP Ledger is unhealthy, prompting intervention from human participants who can decide whether to wait, or reconfigure their set of trusted validators.

The only way to confirm an invalid transaction would be to get at least 80% of trusted validators to approve of the transaction and agree on its exact outcome. (Invalid transactions include those spending money that has already been spent, or otherwise breaking the rules of the network.) In other words, a large majority of trusted validators would have to collude. With dozens of trusted validators run by different people and businesses in different parts of the world, this would be very difficult to achieve intentionally.

 

 

For all participants in the XRP Ledger to agree on what they consider validated, they must start by choosing a set of trusted validators that are fairly similar to the sets chosen by everyone else. In the worst case, less than about 90% overlap could cause some participants to diverge from each other. For that reason, Ripple publishes a signed list of recommended validators, including trustworthy and well-maintained servers run by the company, industry, and community.

By default, XRP Ledger servers are configured to use a validator list site run by Ripple. The site provides a list of recommended validators (also known as a recommended Unique Node List, or UNL), which Ripple updates periodically. Servers configured this way trust all validators in the latest version of the list, which ensures 100% overlap with others also using the same list. The default configuration includes a public key that verifies the authenticity of the site's contents. In case the site goes down, servers in the XRP Ledger's peer-to-peer network can directly relay the signed updates to the list among themselves.

Technically, if you run a server, you can configure your own list site or explicitly choose validators to trust on an individual basis, but Ripple does not recommended doing so. If your chosen set of validators does not have enough overlap with others, your server may diverge from the rest of the network, and you could lose money by taking action based on your server's divergent state.

Research is ongoing to design an improved consensus protocol that allows more heterogeneous validator lists.

[Guest]

On 8/27/2019 at 11:01 AM, Sukrim said:

Another potential fork example could be to take an existing ledger, remove Ripple's Escrow objects and move forward from there if you are concerned about their wealth.

 

Just disable https://xrpl.org/known-amendments.html#escrow ? (An amendment normally requires 80% support for two weeks before it can apply. You'd need to introduce a new amendment to disable an amendment :-))