WTF happened to ripple?

[gmaxwell]

The original idea for ripple was a credit network based on pairwise trust. The reliance of pairwise trust instead of global consensus gave it a significant scaling advantage compared to blockchain crypto-currencies: if you make a set of trades that can be settled entirely within your local community there would be no need to tell the whole world about them. It would have been possible to use ripple along side Bitcoin in order to get low cost high scale transactions denominated in Bitcoin— which you then periodically and automatically settled with actual Bitcoin.

The ripple system of today is very different: It is a blockchain global consensus system— like Bitcoin, with all the inherent scaling limits— which exchanges pre-mined coins.  It replaces the attack resistant decentralized POW consensus in Bitcoin with a something which is either dependent on centralized trust or, alternatively, is sibyl vulnerable (depending on how  UNL actually plays out— the system basically punts sybil resistance to the user, instead of being fundamentally sibyl resistant like POW systems; my expectation is that sybil resistance is too hard to punt to the user and the effect will that people will only trust a few big nodes— effectively making it a centralized system).

How did it go from a interesting and potentially worthwhile addition to the cryptocoin ecosystem to— what basically amounts to— "just another premined altcoin"? Frankly, the whole things sounds like something RealSolid would have come up with now.

[1714137049]

1714137049

[Bit_Happy]

The original idea for ripple was a credit network based on pairwise trust....

They still show a trust system like this:

The system works because everyone along the path has vouched for the person just directly before him in the pathway. He accepts an IOU from her and then issues an IOU of his own for the same amount to the next person in the path who accepts his. His balance then zeroes out and the IOU has moved along one more link in the pathway.

The more people you trust and the more people trust you, the more pathways there will be for IOUs to travel. The more IOU pathways available, the more transactions become possible without a Ripple gateway.




Edit:
This looks great...

Built-in currency exchange
Currency exchange is built-in, allowing people to pay and receive in their preferred currency — including Bitcoin. So you can make payments in BTC even for things priced in fiat, or conversely, accrue BTC from payments made from payers using euros, yen, or dollars. In general, Ripple expands the Bitcoin marketplace.



...and this looks somewhat bad.   

A Gateway will typically:

    Accept fiat from a customer and credit their ripple account balance.
    Accept funds from a ripple account and send the customer fiat.
        Gateways should comply with the BSA, have AML policies and require KYC information.

[jancsika]

The original idea for ripple was a credit network based on pairwise trust. The reliance of pairwise trust instead of global consensus gave it a significant scaling advantage

The only _real_ examples where there would have been a scaling advantage were centralized networks run by Ryan (and maybe a handful of other servers).  I suppose you could call RipplePay and Villages proofs-of-concept with the possibility for a federation glued together by Bitcoins, but afaict nobody ever implemented anything like that.  It was just a series of vague proposals on the mailing list.  (And even if someone did implement that, they would run into the same centralization problems Diaspora has without any of the data control features.)

If you wanted to create a bonafide p2p Ripple without the use of a blockchain, how would you deal with nodes appearing and disappearing just as quickly as they do with Bittorrent?

I'm not saying that the new Ripple solves this-- I'm saying it's the next logical step in a system that feigns decentralization while it implements a centralized solution.  The current Ripple XRP system and (to a large extent) Freicoin are both _centralized_ approaches to digital currencies.  Whether its solving puzzles, downloading/verifying a blockchain, or maintaining the node list, why should the user do any work whatsoever without knowing the rules for how the rewards (or the bulk of the initial rewards) controlled by a single entity are to be divvied up?  This would be like if Bittorrent had started by encouraging hundreds of thousands of nodes to connect through a bunch of trackers, then at some point in the future having a single node with all the files people want start uploading to everyone else.  It's an absurd idea for bootstrapping a network-- or, more properly, it's a way of implementing a protocol without having addressed one of its core problems.

You can't claim to have designed the next generation of digital currency and punt on how to allocate your resources.  Of course I'm happy to be wrong if it turns out that, "just ask and we'll give you some," is the holy grail here.

[hashman]

I could be wrong of course, but the first answer to your question that comes to my mind is:

the same thing that happened to Chaum e-currency, RSA, and many other efforts (OK you named at least one):  mainly, greed of the founders drove the ideas down into irrelevancy. 

Lets see me proved wrong please   I liked what I saw at first too. 

[markm]

The current Ripple is maybe better referred to as a B2B network than a P2P network, since really it is not intended that ordinary people will run an actual node (server).

-MarkM-

[jtimon]

I agree that a non-public ripple implementation like the two phase design could be more efficient in many cases, and it would be also more private.
That design had a "register" server as a commit method (a server that just timestamps the commit id) or a blockchain commit method. It could be a ledger commit method.
The main disadvantage of this approach is that it requires all intermediaries in a transaction to be online, pushing for centralized mail-like servers.
But I'm sure a system like that will eventually appear, and I think it can be combined with a chain/ledger type of ripple system.
Colored coins can implement the ripple concept on the bitcoin blockchain too.
So whether this new consensus system works or not, Ripple will be there, and I'm very happy about it.

But if the system works, it seems it will be more efficient than bitcoin, precisely for not having mining.
And the system NEEDS a scarce token to be secure, they had to create xrp, just like a ripplecoin would have needed its own hostcoin.

But now we realize that mining was a solution for two problems: security and issuing.

When we were asked "Isn't mining wasteful", we used to argue "No, it's the cost of security, cheaper than other monetary systems".

But if opencoin issued the initial supply through a free software program to submit proof of work, and they we're asked...

-Isn't this wasteful ?
-No, it's p2p issuance.

Would that make sense for the average person who can't even mine ? I don't think so.

What this means to me is that the issuance problem wasn't really solved in the first place. That's why we want to try a different approach with Freicoin, taking it as an opportunity to attract attention and reputation to the currency, let's see what happens.
And although I'm concerned about what they're going to do with xrp, I'm glad is not giving it to miners they don't need as Ben Lauri proposed for his mining-less minettes (which by the way I'm not sure what relation it has with this new ripple system).
If they distribute them badly and xrp become somehow unacceptable, just fork and try again.
I'm very excited about the technical improvements this new chain can bring us besides mining-less p2p accounting. They told me they're using Content-addressable storage, which seems ideal for this public accounting use case.

[JoelKatz]

I think most of your complaints are legitimate. Every system reflects tradeoffs and Ripple is not trying to be all things to all people. But I have to disagree with this part:

How did it go from a interesting and potentially worthwhile addition to the cryptocoin ecosystem to— what basically amounts to— "just another premined altcoin"? Frankly, the whole things sounds like something RealSolid would have come up with now.

The point is to allow people to transact in fiat currencies much the same way they transact in Bitcoins. Bitcoin is a currency with a built in payment system for that currency. 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.

[gmaxwell]

I guess this link gives me the answer I was looking for:

utunga 22 hours ago | link | parent | flag
snippet of email from Ryan Fugger Sep last year (2012) seems relevant
.. group would like to take over the Ripple project and call their system "Ripple". They have offered me xx for this, which would give them ownership of all Ripple software I've written...[and] ripplepay.com domains... I could continue my work independently, but I would need to give it a different name.

I think this pretty much explains the stark disconnect between ripple of now and ripple of the past.  I feel a little cheated: I wrote positive sounding statements in the past about the usefulness of Ripple, and I wouldn't currently apply those statements to the current system.  My endorsement wasn't Ryan Fugger's to sell. (Fortunately on the forum I can go back and edit my old posts to remove reference to Ripple (Edit: And I've since done so)).

I think most of your complaints are legitimate. Every system reflects tradeoffs and Ripple is not trying to be all things to all people.[...]The point is to allow people to transact in fiat currencies much the same way they transact in Bitcoins. Bitcoin is a currency with a built in payment system for that currency. Ripple is a Bitcoin-like payment system for any currency.

I'm certainly a fan of having things with different tradeoffs! But I don't think I'd call Ripple a "Bitcoin like" payment system— it seems to have inherited some of Bitcoin's scaling weaknesses, but not its fundamental purpose or strengths (strong decentralization). The places where it is similar seem to be fairly superficial (use of ECDSA and base58 encoded 160 bit addresses).  Maybe I'm entirely missing what is actually bitcoin like about it. ... but not being Bitcoin like is a good thing, ... failing to be obviously and assuredly decentralized, however, makes me skeptical of its future.

"Ripple isn't a good currency" is a great rebuttal to an argument nobody's making.

It's an argument implicitly being made in many of the threads on the forum here where people are offering increasingly large prices for XRP.

[JoelKatz]

The current Ripple is maybe better referred to as a B2B network than a P2P network, since really it is not intended that ordinary people will run an actual node (server).

You're right. The clients are not peers since they don't provide services to anything and so, to be precise, Ripple should not be described as a P2P network unless you mean the relationship among servers. B2B's not really right either -- if you mean the servers, they are P2P. If you mean the clients, they're not B2B. There may not be any perfect term to describe it. I still think P2P is closest because it behaves just as if it would if it were "really" P2P except that adding a client doesn't add capacity. Some may consider that fundamental.

[Sunny King]

It qualifies as peer-to-peer in my book as long as you've got enough people to run server nodes so it couldn't be shut down.

Sort of like tor I think.

Also, wasn't bitcoin intended to move toward light client for users as well?

[gmaxwell]

It qualifies as peer-to-peer in my book as long as you've got enough people to run server nodes so it couldn't be shut down.

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)

[markm]

The current Ripple is maybe better referred to as a B2B network than a P2P network, since really it is not intended that ordinary people will run an actual node (server).

You're right. The clients are not peers since they don't provide services to anything and so, to be precise, Ripple should not be described as a P2P network unless you mean the relationship among servers. B2B's not really right either -- if you mean the servers, they are P2P. If you mean the clients, they're not B2B. There may not be any perfect term to describe it. I still think P2P is closest because it behaves just as if it would if it were "really" P2P except that adding a client doesn't add capacity. Some may consider that fundamental.

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-

[JoelKatz]

Maybe I'm entirely missing what is actually bitcoin like about it. ... but not being Bitcoin like is a good thing, ... failing to be obviously and assuredly decentralized, however, makes me skeptical of its future.

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.

[JoelKatz]

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

The number of servers doesn't matter. What matters is the number of keys you have that other people have chosen to trust.

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

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.

[gmaxwell]

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.

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?

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

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.

[jancsika]

What's Bitcoin-like about Ripple is that:

[...]

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.

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.

[JoelKatz]

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.

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.

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

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.

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.

[jancsika]

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.

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.

Is there a mechanism to prevent netsplits?

[JoelKatz]

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