<blockquote>
  <p>By contrast, if someone acquired ASICs to attack Bitcoin, they could attack Bitcoin repeatedly.</p>
</blockquote>

<p>The problem is, there isn't enough ASICs available on Earth to mount an effective attack on Bitcoin. Existing miners would need to be co-opted as part of the attack, which effectively becomes a fork: a new chain splits off with different rules. Which is what happened with the bcash fiasco. The old chain continues unaffected, while the new one dwindles as miners eventually capitulate and return to the more profitable consensus chain.</p>

CC BY-SA 4.0
2018-12-07T18:43:34.913Z
2018-12-07T18:43:34.913Z
Brix
<p>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.</p>

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

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

<p>In this case, servers would declare the Ripple network unusable automatically. Until the problem was resolved, no transaction results could be relied upon.</p>

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

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

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

CC BY-SA 3.0
2013-04-25T10:32:45.810Z
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
CC BY-SA 3.0
2013-04-25T10:40:36.193Z
A blockchain fork :)
eMansipater
CC BY-SA 3.0
2013-04-25T14:47:21.677Z
"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
CC BY-SA 3.0
2013-04-25T14:50:22.997Z
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
CC BY-SA 3.0
2013-04-25T15:30:17.347Z
@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
CC BY-SA 3.0
2013-04-25T15:31:39.977Z
@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
CC BY-SA 3.0
2013-04-25T16:12:12.203Z
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
CC BY-SA 3.0
2013-04-25T16:48:53.983Z
@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
CC BY-SA 3.0
2013-04-25T06:23:29.400Z
2013-04-25T15:29:00.233Z
2013-04-25T15:29:00.233Z
David Schwartz
<p>In Bitcoin, if a participant gains control of more than 50% of the hash power, they can execute a double-spending attack. The "attack" could come from within, say if the existing powerful miners decide to change the rules.</p>

<p>Does Ripple have a similar problem, where a few people can effectively take control of the system? If yes, how does it work?</p>

<ripple><doublespend><attack><majority-attack><decentralization>
What is the Ripple equivalent of the "51% attack?"
Manish
# What is the Ripple equivalent of the "51% attack?"

(Asked by: username_0 on 2013-04-24)

In Bitcoin, if a participant gains control of more than 50% of the hash power, they can execute a double-spending attack. The "attack" could come from within, say if the existing powerful miners decide to change the rules.

Does Ripple have a similar problem, where a few people can effectively take control of the system? If yes, how does it work?

**Tags:** ripple, doublespend, attack, majority-attack, decentralization


---

## 2 answers

### Answer by username_2 on 2013-04-25. Score: 11 | Accepted answer

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.

> **Comments:**
> **username_3**: 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?  
> **username_4**: A blockchain fork :)  
> **username_0**: "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?  
> **username_0**: 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)?  
> **username_2**: @username_3: 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.  
> **username_2**: @username_0: 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.  
> **username_0**: 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?  
> **username_2**: @username_0: 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.)  

---

### Answer by username_1 on 2018-12-07. Score: 0

> By contrast, if someone acquired ASICs to attack Bitcoin, they could attack Bitcoin repeatedly.

The problem is, there isn't enough ASICs available on Earth to mount an effective attack on Bitcoin. Existing miners would need to be co-opted as part of the attack, which effectively becomes a fork: a new chain splits off with different rules. Which is what happened with the bcash fiasco. The old chain continues unaffected, while the new one dwindles as miners eventually capitulate and return to the more profitable consensus chain.


---

