How does Ripple consensus deal with forks?

[caveden]

Hello all,

I'm trying to understand this new cryptocurrency making the buzz lately.
Ripple looks interesting. For what I can see, there are two different things in Ripple (as in BTC): the "payment network", a p2p trust-based network, that might be useful in many situations, and  the "ripple currency", a cryptocurrency that does not use a blockchain for consensus.
AFAICT, the payment network is totally complementary to Bitcoin. Actually, I think they could have just developed this payment network and have used BTC as settlement currency if they wanted, but it seems they had more ambition.
The XRP is not complementary to BTC, though. It's a competitor. And perhaps the first one with potential to shake things on the cryptocurrency world.
The main difference between XRP and all BTC-based cryptocurrencies is the fact that the p2p consensus is obtained without the use of a blockchain. That's quite interesting, because a blockchain is an expensive thing to maintain. If XRP consensus can prove itself to be as safe as the blockchain, then I see no reason to keep spending so much money to keep this expensive data structure. If their p2p consensus is really safe, eventually they would beat BTC.

So, I started reading about ripple and went right away to the consensus wiki article.

After reading it I had a doubt. I imagine there is a solution to this, but I just couldn't find it detailed anywhere.
How does this consensus process deal with a fork?

With a blockchain it's pretty straightforward: the larger (as in amount of calculus done) chain wins. Simple. Even if a piece of the Internet is temporarily disconnected from the rest of the world, as soon as a single link between them is available, consensus will be once again established by having everybody accepting the largest chain.

How does that work with Ripple?
Say node A has a UNLa and node B has a UNLb. And suppose the intersection between these two UNLs is small, like, less than 20% of the size of each.
Isn't it possible that node A sets on a different Transaction Set than node B? Both nodes will agree with the large majority of their UNL, it just happens that their UNLs don't agree among themselves. Couldn't that "fork" the network, at least temporarily? How does the Ripple protocol avoids and/or fixes such forks?

By the way, won't the Ripple people create a forum.ripple.com for questions like this? (so that eventually it gets crowded with trolls saying lots of BS and making those responsible for ripple.com ashamed and, in an elitist attempt not to get mixed with such trolls, kick the forum to a new domain like rippletalk.org or something  )

[Sunny King]

How does that work with Ripple?
Say node A has a UNLa and node B has a UNLb. And suppose the intersection between this two UNLs is small, like, less than 20% of the size of each.
Isn't it possible that node A sets on a different Transaction Set than node B? Both nodes will agree with the large majority of their UNL, it just happens that their UNLs don't agree among themselves. Couldn't that "fork" the network, at least temporarily? How does the Ripple protocol avoids and/or fixes such forks?

I think both gmaxwell and me had doubts over this issue, but so far I haven't heard any solution.

[dchapes]

I think both gmaxwell and me had doubts over this issue, but so far I haven't heard any solution.

Then you haven't been paying attention or didn't care enough to search. I've seen JoelK (I think) answer these kinds of questions at least a few times.

[caveden]

I've seen JoelK (I think) answer these kinds of questions at least a few times.

Care to link it here? I couldn't find it. Thanks.

By the way, I believe the wiki article should be edited to answer this question as I don't think I'm going to be the last one asking it.

[caveden]

bump

[TheSeven]

I don't remember where I read it, but I think Joel Katz said that this situation is a UNL misconfiguration from their point of view that will require manual intervention to be resolved.

[caveden]

Bump.

I think Joel Katz said that this situation is a UNL misconfiguration from their point of view that will require manual intervention to be resolved.

But how do you solve it? How do you know which ledger is correct? You manually pick one, randomly? How do you get everybody to pick the same?

Assuming all sides of the fork(s) are honest, there should be a deterministic way to solve it.

[Come-from-Beyond]

I suspect Ripple's consensus approach is flawed and this is the main reason they keep the sources closed.

But I found a way to check it in practice - https://bitcointalk.org/index.php?topic=203877.0.

[cdog]

A: OpenCoin prints another 100 Billion XRP and laughs as fools lap it up like homeless cats drinking sour milk.

[🏰 TradeFortress 🏰]

A: I believe transactions will simply not be accepted if there is no consensus (ie there's a fork). The user then has to change their settings.

[caveden]

A: I believe transactions will simply not be accepted if there is no consensus (ie there's a fork). The user then has to change their settings.

How do you even detect a fork's happened?

And how does "change their settings" fix the problem? How do you decide which fork is good and which is not? If human intervention is necessary, we may suppose that at best it would take several hours - probably several days - to come to an agreement on a "good UNL". Doesn't that open the door to dangerous double-spends? (imagine a Bitcoin reorg of hundreds of blocks)

[caveden]

The forkers would be ignored and cut out.

Of course they'd be "ignored", that's the very definition of a "split", each part of the network believe in its version of the ledger. But how do they get to common ground? How do you fix the split and merge everything back, without allowing for dangerous double-spends?

Since every validation must be signed, it is blatantly apparent who is lying.

I'm not talking about lying, I'm talking about honest splits, please read OP.
If my node's ULN doesn't share a large intersection with your node's ULN, we may split. Specially considering the high settlement frequency Ripple supposedly works with. At least that's my understanding of the protocol.

It is all reputation based - so if I have a reputation as a good validator people will choose to trust my node as a validator.

I'm not sure ordinary users would even bother to know what a validator is, let alone a good one, but anwyays, that's not the question.

Imagine taking out all of the spammers, "dust bunnies," and bad guys from the Bitcoin protocol

You'll only take out scammers and others if you introduce chargeback. But then you only push the problem onto merchants actually, who can take no action to counter these scammers (only their direct victims could have potentially done so)

Even if 80% of validators that somehow managed to gain trust decided to fork Ripple dishonestly the major exchanges, institutions, and people who matter in commerce would cut them out immediately and would never trust them again as validators based on their signatures.

You might be right. On the other hand, protocol changes can be introduced without people having to change their clients. If 80% of validators decide to introduce some change in the protocol, your node will automatically consent to it. In Bitcoin, you'd need to take the action of updating to the new protocol version.
I wonder if that's not a potential vulnerability. How many big actors would really change their validators? Introducing dangerous changes little by little, wouldn't that be a possibility?

What's more is that Bitcoin cannot change it's core without becoming an entirely different protocol.

I consider that an advantage. The contract doesn't change without your explicit and active consent. In Ripple, you may "consent" without even knowing it (passively).

If we increase the size of blocks we move toward centralization

That's false and FUD.

Even if Moore's law results in better connectivity and speed, we are still wasting all this electricity and processing power on mining just to prevent the 51% attack. Ripple helps solve these problems and is a happy medium.  

Granted, mining is costly. But I'm still not 100% convinced Ripple actually "solves it". Nobody has yet answered this topic's question: how does ripple deal with splits/forks?

I would rather embrace a distributed, technically unified protocol that will transition from centralized to decentralized than a fragmented, bottlenecked protocol which will transition from decentralized to centralized.

Bitcoin is neither.

[datz]

Of course they'd be "ignored", that's the very definition of a "split", each part of the network believe in its version of the ledger. But how do they get to common ground? How do you fix the split and merge everything back, without allowing for dangerous double-spends?

I'm not talking about lying, I'm talking about honest splits, please read OP.
If my node's ULN doesn't share a large intersection with your node's ULN, we may split. Specially considering the high settlement frequency Ripple supposedly works with. At least that's my understanding of the protocol.

since everything is signed you know generally who the other validators are and can prevent splits/merge them.

If a validator cannot keep up with the load of transactions being voted into the consensus set, it will switch to issuing partial validations. These let those who trust it know that it is not split off from the network (and potentially validating other ledgers). In addition, validators will raise the transaction fees they demand to prevent the network from shrinking to a small set of "super nodes", as that would increase the risk of collusion.

remember, this is a distributed network, so each validator comes into play to reach consensus. If one node's unique node list agrees on one ledger, that node will also agree on that ledger. Since every node has a unique node list and all ledgers/validators are signed, the network can never fork in a significant manner since the network essentially knows all the node players and knows which node players signed what.

I'm not sure ordinary users would even bother to know what a validator is, let alone a good one, but anwyays, that's not the question.

ordinary users would not have to know what a validator is

You'll only take out scammers and others if you introduce chargeback. But then you only push the problem onto merchants actually, who can take no action to counter these scammers (only their direct victims could have potentially done so)

i wrote "spammers" not "scammers." even scammers are less of an issue due to universally or widely trusted gateways and gateway ious, most which will comply with the "know your customer" laws.

You might be right. On the other hand, protocol changes can be introduced without people having to change their clients. If 80% of validators decide to introduce some change in the protocol, your node will automatically consent to it. In Bitcoin, you'd need to take the action of updating to the new protocol version.
I wonder if that's not a potential vulnerability. How many big actors would really change their validators? Introducing dangerous changes little by little, wouldn't that be a possibility?

not really, the slightest change could get you distrusted and ignored in the validator pool.  

I consider that an advantage. The contract doesn't change without your explicit and active consent. In Ripple, you may "consent" without even knowing it (passively).

this just means Bitcoin cannot update to become what Ripple is - cannot simply update once something catastrophic happens.

That's false and FUD.

https://bitcointalk.org/index.php?topic=208200.0

Granted, mining is costly. But I'm still not 100% convinced Ripple actually "solves it". Nobody has yet answered this topic's question: how does ripple deal with splits/forks?

see above.

Bitcoin is neither.

Bitcoin is fragmented (services) and bottlenecked to some degree. As a coder, in order to achieve complex builds, I have to code into several APIs and rely on several servies which could die at any time. There are many moving parts. Bitcoin will become more centralized not less - it's a tradeoff.  

[caveden]

Of course they'd be "ignored", that's the very definition of a "split", each part of the network believe in its version of the ledger. But how do they get to common ground? How do you fix the split and merge everything back, without allowing for dangerous double-spends?

I'm not talking about lying, I'm talking about honest splits, please read OP.
If my node's ULN doesn't share a large intersection with your node's ULN, we may split. Specially considering the high settlement frequency Ripple supposedly works with. At least that's my understanding of the protocol.

since everything is signed you know generally who the other validators are and can prevent splits/merge them.

If a validator cannot keep up with the load of transactions being voted into the consensus set, it will switch to issuing partial validations. These let those who trust it know that it is not split off from the network (and potentially validating other ledgers). In addition, validators will raise the transaction fees they demand to prevent the network from shrinking to a small set of "super nodes", as that would increase the risk of collusion.

remember, this is a distributed network, so each validator comes into play to reach consensus. If one node's unique node list agrees on one ledger, that node will also agree on that ledger. Since every node has a unique node list and all ledgers/validators are signed, the network can never fork in a significant manner since the network essentially knows all the node players and knows which node players signed what.

This is not clear to me.
It seems you're saying that for it to work, all nodes would have to basically set the same ULN, or at least do not set ULNs which are meaningfully different.

That's not a desirable requirement. More than that, I don't see how could you guarantee it.

I'm correct to assume that the validation consensus need not to be unanimous, right? If 10% of your ULN doesn't agree with the ledger, you simply ignore them and trust the other 90%, right?
Then how do you guarantee a split won't happen?
Or else, how do you fix a split once it happens? Manual reconfiguration cannot be an option. It could take too long and make people vulnerable to double-spends.

ordinary users would not have to know what a validator is

You say what's above, then you say this:

not really, the slightest change could get you distrusted and ignored in the validator pool.  

But how, if most people don't even know what a validator is? Who would distrust the validator implementing "slight changes"?

i wrote "spammers" not "scammers."

Sorry, my bad. (there's no actual spamming problem in the blockchain though... these dust rules were mostly unnecessary IMO)

this just means Bitcoin cannot update to become what Ripple is - cannot simply update once something catastrophic happens.

Of course it can, we saw it happening this year with the 0.7 Berkeley DB issue.

That's false and FUD.

https://bitcointalk.org/index.php?topic=208200.0

I'm aware of retep desperate attempts to spread this false idea. It doesn't make it correct though.

[datz]

This is not clear to me.
It seems you're saying that for it to work, all nodes would have to basically set the same ULN, or at least do not set ULNs which are meaningfully different.

That's not a desirable requirement. More than that, I don't see how could you guarantee it.

I'm correct to assume that the validation consensus need not to be unanimous, right? If 10% of your ULN doesn't agree with the ledger, you simply ignore them and trust the other 90%, right?
Then how do you guarantee a split won't happen?
Or else, how do you fix a split once it happens? Manual reconfiguration cannot be an option. It could take too long and make people vulnerable to double-spends.

validators are encouraged to build slightly different UNLs (default UNLs [universally trusted] may be shared upon initial build if not changed) and are discouraged from sharing their UNLs for fear of collusion or conformity. splits can theoretically happen with any protocol if one group of nodes decides to change the software they run. algorithmically, splits are not going to happen with the Ripple protocol unless a group of renegades intentionally wants to split and even then they will not be trusted by legitimate businesses. a natural split is algorithmically unlikely or impossible because as a whole a subbranch of nodes with shared nodes on a UNL must agree on a specific ledger. consensus will simply stall or hold up if a "split" happens - without core software changes a "split" only means failure to reach consensus. this could only occur if people are using totally disparate, non-overlapping UNLs which will not happen in practice due to defaults and universally trusted nodes. if a software change is enough that a large subset of nodes is cut off from the main Ripple protocol entirely, that is basically the same as if someone just created a new alt coin. official updates to the protocol will never put the network at risk in this manner. tapping into the protocol means you are using core ripple technology and you may only differ from other nodes in the distributed network by only configurable environmental variables which by the design of Ripple cannot force a fork. if you are a validator and doing fishy things you will be distrusted and ignored, rendering your efforts to influence the network useless. if one group wanted to run a Ripple local network in parallel to the main one as a fork, and then try to enter the main network, the local network would be distrusted and ignored by legitimate nodes in the main network (the ledgers would be completely incompatible).

But how, if most people don't even know what a validator is? Who would distrust the validator implementing "slight changes"?

people running clients who are not validators need not worry about it. they may use the default list of UNLs.

Of course it can, we saw it happening this year with the 0.7 Berkeley DB issue.

we can update something like block size - there are configurable variables we can change from version to version. the core structure of Bitcoin can never change without Bitcoin becoming an entirely different protocol and without conducting a 1:1 value transfer agreement outside the blockchain.

I'm aware of retep desperate attempts to spread this false idea. It doesn't make it correct though.

regardless of that childlike campaign, the simple fact remains: the bigger the block the longer the transmission time. we are essentially relying on Moore's Law here in network capacity which does not apply across the board in computing. still, there are other issues described above.

[datz]

Also, it is all about UNL overlap.

[caveden]

this could only occur if people are using totally disparate, non-overlapping UNLs which will not happen in practice due to defaults and universally trusted nodes.
...
people running clients who are not validators need not worry about it. they may use the default list of UNLs.

Also, it is all about UNL overlap.

So, people are expected to trust a set of "default validators". Everybody.

Don't you believe that gives too much power to these validators? Okay, you may argue they could be in different jurisdictions, some of them could be anonymous entities on a darknet etc, but still.

Not to mention this "default list". I'm supposing it'd be attached to the client. What a power it gives to these clients editors...

regardless of that childlike campaign, the simple fact remains: the bigger the block the longer the transmission time. we are essentially relying on Moore's Law here in network capacity which does not apply across the board in computing. still, there are other issues described above.

Have you ever read this? https://en.bitcoin.it/wiki/Scalability
Mike Hearn has already made lots of good posts on this subject too, as well as Gavin. Search for their posts if you're interested.