Topic: How does Ripple consensus deal with forks? (Read 1648 times)

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


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.

Also, it is all about UNL overlap.

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

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

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.

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.

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.


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


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


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


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


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

since everything is signed you know generally who the other validators are and can prevent splits/merge them.
ordinary users would not have to know what a validator is

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.

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

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

https://bitcointalksearch.org/topic/new-video-why-the-blocksize-limit-keeps-bitcoin-free-and-decentralized-208200

see above.


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.  

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.


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.


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)


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?


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


That's false and FUD.


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?


Bitcoin is neither.

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)

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.

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

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://bitcointalksearch.org/topic/ann-ripple-203877.

Bump.


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.

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.

bump

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.

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.

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

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  )