Topic: WTF happened to ripple? - page 3. (Read 21828 times)

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.

And what happens with small world topologies like this:

(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?

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.

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.

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.

That would cause you to validate the wrong things.

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.

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:

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?

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

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.

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.

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.

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.

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.

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.

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

Is there a mechanism to prevent netsplits?

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

We're not claiming it is decentralized now. We're claiming it requires no central authorities and we are committed to decentralizing it.

I agree. I would say we would also have to wait until a significant fraction of the operating servers aren't under OpenCoin's direct (or perhaps even indirect) control. (For example, until then, if OpenCoin wanted to, it could force a design change that allowed you to create XRP or delete other people's IOUs. Actually, probably not, but you get the idea.)

Again, no central authorities are required by the design and we are committed to a having a decentralized system. We genuinely believe that this is the only way Ripple can actually succeed. The system's security relies on you trusting servers that *aren't* under common control. It is designed to be trustworthy only because it is decentralized. It is not useful if you can't trust it.

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.

I understand maaku and others like to celebrate the flexibility that comes from separating the coinbase function from transaction verification (and that's fine as long as they don't minimize the costs); regardless, it is simply false to claim Ripple is decentralized given how they've chosen to centrally bootstrap the initial distribution.

I suppose if the corp. ultimately succeeds in distributing this sum before running into any major problems you could then genuinely claim there is no central authority or central point of failure.  But only then.

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.

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.

Because servers are tracking the validation processes, it's harder to fool servers than clients. If a client is connected to a non-conspiring server that hasn't itself been fooled, then the client will immediately know it has a problem because it won't accept the proofs the server is sending it and the attack will fail.

I've learned to be less quick about saying something— especially something I don't fully understand— can't work. But I'm having a hard time reasoning about how the points your making result in a secure system.

Bitcoin's consensus algorithm is secure assuming that information is hard to stifle (the longest chain can't be hidden from you)  and so long as conspiring dishonest parties do not control more than a (near-)majority of the hashpower.

If these assumptions are violated a high hashpower attackers can block and reverse transactions and replace their own transactions at a depth related to their hashpower share, but can do nothing else— can't create inflation, can't steal funds from unrelated transactions, etc.


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

The number of servers doesn't matter. What matters is the number of keys you have that other people have chosen to trust.
We have a lot of ideas for how to manage this. But we won't get to decide. We can put forth our solution and people will be free to use it or not. Over time, this will probably need to evolve.

We have several different ideas. Here are three of them:

1) Domains can publish lists of validators at a known URL. You can choose domains to trust. You periodically refresh the list of validators and extend trust based on how many such lists a key appears on. (This is essentially the current model.)

2) When you browse the web, your client could check for domains you were visiting that offer validator lists and then you could click to add their published list of validators to your own.

3) People who use the Ripple system, such as major gateways, could run validators and publish lists of validators (including their own) that they assert are not under common administration.

You genuinely want to find as many validators as you can that are not under common administration. You want to do whatever you can to avoid "cronies". The only failure mode is if you wind up trusting a bunch of conspirators.

We're committed to decentralizing it and we honestly believe that it can only work if it's decentralized. If you don't trust us (and I'm not saying you should) wait until it is decentralized.

What's Bitcoin-like about Ripple is that:

1) Transactions are public and pseudonymous. All system state is public and freely exchanged.

2) Transactions are cryptographically secured.

3) It doesn't require any central authorities once it's deployed. No one person or group will be able force the system to do any particular thing. Nobody will be able to shut it off.

4) The code will be open source. Broad participation in the development will be encouraged.

5) All participants will be able to verify transaction validity if they wish to.

The above assumes we get where we're trying to go. There's no guarantee we'll succeed, but we promise to try very hard.

Darn, I am guessing this isn't the thread where I had posted "in before someone says p2p means peer to peer, not person to person".

Think peer as in a jury of your peers, not peer as in member of the house of lords / big business old boy's network / etc. They don't run around looking for people of your own socioeconomic class to put together a jury of your peers, they run around finding all kinds of random folk off the street, some of whom might turn out to be owners of big businesses some of which aren't.

Unfortunately things like fire-sharing "p2p" networks don't quite fit "c2c" (consumer to consumer, as distinct from business to business or business to consumer) either, since the people/machines involved [can] both produce/provide and consume files.

Maybe we can differentiate p2p from P2P, making one mean peer to peer, (maybe capitals indicates its peer as in the guys at the capital in the house of lords) the other meaning person to person (the smaller / cheaper / lower case)?

(Hey, this is the internet, we get to make up our own terms / conventions / etc for stuff, right?

Free meenz moar beer!

-MarkM-

It's not so simple— some external mechanism needs to prevent sibyl attacks, otherwise I spin up tons of 'servers' and do nasty things.

What I'd call it depends on how that determination happens in practice. I don't believe that something I'd call "peer-to-peer"— e.g. listen to any server you find— would actually work and be secure. One option is Centeralized: e.g. OpenCoin ends up with defacto or dejure control over the lists— this would make the trust scarce and worth behaving to keep, but would also allow shutdown and takeover. But it's not the only option, and I don't know what name I'd give the other ones.

E.g. imagine Bitcoin largely as it exists today, but no POW (difficulty=0)... and no description in the protocol over which chain to accept just "get it from a trusted party".  Is that peer to peer? Centerlized? What is it?   It's not a question you could answer without knowing how people would choose their chain in practice.  Ripple specifies more than that, but I think not enough more for me to say what kind of system I think it is.

I wouldn't even call ripple peer-to-peer between the servers, simply because not all "candidate peers" are equal— some external process makes some peers important and some irrelevant. That might meet the English definition of peer to peer but not the technical one.  Call it "friend to friend" might avoid the overloaded meaning, but it would be odd to call relationships which are primarily between large banks "friendships".  It's peer to peer, but only inside an exclusive club. The nature of the clubs' exclusions define the system more than anything else.  For example— Paypal's infrastructure could be called "peer-to-peer", but to be a peer you must be part of paypal.

Hm.  Maybe I should call Ripple's general class of consensus algorithm "Crony Consensus".

(FWIW, Tor is distributed but not decenteralized.  This is regarded as worry-some by many, but at the same time, the influence of the tor directories is inherently transitory.  Tor doesn't represent stored value. But Bitcoin and Ripple do, the tradeoff is different)