<p>@David's answer essentially doesn't talk about an attack scenario where the room is full of dishonest nodes. This is essentially what the proof-of-work was designed to fix.</p>

<p>If you get a hold of a lot of IPs (nodes in the Ripple network) you could become a majority in the room. The difference is that it's really easy to get an IP, but extremely hard to prove you work in a proof-of-work system (like Bitcoin's).</p>

<p>For my understanding, Ripple doesn't solve the double-spending problem mathematically, as Bitcoin does (assuming honest nodes are overpowering the network). It solves it using a distributed consensus system that can easily be overthrown if you can obtain the majority of the IPs and you act honestly for a while, making other nodes trust you.</p>

<p>In conclusion double-spending is possible with both Bitcoin and Ripple, but with Bitcoin it's much harder to double-spend because the system is based on a mathematical race against the proof-of-work system, whilst Ripple relies on consensus of a number of nodes that can be more easily reproduced by an attacker.</p>

CC BY-SA 3.0
2013-11-12T18:28:19.157Z
reason why i'm being downvoted?
Luca Matteis
CC BY-SA 3.0
2013-11-13T00:52:54.123Z
IPs and nodes have nothing to do with anything. The algorithm doesn't care how many IPs or nodes you have or don't have. It's based on public keys that human beings have chosen to extend very small amounts of trust to. As for "it's really easy to get an IP, but extremely hard to prove you work in a proof-of-work system", that's basically false. They both take money. What's hard to do is convince other human beings that lots of keys have totally independent ownership when they actually don't.
David Schwartz
CC BY-SA 3.0
2013-11-13T09:47:28.743Z
Sorry but it's still not clear to me. The Ripple system requires trust to certain amount of nodes, right? How easily can trust be faked by a single entity, simply creating a variety of different nodes in the system (sybil attack). Essentially, what if the room is full of dishonest people, and how easy would it be to do this?
Luca Matteis
CC BY-SA 3.0
2013-11-13T09:55:47.167Z
This forum isn't really suitable to conversation. If you like, you can post to the Bitcoin forums or the Ripple forums. A single entity can create as many nodes as they want, but they have to actually convince people that the nodes are independent for them to count. Human beings make the decision of which keys to count based on their conviction that the keys are independently administered. There's a discussion of this issue [here](https://ripple.com/forum/viewtopic.php?f=1&t=3881&p=19414).
David Schwartz
CC BY-SA 3.0
2013-11-13T13:03:33.470Z
Ok. But simply: why doesn't Bitcoin then use this sort of system if it prevents double-spending without all the electricity waste of mining?
Luca Matteis
CC BY-SA 3.0
2013-11-13T13:23:22.060Z
For one thing, this system wasn't known until two years after Bitcoin was made public. [Jed McCaleb proposed it as a response to what he perceived as mining's inefficiency.](https://bitcointalk.org/index.php?topic=10193.0)
David Schwartz
CC BY-SA 3.0
2013-11-13T14:03:38.187Z
Do you know of an alt-coin that uses this trust model instead of proof-of-work. I know Ripple is one of course, but I dislike the very corporate nature of it. I'll keep an eye on the "trust" topic as it's very interesting. Also my point was raised by other several members on that topic as well (https://bitcointalk.org/index.php?topic=10193.msg146301#msg146301) so I'm not completely out of the line here.
Luca Matteis
CC BY-SA 3.0
2014-07-25T08:49:28.810Z
@LucaMatteis Ripple is based on openness and trust unlike bitcoin. You chose specifically which nodes you want to trust unlike bitcoin. This will be individuals, business etc who can prove who they are. Nobody is going to trust some random unknown bunch of nodes. A ripple node isn't an IP but more like a public key. So my impression is that this is more like how security works in PGP. In PGP you typically verify the identity of someone physically or through signatures by people you already trust.
Erik Engheim
CC BY-SA 3.0
2013-11-12T18:17:35.220Z
2013-11-12T18:17:35.220Z
Luca Matteis
<p>The details are very complex, but the core concept is fairly simple. Ripple solves the double-spend problem by consensus.</p>

<p>The analogy I use is an "agreement room". To walk into the room, you have to agree with everyone who is already in there. If you want to disagree, you have to leave and form your own room. Everyone who is honest wants to get into the biggest room they can with the most people in it.</p>

<p>In the room, people constantly agree on the current state of the system. It's implemented as a hash tree, so that's just one 256-bit number.</p>

<p>To perform a transaction, you walk into the big room and read out the transaction. Everyone checks the transaction against their ledger. Assuming there's no conflicting transaction or other problem, everyone agrees that the transaction is valid and they include it in the set of transactions they believe should be applied.</p>

<p>They then work on any disagreements they have by an avalanche process. Essentially, if someone is voting yes on a transaction that doesn't have overwhelming majority support, they just change their vote to no. This ensures there's a quick agreement on a set of transactions.</p>

<p>Once a set of candidate transactions is agreed upon, those transaction are applied and everyone computes the next ledger according to a set of deterministic rules. They all sign it, publish those signatures, and now clients know which transactions have been accepted by the consensus process.</p>

<p>If a transaction doesn't get in for some reason, but it's still valid, every honest person in the room will say yes to that transaction in the next round.</p>

<p>So, back to the double spend problem. A double spend is essentially two transactions, each of which is valid if and only if it's applied before the other. Thus solving the double spend problem "merely" requires agreeing on an order for the two transactions. If everyone agrees which comes first, the problem is solved -- the one that comes first is applied and thus the other is invalid.</p>

<p>In the Ripple system, if two transactions are a double spend, one of three things can happen:</p>

<ol>
<li><p>One transaction will get voted into a consensus set before the other. In this case, that transaction will be in a ledger signed by all the people in the room, forever invalidating the other.</p></li>
<li><p>Both get into the same consensus set (this should almost never happen). In this case, a deterministic rule when the consensus set is applied determines which gets into the ledger, forever blocking the other.</p></li>
<li><p>Neither gets into a consensus set because neither gets a majority and both transactions are at around 50%. In this case, every node that sees both transactions (which will quickly be the vast majority of nodes) will vote yes on the transaction that wins by a deterministic rule and no on the transaction that loses by that rule. The one that wins by that deterministic rule will get in the consensus set, be applied to the ledger, and forever block the other.</p></li>
</ol>

<p>That's a gross oversimplification, but it's inherently fairly complex.</p>

CC BY-SA 3.0
2013-02-12T01:47:48.197Z
How is this different from Bitcoin, if it is different?
Colin Dean
CC BY-SA 3.0
2013-02-12T01:49:44.123Z
@ColinDean: Bitcoin uses [proof of work](https://en.bitcoin.it/wiki/How_bitcoin_works#Double_spending). The methods are completely different.
David Schwartz
CC BY-SA 3.0
2013-04-12T07:10:10.497Z
Is there any 'cost' to having a vote?  Does each node on the network represent one vote?  If there is not a high cost, is there a risk that an attacker can spam nodes on the network to get more votes?  Thanks for the detailed writeup.
Brian Armstrong
CC BY-SA 3.0
2013-04-12T07:54:03.317Z
@BrianArmstrong: There is no cost to having a vote. Each server operator chooses who they want to give votes to. See [UNL](https://ripple.com/wiki/Unique_Node_List) in the Ripple wiki. (Sorry, that entry is a bit out of date, but the concept is correct.)
David Schwartz
CC BY-SA 3.0
2013-04-24T20:49:56.910Z
What is the deterministic rule here?
Manish
CC BY-SA 3.0
2013-04-24T20:55:07.113Z
@Manish: It's actually fairly complicated, but if there are no other complicating factors (such as prior transactions that have to get in before one of the conflicting transactions can or the transactions produce a suboptimal result on their first application), then the one with the lowest transaction ID will get in.
David Schwartz
CC BY-SA 3.0
2014-01-11T22:08:24.007Z
@DavidSchwartz So Ripple nodes also keep a history of all transactions? Btw, in Bitcoin PoW does not solve double-spending. The block chain does. PoW is just a way of securing the block chain from unfair parties.
Steven Roose
CC BY-SA 3.0
2014-01-13T17:16:42.430Z
@StevenRoose Ripple nodes don't need to keep a history of all transactions. They can keep as much or as little history as they like -- it's just needed to provide historical data to clients.
David Schwartz
CC BY-SA 3.0
2014-01-14T15:49:06.883Z
But how can a node vote against a double-spend without keeping a history?
Steven Roose
CC BY-SA 3.0
2014-01-14T22:37:33.663Z
@StevenRoose Ripple has accounts with balances. If I send you $10, that's a double spend if I don't have $10 but it's not a double spend if I have (another) $10. So what you need to prevent a double spend is the current balance, not historical transactions.
David Schwartz
CC BY-SA 3.0
2014-01-15T15:07:16.143Z
Wow, that sounds weird. Maybe I get the concept of making transactions in Ripple wrong. Is it like with Bitcoin, broadcasting a transaction to all nodes? Because if it is, what prevents the receiver of $10 from rebroadcasting that transaction (f.e. when your balance is $50)?
Steven Roose
CC BY-SA 3.0
2014-01-15T17:48:04.920Z
@StevenRoose Every account also has a sequence number. For a transaction to be legal, the sequence number in the transaction must equal the sequence number in the account that performed the transaction. As part of performing the transaction, the account's sequence number is incremented, forever preventing that transaction from being applied again. So, again, you only need the current state of the account and no historical transactions.
David Schwartz
CC BY-SA 3.0
2014-01-15T18:57:00.810Z
The sequence number is neat. Thanks for clearing out. I think it's hard to find good references of the technical workings of Ripple. I used to learn everything about Bitcoin from the paper and the wiki, but last time I checked the Ripple wiki, it was kind of empty and didn't contain technical information.
You guys at O̶p̶e̶n̶C̶o̶i̶n̶ RippleLabs should do a better job with that if you want the community to embrace Ripple!
Steven Roose
CC BY-SA 3.0
2013-02-11T14:39:26.867Z
2013-02-13T03:04:41.073Z
2013-02-13T03:04:41.073Z
David Schwartz
<p>How does <a href="https://ripple.com/">the Ripple system</a> solve the double-spend problem? Does it also use some block-chain-like entity that officially dictates which transactions are confirmed and which are not, or does it use some other clever mechanism?</p>

<protocol><ripple><doublespend><architecture>
How does Ripple solve the double-spend problem?
ThePiachu
# How does Ripple solve the double-spend problem?

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

How does [the Ripple system](https://ripple.com/) solve the double-spend problem? Does it also use some block-chain-like entity that officially dictates which transactions are confirmed and which are not, or does it use some other clever mechanism?

**Tags:** protocol, ripple, doublespend, architecture


---

## 2 answers

### Answer by username_2 on 2013-02-11. Score: 33 | Accepted answer

The details are very complex, but the core concept is fairly simple. Ripple solves the double-spend problem by consensus.

The analogy I use is an "agreement room". To walk into the room, you have to agree with everyone who is already in there. If you want to disagree, you have to leave and form your own room. Everyone who is honest wants to get into the biggest room they can with the most people in it.

In the room, people constantly agree on the current state of the system. It's implemented as a hash tree, so that's just one 256-bit number.

To perform a transaction, you walk into the big room and read out the transaction. Everyone checks the transaction against their ledger. Assuming there's no conflicting transaction or other problem, everyone agrees that the transaction is valid and they include it in the set of transactions they believe should be applied.

They then work on any disagreements they have by an avalanche process. Essentially, if someone is voting yes on a transaction that doesn't have overwhelming majority support, they just change their vote to no. This ensures there's a quick agreement on a set of transactions.

Once a set of candidate transactions is agreed upon, those transaction are applied and everyone computes the next ledger according to a set of deterministic rules. They all sign it, publish those signatures, and now clients know which transactions have been accepted by the consensus process.

If a transaction doesn't get in for some reason, but it's still valid, every honest person in the room will say yes to that transaction in the next round.

So, back to the double spend problem. A double spend is essentially two transactions, each of which is valid if and only if it's applied before the other. Thus solving the double spend problem "merely" requires agreeing on an order for the two transactions. If everyone agrees which comes first, the problem is solved -- the one that comes first is applied and thus the other is invalid.

In the Ripple system, if two transactions are a double spend, one of three things can happen:

1. One transaction will get voted into a consensus set before the other. In this case, that transaction will be in a ledger signed by all the people in the room, forever invalidating the other.
2. Both get into the same consensus set (this should almost never happen). In this case, a deterministic rule when the consensus set is applied determines which gets into the ledger, forever blocking the other.
3. Neither gets into a consensus set because neither gets a majority and both transactions are at around 50%. In this case, every node that sees both transactions (which will quickly be the vast majority of nodes) will vote yes on the transaction that wins by a deterministic rule and no on the transaction that loses by that rule. The one that wins by that deterministic rule will get in the consensus set, be applied to the ledger, and forever block the other.

That's a gross oversimplification, but it's inherently fairly complex.

> **Comments:**
> **username_4**: How is this different from Bitcoin, if it is different?  
> **username_2**: @username_4: Bitcoin uses [proof of work](https://en.bitcoin.it/wiki/How_bitcoin_works#Double_spending). The methods are completely different.  
> **username_5**: Is there any 'cost' to having a vote?  Does each node on the network represent one vote?  If there is not a high cost, is there a risk that an attacker can spam nodes on the network to get more votes?  Thanks for the detailed writeup.  
> **username_2**: @username_5: There is no cost to having a vote. Each server operator chooses who they want to give votes to. See [UNL](https://ripple.com/wiki/Unique_Node_List) in the Ripple wiki. (Sorry, that entry is a bit out of date, but the concept is correct.)  
> **username_6**: What is the deterministic rule here?  
> **username_2**: @username_6: It's actually fairly complicated, but if there are no other complicating factors (such as prior transactions that have to get in before one of the conflicting transactions can or the transactions produce a suboptimal result on their first application), then the one with the lowest transaction ID will get in.  
> **username_7**: @username_2 So Ripple nodes also keep a history of all transactions? Btw, in Bitcoin PoW does not solve double-spending. The block chain does. PoW is just a way of securing the block chain from unfair parties.  
> **username_2**: @username_7 Ripple nodes don't need to keep a history of all transactions. They can keep as much or as little history as they like -- it's just needed to provide historical data to clients.  
> **username_7**: But how can a node vote against a double-spend without keeping a history?  
> **username_2**: @username_7 Ripple has accounts with balances. If I send you $10, that's a double spend if I don't have $10 but it's not a double spend if I have (another) $10. So what you need to prevent a double spend is the current balance, not historical transactions.  
> **username_7**: Wow, that sounds weird. Maybe I get the concept of making transactions in Ripple wrong. Is it like with Bitcoin, broadcasting a transaction to all nodes? Because if it is, what prevents the receiver of $10 from rebroadcasting that transaction (f.e. when your balance is $50)?  
> **username_2**: @username_7 Every account also has a sequence number. For a transaction to be legal, the sequence number in the transaction must equal the sequence number in the account that performed the transaction. As part of performing the transaction, the account's sequence number is incremented, forever preventing that transaction from being applied again. So, again, you only need the current state of the account and no historical transactions.  
> **username_7**: The sequence number is neat. Thanks for clearing out. I think it's hard to find good references of the technical workings of Ripple. I used to learn everything about Bitcoin from the paper and the wiki, but last time I checked the Ripple wiki, it was kind of empty and didn't contain technical information. You guys at O̶p̶e̶n̶C̶o̶i̶n̶ RippleLabs should do a better job with that if you want the community to embrace Ripple!  

---

### Answer by username_1 on 2013-11-12. Score: 5

@username_2's answer essentially doesn't talk about an attack scenario where the room is full of dishonest nodes. This is essentially what the proof-of-work was designed to fix.

If you get a hold of a lot of IPs (nodes in the Ripple network) you could become a majority in the room. The difference is that it's really easy to get an IP, but extremely hard to prove you work in a proof-of-work system (like Bitcoin's).

For my understanding, Ripple doesn't solve the double-spending problem mathematically, as Bitcoin does (assuming honest nodes are overpowering the network). It solves it using a distributed consensus system that can easily be overthrown if you can obtain the majority of the IPs and you act honestly for a while, making other nodes trust you.

In conclusion double-spending is possible with both Bitcoin and Ripple, but with Bitcoin it's much harder to double-spend because the system is based on a mathematical race against the proof-of-work system, whilst Ripple relies on consensus of a number of nodes that can be more easily reproduced by an attacker.

> **Comments:**
> **username_1**: reason why i'm being downvoted?  
> **username_2**: IPs and nodes have nothing to do with anything. The algorithm doesn't care how many IPs or nodes you have or don't have. It's based on public keys that human beings have chosen to extend very small amounts of trust to. As for "it's really easy to get an IP, but extremely hard to prove you work in a proof-of-work system", that's basically false. They both take money. What's hard to do is convince other human beings that lots of keys have totally independent ownership when they actually don't.  
> **username_1**: Sorry but it's still not clear to me. The Ripple system requires trust to certain amount of nodes, right? How easily can trust be faked by a single entity, simply creating a variety of different nodes in the system (sybil attack). Essentially, what if the room is full of dishonest people, and how easy would it be to do this?  
> **username_2**: This forum isn't really suitable to conversation. If you like, you can post to the Bitcoin forums or the Ripple forums. A single entity can create as many nodes as they want, but they have to actually convince people that the nodes are independent for them to count. Human beings make the decision of which keys to count based on their conviction that the keys are independently administered. There's a discussion of this issue [here](https://ripple.com/forum/viewtopic.php?f=1&t=3881&p=19414).  
> **username_1**: Ok. But simply: why doesn't Bitcoin then use this sort of system if it prevents double-spending without all the electricity waste of mining?  
> **username_2**: For one thing, this system wasn't known until two years after Bitcoin was made public. [Jed McCaleb proposed it as a response to what he perceived as mining's inefficiency.](https://bitcointalk.org/index.php?topic=10193.0)  
> **username_1**: Do you know of an alt-coin that uses this trust model instead of proof-of-work. I know Ripple is one of course, but I dislike the very corporate nature of it. I'll keep an eye on the "trust" topic as it's very interesting. Also my point was raised by other several members on that topic as well (https://bitcointalk.org/index.php?topic=10193.msg146301#msg146301) so I'm not completely out of the line here.  
> **username_3**: @username_1 Ripple is based on openness and trust unlike bitcoin. You chose specifically which nodes you want to trust unlike bitcoin. This will be individuals, business etc who can prove who they are. Nobody is going to trust some random unknown bunch of nodes. A ripple node isn't an IP but more like a public key. So my impression is that this is more like how security works in PGP. In PGP you typically verify the identity of someone physically or through signatures by people you already trust.  

---

