<p>Ripple should be immune to this attack because a transaction is not considered validated until an overwhelming majority of validators (that you care about) have signed a receipt saying that they have processed it (by validating a ledger that includes it either in that ledger or in one of its prior ledgers). If the network had split, you could not receive receipts from an overwhelming majority of validators.</p>

<p>Ripple servers have an internal "gate". They continue to track the network, try to reach a consensus, sign validations, and so on. But they don't report transactions as confirmed to clients until they pass this internal gate. To pass the gate, a ledger must have sufficient validations from trusted sources. Once a ledger meets that threshold, the gate is advanced to just past that ledger and everything up to that new point is considered fully validated.</p>

<p>Anything after the gate is in flux, subject to consensus with other validators. Everything behind the gate is forever committed. The overwhelming majority of validators have committed to it.</p>

<p>If you are on the minority side of a split (or even the slight majority side of a bad split), no transactions will pass the gate. The network will be unusable, but nobody will rely on a transaction that gets undone when a split is resolved.</p>

<p>In exchange for immunity to this attack and in exchange for Ripple's fast confirmations with no proof of work needed, a price is paid. One can imagine situations where transactions might fail to pass the gate even though there's no network split. For example, if a large number of validators suddenly stop validating all at the same time, you might think you're split off from them, and manual intervention might be needed to permit any transactions to pass the gate.</p>

CC BY-SA 3.0
2013-11-12T18:06:39.520Z
But since it's very easy to become a node (just need an IP and a computer), wouldn't a large entity with enough interest be willing to make these sort of attacks by disguising themselves as honest for a while (to gain trust) and then attack with these sort of double-spends? Again, all it takes is IPs, not proof-of-works.
Luca Matteis
CC BY-SA 3.0
2013-11-12T20:41:34.890Z
@LucaMatteis No, for two reasons. First, IPs are not enough. You have to actually get people to trust you and collusion is the one thing they are selecting trusted endpoints to avoid. Second, you can't double spend. You can only break consensus. Once the gate moves, everything behind it is forever committed. All you can do is keep the gate from moving.
David Schwartz
CC BY-SA 3.0
2013-11-12T20:58:13.377Z
If you're the majority, what does it matter? You can control the ledger and double spend all you want. The client you're double-spending against will notice because their transaction will disappear. But for the rest of the network, your nodes are as trustworthy as before. Also, with Ripple, you must assume past good behavior implies future good behavior, which is an unreliable assumption.
Luca Matteis
CC BY-SA 3.0
2013-11-12T21:22:53.830Z
@LucaMatteis You can't double spend. You can't change anything before the gate and until a transaction is behind the gate, nobody will rely on its results. I'm not sure what you mean by "client you're double-spending against". (And in any event, every known monetary system requires that assumption. How do you know a Democracy won't change the laws in a way that destroys any value you hold?)
David Schwartz
CC BY-SA 3.0
2013-11-12T23:15:02.547Z
Who owns this gate? You're saying that all the transactions need to be approved by this central gate to achieve consensus?
Luca Matteis
CC BY-SA 3.0
2013-11-12T23:21:12.100Z
@LucaMatteis Every server has its own gate. Read the second paragraph of my answer.
David Schwartz
CC BY-SA 3.0
2013-11-12T23:36:35.310Z
But my point is: what if the majority of the servers are dishonest? Then they could do bad things right?
Luca Matteis
CC BY-SA 3.0
2013-11-12T23:40:16.843Z
@LucaMatteis To themselves, sure. But who cares if dishonest people do bad things to themselves? For anyone else, the bad guys can't make their gate go backwards, so there's no double spend. They can, however, keep the gate from advancing. So there's a DoS attack possible.
David Schwartz
CC BY-SA 3.0
2013-11-13T00:04:26.413Z
But couldn't the dishonest behave honestly and so others would think they are just like other regular honest servers. But behind the scenes they would do bad things specifically to some individuals (like invalidating some transactions or something else). Would this be possible?
Luca Matteis
CC BY-SA 3.0
2013-11-13T00:20:06.093Z
@LucaMatteis No. Proposals and validations are always signed and flooded. You couldn't get away with sending two different versions. Servers move their gate based on a supermajority, and you can't create two different supermajorities. (You can create none if you control enough trust but then you'll rapidly lose that trust.)
David Schwartz
CC BY-SA 3.0
2013-04-26T09:25:24.447Z
2013-04-26T09:31:10.877Z
2013-04-26T09:31:10.877Z
David Schwartz
<p>From the spec (emphasis added):</p>

<blockquote>
  <p>Under a net split, a ledger may be closed by the minority of network, <strong>this ledger may be discarded in the future</strong>.</p>
</blockquote>

<p>Does this mean it would be possible to spend twice, once on each side of the split?</p>

<p>Even if the transaction is merely rejected later, you could trick a merchant into accepting your payment, then take delivery, and then let the network reject the transaction once the split is resolved. Is this correct? How would the minority of the nodes know that they're separated from the rest of the network?</p>

<transactions><ripple><doublespend>
Is it possible to execute a double-spending attack in Ripple during a network split?
Manish
# Is it possible to execute a double-spending attack in Ripple during a network split?

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

From the spec (emphasis added):

> Under a net split, a ledger may be closed by the minority of network, **this ledger may be discarded in the future**.

Does this mean it would be possible to spend twice, once on each side of the split?

Even if the transaction is merely rejected later, you could trick a merchant into accepting your payment, then take delivery, and then let the network reject the transaction once the split is resolved. Is this correct? How would the minority of the nodes know that they're separated from the rest of the network?

**Tags:** transactions, ripple, doublespend


---

## 1 answers

### Answer by username_1 on 2013-04-26. Score: 3 | Accepted answer

Ripple should be immune to this attack because a transaction is not considered validated until an overwhelming majority of validators (that you care about) have signed a receipt saying that they have processed it (by validating a ledger that includes it either in that ledger or in one of its prior ledgers). If the network had split, you could not receive receipts from an overwhelming majority of validators.

Ripple servers have an internal "gate". They continue to track the network, try to reach a consensus, sign validations, and so on. But they don't report transactions as confirmed to clients until they pass this internal gate. To pass the gate, a ledger must have sufficient validations from trusted sources. Once a ledger meets that threshold, the gate is advanced to just past that ledger and everything up to that new point is considered fully validated.

Anything after the gate is in flux, subject to consensus with other validators. Everything behind the gate is forever committed. The overwhelming majority of validators have committed to it.

If you are on the minority side of a split (or even the slight majority side of a bad split), no transactions will pass the gate. The network will be unusable, but nobody will rely on a transaction that gets undone when a split is resolved.

In exchange for immunity to this attack and in exchange for Ripple's fast confirmations with no proof of work needed, a price is paid. One can imagine situations where transactions might fail to pass the gate even though there's no network split. For example, if a large number of validators suddenly stop validating all at the same time, you might think you're split off from them, and manual intervention might be needed to permit any transactions to pass the gate.

> **Comments:**
> **username_2**: But since it's very easy to become a node (just need an IP and a computer), wouldn't a large entity with enough interest be willing to make these sort of attacks by disguising themselves as honest for a while (to gain trust) and then attack with these sort of double-spends? Again, all it takes is IPs, not proof-of-works.  
> **username_1**: @username_2 No, for two reasons. First, IPs are not enough. You have to actually get people to trust you and collusion is the one thing they are selecting trusted endpoints to avoid. Second, you can't double spend. You can only break consensus. Once the gate moves, everything behind it is forever committed. All you can do is keep the gate from moving.  
> **username_2**: If you're the majority, what does it matter? You can control the ledger and double spend all you want. The client you're double-spending against will notice because their transaction will disappear. But for the rest of the network, your nodes are as trustworthy as before. Also, with Ripple, you must assume past good behavior implies future good behavior, which is an unreliable assumption.  
> **username_1**: @username_2 You can't double spend. You can't change anything before the gate and until a transaction is behind the gate, nobody will rely on its results. I'm not sure what you mean by "client you're double-spending against". (And in any event, every known monetary system requires that assumption. How do you know a Democracy won't change the laws in a way that destroys any value you hold?)  
> **username_2**: Who owns this gate? You're saying that all the transactions need to be approved by this central gate to achieve consensus?  
> **username_1**: @username_2 Every server has its own gate. Read the second paragraph of my answer.  
> **username_2**: But my point is: what if the majority of the servers are dishonest? Then they could do bad things right?  
> **username_1**: @username_2 To themselves, sure. But who cares if dishonest people do bad things to themselves? For anyone else, the bad guys can't make their gate go backwards, so there's no double spend. They can, however, keep the gate from advancing. So there's a DoS attack possible.  
> **username_2**: But couldn't the dishonest behave honestly and so others would think they are just like other regular honest servers. But behind the scenes they would do bad things specifically to some individuals (like invalidating some transactions or something else). Would this be possible?  
> **username_1**: @username_2 No. Proposals and validations are always signed and flooded. You couldn't get away with sending two different versions. Servers move their gate based on a supermajority, and you can't create two different supermajorities. (You can create none if you control enough trust but then you'll rapidly lose that trust.)  

---

