Ripple solves the double spend problem by consensus. Everyone who wants to run a server on the Ripple network picks a set of validators and tries to reach a consensus with them on which transactions are valid.
The Ripple equivalent of Bitcoin's 51% attack would be if some group obtained control over enough validators that the consensus process failed. Because people specifically select validators that they believe are unlikely to collude, this would be an exceptionally difficult thing to do.
If validators refuse to come to a consensus with each other, this is detectable to other validators. They then pronounce the network broken (because they don't know which side is right).
In this case, servers would declare the Ripple network unusable automatically. Until the problem was resolved, no transaction results could be relied upon.
The solution would consist of analyzing the signed validations and proposals to see which validators were being unreasonable and for all honest people to remove those validators from the UNLs (lists of validators they try to come to a consensus with).
So you would have to gain people's trust and then in the process of making the attack you would lose that trust and have to start over again.
By contrast, if someone acquired ASICs to attack Bitcoin, they could attack Bitcoin repeatedly. It's not clear how Bitcoin could respond to such an attack, but changing the mining algorithm (to make the attacker's ASICs worthless) is probably a non-starter as it would also make all the Bitcoin miners' investments in ASICs worthless as well.
How does the network makes sure that no clusters of validators arise? If I'm right, nodes ignore proposals from other nodes than the ones they trust. What happens when a cluster of nodes arises only trusting the others in the cluster but having no link with any other node outside the cluster? – Steven Roose – 2013-04-25T10:32:45.810
A blockchain fork :) – eMansipater – 2013-04-25T10:40:36.193
"Until the problem was resolved, no transaction results could be relied upon." Does this mean transactions wouldn't go through? Would a user know that the system is in this state? – Manish – 2013-04-25T14:47:21.677
In Bitcoin you can do a double-spend if you have enough hash power, and this is by design. Are you saying that you simply can't double-spend in Ripple, only just bring the system to a halt owing to lack of consensus (even if you controlled most of the validating nodes)? – Manish – 2013-04-25T14:50:22.997
@StevenRoose: There's nothing wrong with a cluster of validators, they'd just form their own network. If you want to maintain consistency with the global network of validators and you want to be on the same ledger as them, you have to tell the software that's what you want. – David Schwartz – 2013-04-25T15:30:17.347
@Manish: Yes, that's basically right if UNLs are properly maintained. But think about it -- say you get in that state and you now have two halves of the network that disagree. The network has come to a halt and the only way to fix it is to pick one side or the other. The advantage is that you shouldn't have people who have relied on one side or the other's transactions. – David Schwartz – 2013-04-25T15:31:39.977
Is this "halt" state something that every node knows about? Or is it like Bitcoin where you could happily keep building on an alternative branch forever (and end up with two ledgers)? What does "halt" mean, does it mean no more transactions? – Manish – 2013-04-25T16:12:12.203
2@Manish: The Ripple server has an internal "gate". It continues running based on what it sees on the network, forming a consensus with anything it can. But it only reports transactions as validated to clients when they pass this "gate". If the validators are not agreeing, then nothing will pass the gate. The server will report stale data to the clients and tell them it does not have current data. You could not rely on the results of any transactions. If Bitcoin has a similar failed state, it still happily processes transactions and reports confirmations. (Though that's very rare.) – David Schwartz – 2013-04-25T16:48:53.983