WTF happened to ripple?

[jancsika]

Bitcoin uses the coinbase stuff to hand out the initial distribution.  Ripple XRP is handed out by a single corporation.  A single corporation in control of 80% of the currency is a textbook definition of central authority.

Of course. The design of Ripple doesn't require a central authority. But until it is decentralized, it will effectively have one.

It doesn't "effectively" have one-- it _has_ one.  And that means the implementation is, at present, effectively a centralized payment network (and I meant to write "effectively" there, and will explain if you truly don't understand the implications).  Additionally, the design-- where someone almost certainly said something like, "Hey, to bootstrap the currency why don't we _design_ it so that 80% of the currency goes to a corporation"-- is a design for a _future_ decentralized digital currency that relies on a centralized body to get it there.  If you're going to be honest you have to call it a centralized payment system with the potential to become decentralized.  That's one of the costs to designing it this way.

Furthermore, it is _highly_ relevant and reassuring to hear that Ripple is committed to getting rid of a current central point of failure.  On the other hand, it was more like a curiosity to read Satoshi saying he wished verification had gone to GPUs a little later than it did.  That's the difference between a centralized and decentralized approach to bootstrapping.

[jancsika]

Is there a mechanism to prevent netsplits?

Well, you can't really prevent them. But what you must do is detect them and not rely on any transactions if you are on the minority side of a split. You detect netsplits by waiting for validations before you rely on the contents of a newly-generated ledger. So if there's a net split and you are in the minority, you won't get validations from a significant fraction of your validators and thus won't consider any new ledgers fully validated.

Significant netsplits should be pretty rare because all it takes is one server that can connect to each side of the split and the split is healed. I suppose a natural disaster could cut off a country leaving only the clients and servers in that country talking to each other.

Now that I think about it, something like this could be easily added to Bitcoin. If the network hash rate seems to have drastically decreased, you should stop trusting transactions no matter how many confirmations they have. Does Bitcoin do anything about this? Does anyone think it's needed? (It's less of an issue with Bitcoin though. It would take a two-plus hour netsplit to fool you into thinking you have six confirmations if you're in the minority. Ripple aims for faster fully-confirmed transactions so has to detect even transient splits.)

Your last point about the faster transaction times is why I was asking.

We'll just have to see how servers build their UNLs in practice.  I cannot tell from the wiki how Sybil attacks are avoided.  It mentions that the connections can be untrusted as long as > 50% aren't cheating, so this isn't like Convergence or one of the f2f designs like Retroshare.

[JoelKatz]

I cannot tell from the wiki how Sybil attacks are avoided.

Someone who attempts a Sybil attack either has to give you what you need or not give you want you need. If they give you what they need, then they do no harm. If they stop giving you what you need, it's just like a netsplit. If they don't give you what you need, then you won't be able to operate.

Since all validations and proposals are signed and timestamped, they can't do a reply attack unless you don't have the correct time. And if they did that, all that would happen is that you would think payments weren't completed that actually were.

If necessary, Sybil attacks can be avoided in a more strong way with very slight changes. Connections use SSL internally and you can connect to specific servers trusted not to cut you off from the network.

[gmaxwell]

Is there a similar compact and fairly comprehensive expression of Ripple's security assumptions that could help people reason about the system?

At the highest level -- you are secure so long as the majority of your trust list doesn't conspire. If you have a bad trust list, you can be lied to about what transactions have been applied by the system.

What happens if the majority of each of _their_ (unknowable to me) trust lists conspire?

Something bad must happen, otherwise— My partner and I each run a valditator node make my client trust only those. I know they don't conspire against me. Now my client behind them is totally safe! ...  or not.

Think about it this way though -- if you have a 51% attack against Bitcoin, you have to make fundamental changes in Bitcoin. If you have a consensus breaking attack against Ripple, you have to remove the conspirators from your trust list.

See my example as to why I don't think its so simple. Shutting out a single high hashpower attacker isn't hard and lots of altcoins have done silly things to accomplish it.  But it's pointless because shutting out a single attacker is not useful if the fundamental assumption that a badguy won't have a computing majority is flawed. Likewise, removing conspiring nodes from your trust list is perhaps not all that useful if they were ever able to get there in the first place.

[JoelKatz]

Is there a similar compact and fairly comprehensive expression of Ripple's security assumptions that could help people reason about the system?

At the highest level -- you are secure so long as the majority of your trust list doesn't conspire. If you have a bad trust list, you can be lied to about what transactions have been applied by the system.

What happens if the majority of each of _their_ (unknowable to me) trust lists conspire?

Something bad must happen, otherwise— My partner and I each run a valditator node make my client trust only those. I know they don't conspire against me. Now my client behind them is totally safe! ...  or not.

You are, of course, completely right. I should be more precise. You are secure if the majority of the nodes on your trust list are secure. This ultimately devolves into the majority of the weight in your effective weighted trust not conspiring.

In your scenario, where you have trusted only two nodes and those two nodes trust conspiring nodes, you can't become convinced a transaction happened without them having that signed transaction to present. You can't rewrite the past. However, you could be duped into thinking a transaction was applied when it wasn't. You will have signed cryptographic proof that you were deceived. (Hopefully in the future, we'll automate collecting and distributing that proof so you only get to conspire once.)

Think about it this way though -- if you have a 51% attack against Bitcoin, you have to make fundamental changes in Bitcoin. If you have a consensus breaking attack against Ripple, you have to remove the conspirators from your trust list.

See my example as to why I don't think its so simple. Shutting out a single high hashpower attacker isn't hard and lots of altcoins have done silly things to accomplish it.  But it's pointless because shutting out a single attacker is not useful if the fundamental assumption that a badguy won't have a computing majority is flawed. Likewise, removing conspiring nodes from your trust list is perhaps not all that useful if they were ever able to get there in the first place.

I largely agree. It comes down to the practical question of which scheme will be more robust in the face of a motivated attacker. I don't think any of us really know that yet.

[gmaxwell]

I largely agree. It comes down to the practical question of which scheme will be more robust in the face of a motivated attacker. I don't think any of us really know that yet.

I can agree with that.

I'm still not sure that I've internalized the implications of your model in ripple, though I now think my initial understanding of the basic technicalities of were at least not totally incorrect.

I find it interesting that it's easy to describe topologies where you are insecure even though _all_ of your peers are honest and most of the network is honest:

Code:

                       /---- Honest0
                       /---  Attacker
         /------moron1 ----- Attacker
         /   /    |    \---- Attacker
         /   |    |    /---- Attacker
      you----|--moron2------ Attacker
         \   |    |    \---- Honest1
         \   \    |    /---- Honest2
         \------notmoron --- Honest3
 

In this graph there are 7 honest validators (honest*,moron*, and notmoron), and 5 attacker controlled identities. All of your direct peers are honest.  And yet you're exploited— Every validator you trustlist sees an attacker controlled majority even though only 41% of the total validators are dishonest.

So the Bitcoin security assumption (most hash power is honest) is not strong enough to make ripple secure if translated to comparable terms ('most trusted nodes in the system are honest').

How do your cryptographic signatures that show if someone misbehaved distinguish between them misbehaving vs trusting someone who misbehaved?  Couldn't I protect my reputation by attacking by simply arranging to trust dishonest sockpuppet nodes?  If I can't then isn't there considerable pressure to only trust the same nodes everyone else trusts?

[JoelKatz]

So the Bitcoin security assumption (most hash power is honest) is not strong enough to make ripple secure if translated to comparable terms ('most trusted nodes in the system are honest').

Your analysis is correct. In degenerate cases (small numbers of nodes, sparse trust) the topology works against you as much as the number of colluders. With larger numbers of nodes, the topology works in your favor -- the more nodes there are, the more conspiring nodes required. The cost to acquire a conspiring node may go down with the number of existing nodes, but not linearly.

How do your cryptographic signatures that show if someone misbehaved distinguish between them misbehaving vs trusting someone who misbehaved?

There is no distinction. If you mismanage your trust, you have failed. It is not so much a moral judgment but more a "this isn't working out" kind of thing.

Couldn't I protect my reputation by attacking by simply arranging to trust dishonest sockpuppet nodes?

That would cause you to validate the wrong things.

If I can't then isn't there considerable pressure to only trust the same nodes everyone else trusts?

Yes, exactly. So long as there is agreement, there is no issue. Every honest participant prioritizes agreement over everything but following the rules. (The bitcoin analogy would be that priority one is that blocks are valid. Priority two is that you pick the longest chain.)

The advantage of our scheme is that you get to choose who to trust. The disadvantage is that you have to choose who to trust.

[proff]

General comments that apply to any system:

1. Open source goes without saying, but people still need to read it. Real literate programming please, not just a description on the wiki. In fact a good literate-programming system will automatically generate web pages for you.

Actually, is the complete source even there?

2. Besides the source, papers proving that the system is immune to various directed attacks. Address concerns raised by others; electronic money does have a history. The typical problem with distributed-agreement protocols is scalability, so how are you solving that while maintaining safety, what innovations make your system different from others, etc. In fact all of this should be done before any code is published.

3. Users are not going to read or understand any of the above anyway; give them something that works and is safe to use out of the box.

[gmaxwell]

And what happens with small world topologies like this:

Code:

   *full-mesh of 32 validators*   ------- Link X -------  *full-mesh of 32 validators*

(e.g. two large fully meshed clusters, with a single or few links between them— typical of social graphs)

when wallet loaded on two different computers makes conflicting transactions at the same time, one which is sent to one cluster, one to the other cluster?

What happens in the same case when "Link X" is down (either being dos attacked or random maintenance)? When it stays down long enough for several finalization cycles where each cluster has seen unanimous support of its respective conflicted transaction, and never heard of the conflict?

Can the inconsistency ever be resolved? How? When it's resolved will the losing half of the nodes be automatically considered no longer trustworthy?

[JoelKatz]

And what happens with small world topologies like this:

Code:

   *full-mesh of 32 validators*   ------- Link X -------  *full-mesh of 32 validators*

(e.g. two large fully meshed clusters, with a single or few links between them— typical of social graphs)

when wallet loaded on two different computers makes conflicting transactions at the same time, one which is sent to one cluster, one to the other cluster?

What happens in the same case when "Link X" is down (either being dos attacked or random maintenance)? When it stays down long enough for several finalization cycles where each cluster has seen unanimous support of its respective conflicted transaction, and never heard of the conflict?

Can the inconsistency ever be resolved? How? When it's resolved will the losing half of the nodes be automatically considered no longer trustworthy?

It's not clear whether you mean a mesh of trust or a mesh of network connectivity.

If you mean a mesh of network connectivity, the netsplit detection scheme should solve this. You will see that you are getting validations from half or fewer of your validators and know you might be in the minority side of a network split. The network will be broken, but that's as it must be until the split resolves.

If you mean a mesh of trust with link X being some validator who trusts validators in both groups, then link X fail to achieve consensus and bow out. But that's as it should be -- X is misconfigured into two distinct networks. The two distinct networks can now proceed in peace. Presumably, nobody who only trusts validators on the left want to achieve consensus with those on the right, so it shouldn't matter.

You need about 10% overlap for the system to not be slow to converge or to fail to achieve consensus. If that ever happens, it will be clearly known to all and it will require manual intervention to fix.

[gmaxwell]

If you mean a mesh of trust with link X being some validator who trusts validators in both groups, then link X fail to achieve consensus and bow out. But that's as it should be -- X is misconfigured into two distinct networks. The two distinct networks can now proceed in peace. Presumably, nobody who only trusts validators on the left want to achieve consensus with those on the right, so it shouldn't matter.

Yes, I meant trust. Real social graphs have structure like that.  How do you prevent trust structures that will guarantee convergence failure from evolving? How will you manually resolve a loss of convergence from resulting from one?  How can you distinguish one that arose naturally from one created maliciously for plausibly deniable culpability in attacks?

Or more generally— What are the trust topological requirements to prevent failure?  This is the kind of requirement that needs to put into the security assumptions statement.

[Monster Tent]

Is there a similar compact and fairly comprehensive expression of Ripple's security assumptions that could help people reason about the system?

At the highest level -- you are secure so long as the majority of your trust list doesn't conspire. If you have a bad trust list, you can be lied to about what transactions have been applied by the system.

What happens if the majority of each of _their_ (unknowable to me) trust lists conspire?

Something bad must happen, otherwise— My partner and I each run a valditator node make my client trust only those. I know they don't conspire against me. Now my client behind them is totally safe! ...  or not.

You are, of course, completely right. I should be more precise. You are secure if the majority of the nodes on your trust list are secure. This ultimately devolves into the majority of the weight in your effective weighted trust not conspiring.

In your scenario, where you have trusted only two nodes and those two nodes trust conspiring nodes, you can't become convinced a transaction happened without them having that signed transaction to present. You can't rewrite the past. However, you could be duped into thinking a transaction was applied when it wasn't. You will have signed cryptographic proof that you were deceived. (Hopefully in the future, we'll automate collecting and distributing that proof so you only get to conspire once.)

Think about it this way though -- if you have a 51% attack against Bitcoin, you have to make fundamental changes in Bitcoin. If you have a consensus breaking attack against Ripple, you have to remove the conspirators from your trust list.

See my example as to why I don't think its so simple. Shutting out a single high hashpower attacker isn't hard and lots of altcoins have done silly things to accomplish it.  But it's pointless because shutting out a single attacker is not useful if the fundamental assumption that a badguy won't have a computing majority is flawed. Likewise, removing conspiring nodes from your trust list is perhaps not all that useful if they were ever able to get there in the first place.

I largely agree. It comes down to the practical question of which scheme will be more robust in the face of a motivated attacker. I don't think any of us really know that yet.

If they conspire once and that one time someone loses 1 million xrp its a flawed system. After all attackers will be motivated to go after clients who hold large balances.

[proff]

All scale-free networks are vulnerable to directed attacks: just go after the most connected nodes. In Bitcoin we have seen successful attacks on major mining pools in order to steal their potential mining profits. Anyway, sure you can detect netsplits, but your high-volume network has still ground to a halt. Similarly you must assume worst-case placement of conspiring nodes. Crossing your fingers and hoping your scheme is robust is not enough...

[Sunny King]

If you mean a mesh of trust with link X being some validator who trusts validators in both groups, then link X fail to achieve consensus and bow out. But that's as it should be -- X is misconfigured into two distinct networks. The two distinct networks can now proceed in peace. Presumably, nobody who only trusts validators on the left want to achieve consensus with those on the right, so it shouldn't matter.

Yes, I meant trust. Real social graphs have structure like that.  How do you prevent trust structures that will guarantee convergence failure from evolving? How will you manually resolve a loss of convergence from resulting from one?  How can you distinguish one that arose naturally from one created maliciously for plausibly deniable culpability in attacks?

Or more generally— What are the trust topological requirements to prevent failure?  This is the kind of requirement that needs to put into the security assumptions statement.

Hmm Joel I don't know if I like your answer here or not, are you saying a split of trust network is fine? I agree with gmaxwell here that your probably need some ensurance that this doesn't happen (at least make it very very unlikely). Network split is very very serious issue.

Another point I didn't get from your description is that what's your assumption on server node availability? Under a peer-to-peer setting a lot of nodes on UNL may have less than ideal availability, so making a 50% rule to solidify the ledger could be problematic. Also you don't know whether they have solidified they could suddenly all change their mind.

[Sunny King]

Think about it this way though -- if you have a 51% attack against Bitcoin, you have to make fundamental changes in Bitcoin. If you have a consensus breaking attack against Ripple, you have to remove the conspirators from your trust list.

There is a reasonable fix for this though, just set a reorg limit say 100 blocks, and prompt for manual intervention from the user. Given a prolonged network partition situation, there would be either a central or democratic procedure to determine the winning branch, via a checkpoint. This assumes that network partition does not happen too often for longer than a day in practice.

Actually this might be the approach ppcoin eventually adopts.

[gmaxwell]

There is a reasonable fix for this though, just set a reorg limit say 100 blocks, and prompt for manual intervention from the user. Given a prolonged network partition situation, there would be either a central or democratic procedure to determine the winning branch, via a checkpoint. This assumes that network partition does not happen too often for longer than a day in practice.
Actually this might be the approach ppcoin eventually adopts.

that means that anyone who can create 100 blocks can shut the network down 'forever'— if that'll never happen, why secure against it?  If you have some consensus method that can easily resolve the shutdown why not use that for your consensus system instead of a PoX hashchain?  ::meh::  It might actually be a prudent sort of thing to do, but I'm skeptical.

[tacotime]

I largely agree. It comes down to the practical question of which scheme will be more robust in the face of a motivated attacker. I don't think any of us really know that yet.

I can agree with that.

I'm still not sure that I've internalized the implications of your model in ripple, though I now think my initial understanding of the basic technicalities of were at least not totally incorrect.

I find it interesting that it's easy to describe topologies where you are insecure even though _all_ of your peers are honest and most of the network is honest:

Code:

                       /---- Honest0
                       /---  Attacker
         /------moron1 ----- Attacker
         /   /    |    \---- Attacker
         /   |    |    /---- Attacker
      you----|--moron2------ Attacker
         \   |    |    \---- Honest1
         \   \    |    /---- Honest2
         \------notmoron --- Honest3
 

In this graph there are 7 honest validators (honest*,moron*, and notmoron), and 5 attacker controlled identities. All of your direct peers are honest.  And yet you're exploited— Every validator you trustlist sees an attacker controlled majority even though only 41% of the total validators are dishonest.

So the Bitcoin security assumption (most hash power is honest) is not strong enough to make ripple secure if translated to comparable terms ('most trusted nodes in the system are honest').

How do your cryptographic signatures that show if someone misbehaved distinguish between them misbehaving vs trusting someone who misbehaved?  Couldn't I protect my reputation by attacking by simply arranging to trust dishonest sockpuppet nodes?  If I can't then isn't there considerable pressure to only trust the same nodes everyone else trusts?

This is the major problem with ripple.  Someone with a botnet can form thousands or tens of thousands of validated nodes and operate them as normal for months on end, then suddenly command them to reject certain transactions as invalid.  It doesn't even have to be a lot of transactions, just small ones that majorly benefit the botnet operator, and this could be performed very easily with no one catching on to it for some time.  You've created a "one IP one vote" system, something that is warned against in the original bitcoin protocol specifications.  If the chain lives long enough we'll all see why.  Sybil attacks are cheap and the threat of them is real.

[Sunny King]

There is a reasonable fix for this though, just set a reorg limit say 100 blocks, and prompt for manual intervention from the user. Given a prolonged network partition situation, there would be either a central or democratic procedure to determine the winning branch, via a checkpoint. This assumes that network partition does not happen too often for longer than a day in practice.
Actually this might be the approach ppcoin eventually adopts.

that means that anyone who can create 100 blocks can shut the network down 'forever'— if that'll never happen, why secure against it?  If you have some consensus method that can easily resolve the shutdown why not use that for your consensus system instead of a PoX hashchain?  ::meh::  It might actually be a prudent sort of thing to do, but I'm skeptical.

It doesn't shut it down. It just refuses the reorg and log the event and tell user about it, and the network is still chugging along. User should be notified so if there was a legitimate network partition event going on, people can notice and start discussion about it.

Of course the concensus mechanism to deal with these partition event would be quite a bit centralized and costly, that's why there needs to be assumption that it rarely happens.

[misterbigg]

Ripple is a Bitcoin-like payment system for any currency. "Ripple isn't a good currency" is a great rebuttal to an argument nobody's making.

I've been willing to set aside the lack of clear technical documentation and trust that the developers have rigorous mathematical proofs for their claims.

But as I have stated over and over again, it seems people are drawing the conclusion that the "Ripple" currency unit (XRP) functions in the same role as the Bitcoin (BTC). Specifically, that it is a store of value. I've been on the Ripple forum and pointed this out to you JoelKatz. People are coming on there saying they "want to buy a lot of Ripples" and I can only conclude that it is because they think that the Ripple will rise in value like the Bitcoin.

From what you've been telling me, this is not the case. But then we have Jed coming on and saying that yes Ripple does function as a unit of currency like Bitcoin. Which one is it? If the people involved with the project cannot even present a consistent description how can we have confidence in the system?

Either Ripples are just a marginally valued, artificially scarce resource designed to make transaction spam prohibitively expensive (in which case, it is being marketed totally the wrong way) or it functions like the Bitcoin as a store of value (in which, the premine rules Ripple out as any sort of legitimate system no matter how much is being given away).

Look at what people on the Ripple forum are saying:

This guy thinks that having XRPs means he has achieved wealth (like having a bunch of Bitcoins)

I will sadly admit I am confused on what the best play is with my new found wealth.

This one wants to "sell" his initial XRPs to "cash out"

Hello, I'm new to the Ripple. So, where I can see the exchange rate?

This guy wants to "invest early" in XRP for nanobitcents on the Ripple, as an early bet on XRPs gaining significant value

please contact me, large orders over 100k preferred.

Selling VPN services for XRPs. Was this really the purpose behind XRPs?

Post subject: VPN for Ripples! Only 3,000 XRP a month!

Even people posting in this thread think that XRPs are a store of value, like Bitcoin!

Buying pizza with XRP?

I'll pay 10,000 XRP for a couple of pizzas..

hashman refers to the XRP pre-mine:

...greed of the founders drove the ideas down into irrelevancy.

Conflating XRPs with BTCs:

Bitcoin uses the coinbase stuff to hand out the initial distribution.  Ripple XRP is handed out by a single corporation.  A single corporation in control of 80% of the currency is a textbook definition of central authority.

Thinks Ripple is a "coin"

Ripple may be the coin for you...

And it goes on and on.

So what's up? Are XRPs coins, a store of value, like Bitcoin? Or what? Can we please get a straight answer?

[misterbigg]

Furthermore, it is _highly_ relevant and reassuring to hear that Ripple is committed to getting rid of a current central point of failure.

To paraphrase someone else's post in the forum, one of the intrinsic characteristics of Bitcoin is that every node needs to hear about every transaction. For example, every purchase of a child's popsicle or every microbet on a digital lottery. That's just the way the system works. Another characteristic is that individual nodes do not need to have trust in any other nodes for the system to work.

Ripple solves different problems than Bitcoin, and it seems to me that in exchange for getting decentralized scalability to infinity and multiple currencies, the price is that you have to trust at least one node (among other things). It seems reasonable to also accept that another unique property of Ripple is that, unlike Bitcoin, it must be bootstrapped in a centralized way. There needs to be that initial node of trust (unlike Bitcoin).

It is probably too early to worry about Ripple's current lack of decentralization. Bigger problems are:

1) Confusion over the role of XRPs
2) Lack of mathematical proofs of the security and performance of the system
3) Missing source code

We can't even determine if Ripple can be decentralized until we have answers to the three points above.