<p>How would such an attack work? Presumably, there would have to be a first consensus that agreed on one transaction and then a later consensus that agrees on the other transaction. Otherwise, nobody would rely on the first transaction having been accepted and there would be no attack.</p>

<p>But what do they do about that first consensus? If they participate in it, they've now validated <em>both</em> transactions. Everyone would have absolute proof they were liars, so nobody would care that they validated the second one.</p>

<p>If they don't participate in it, then everyone would have absolute proof that they validated a transaction that conflicted with a transaction that was previously accepted. Again, everyone would have absolute proof they were liars.</p>

<p>Maybe you're thinking they might try to go back and claim that the first consensus actually went down a different way than it actually went down, presenting a conflicting view of the past. The problem is, information about the past is not established by looking at what consensus we had in the past. Information about the past is established by looking at the present consensus and walking hash chains to see what happened in the past. Lying about the past won't help you change the consensus about where everyone is now.</p>

<p>Essentially, consensus is only used to establish an ordering of transactions via a series of checkpoints. There's no way to say "move that transaction back so that it occurred in the past". Once validated, the past is immutable.</p>

<p>What you could do with an attack like this is prevent the network from reaching consensus. However, you'd have to do it by behaving clearly irrationally, announcing positions that don't make progress towards a consensus. As soon as people discovered you doing this, they'd stop letting you participate in the consensus process and you'd have to build trust all over again.</p>

CC BY-SA 3.0
2013-02-15T00:46:21.927Z
2013-02-15T08:56:17.687Z
2013-02-15T08:56:17.687Z
David Schwartz
<p>A key point in Ripple is that the consensus doesn't take everyone's opinions into account. Each user has a list of trusted nodes. It will not do much good for an attacker to create multiple anonymous, untrusted sockpuppet accounts.</p>

CC BY-SA 3.0
2013-02-14T12:27:51.177Z
2013-02-14T12:27:51.177Z
Meni Rosenfeld
<p>I'm under the impression that Ripple uses a consensus based system in order to determine which of two payments is the authoritative one, with the other getting rejected due to a lack of proponents. This form of decision making appears to be prone to a sock-puppet attack.</p>

<p>Would it be possible for someone to create a high value spend in one store and then negate it through a carefully timed sock-puppet attack such that the original   spend is outvoted by a lesser value payment that has vastly more (fake) backing? </p>

<p>In short, how are resources consumed during the consensus process?</p>

<security><ripple><consensus>
How does Ripple solve the sock-puppet problem during consensus?
Gary
# How does Ripple solve the sock-puppet problem during consensus?

(Asked by: username_0 on 2013-02-14)

I'm under the impression that Ripple uses a consensus based system in order to determine which of two payments is the authoritative one, with the other getting rejected due to a lack of proponents. This form of decision making appears to be prone to a sock-puppet attack.

Would it be possible for someone to create a high value spend in one store and then negate it through a carefully timed sock-puppet attack such that the original spend is outvoted by a lesser value payment that has vastly more (fake) backing?

In short, how are resources consumed during the consensus process?

**Tags:** security, ripple, consensus


---

## 2 answers

### Answer by username_1 on 2013-02-15. Score: 2 | Accepted answer

How would such an attack work? Presumably, there would have to be a first consensus that agreed on one transaction and then a later consensus that agrees on the other transaction. Otherwise, nobody would rely on the first transaction having been accepted and there would be no attack.

But what do they do about that first consensus? If they participate in it, they've now validated *both* transactions. Everyone would have absolute proof they were liars, so nobody would care that they validated the second one.

If they don't participate in it, then everyone would have absolute proof that they validated a transaction that conflicted with a transaction that was previously accepted. Again, everyone would have absolute proof they were liars.

Maybe you're thinking they might try to go back and claim that the first consensus actually went down a different way than it actually went down, presenting a conflicting view of the past. The problem is, information about the past is not established by looking at what consensus we had in the past. Information about the past is established by looking at the present consensus and walking hash chains to see what happened in the past. Lying about the past won't help you change the consensus about where everyone is now.

Essentially, consensus is only used to establish an ordering of transactions via a series of checkpoints. There's no way to say "move that transaction back so that it occurred in the past". Once validated, the past is immutable.

What you could do with an attack like this is prevent the network from reaching consensus. However, you'd have to do it by behaving clearly irrationally, announcing positions that don't make progress towards a consensus. As soon as people discovered you doing this, they'd stop letting you participate in the consensus process and you'd have to build trust all over again.


---

### Answer by username_2 on 2013-02-14. Score: 3

A key point in Ripple is that the consensus doesn't take everyone's opinions into account. Each user has a list of trusted nodes. It will not do much good for an attacker to create multiple anonymous, untrusted sockpuppet accounts.


---

