Bitcoin Forum

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. :(

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.

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.

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. 

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-

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 (http://en.wikipedia.org/wiki/Content-addressable_storage), which seems ideal for this public accounting use case.

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:

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.

I guess this link gives me the answer I was looking for:
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'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.

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.

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.

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?

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)

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-

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.

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.

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?

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.

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.

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.

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

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.

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.

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.

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.

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.

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?

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.

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.

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?

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.

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.

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.

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

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.

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.

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.

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.

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 (https://ripple.com/forum/viewtopic.php?f=1&t=554). 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 (http://) are saying:

This guy thinks that having XRPs means he has achieved wealth (like having a bunch of Bitcoins) (https://ripple.com/forum/viewtopic.php?f=1&t=580)

This one wants to "sell" his initial XRPs to "cash out" (https://ripple.com/forum/viewtopic.php?f=1&t=553)

This guy wants to "invest early" in XRP for nanobitcents on the Ripple, as an early bet on XRPs gaining significant value (https://ripple.com/forum/viewtopic.php?f=1&t=551)

Selling VPN services for XRPs (https://ripple.com/forum/viewtopic.php?f=1&t=502). Was this really the purpose behind XRPs?

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

Buying pizza with XRP? (https://bitcointalk.org/index.php?topic=145984.0)

hashman refers to the XRP pre-mine:

Conflating XRPs with BTCs:

Thinks Ripple is a "coin"

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?

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.

Of course it would be currency and with fixed/dwindling supply (after distribution process completes), it would be as good a store of value as bitcoin.  Obviously Joel is just doing the necessary PR to appease the 'premine' outrage.   ;D

If I had such a good PR/image skills I would have my own startup soon  :P

I have got a similar opinion like OP.

Ripple.com is a mix of Bitcoin-like currency XRP and ripple IOUs. As XRP is more suitable for payments than IOUs, it seems that IOUs would become only a secondary feature, and so it seems unfair to call this system Ripple. The difference from Bitcoin would be no mining, but starting a new server would be more troublesome because the peer has to find some (many?) peers that he would trust not to cheat him, ideally some peers he knows.

How about True Ripple? I can think of a system with just IOUs without XRP. It would also be truly P2P. There wouldn't be the global ledger but just peers transacting with (few) peers they know. All value transfer would be performed using chains of IOU transfers between peers, obviously. To prevent spamming there would be fees for all activities using up resources, like routing a search through a node, or routing a payment through a node. If a node sets fees too high then the traffic would route through someone else eventually. The actual interaction between nodes would need to be somewhat cautious, so the money don't disappear on a half-way, but it seems doable.

I fully understand that this kind of reasoning has a kind of attractive logic to it, but I think that's an extremely unlikely scenario. I could have made a similar argument in 1950 that people would soon abandon fiat currencies and switch to gold certificates. I can make a similar argument that Bitcoin will make fiat currencies obsolete. Sure, that might be the endgame in the far future, but to focus on that endgame *now*, rather than the many decades of work we have to get there, is navel contemplation.

So, can we get a straight answer?

JoelKatz can I have your personal opinions on the speculation going on with XRP right now (see my example quotes)?

Unfortunately, no. I am prohibited from discussing that. Those things that I cannot comment honestly on for any reason, I simply do not discuss. There's nothing I enjoy more than sharing my honest opinions with others, but in this area, I cannot do so.

Actually, this says a lot.


I'll do it for you. You're insanely annoyed at the onslaught of newbs who just don't seem to understand that XRPs are not like Bitcoin. And you're frustrated because you can't respond to set them straight, because doing so might make the necessary and difficult bootstrapping process even harder.

Good one.  I will interpret Joel's _lack_ of disagreement with the previous remark as an implicit agreement :-)

Oh well, next time maybe create a hundred trillion whatzits and give people fifty million each when doing giveaways, maybe instant internet multimillionaires wouldn't be as ungrateful as people who receive handouts of only a puny fifty grand! ;)

:D

-MarkM-

Credit where credit is due! The following scheme was described by Ben Laurie years ago:

The "central authority" consists of a set of distributed (and preferably independent) servers which keep track of the ledger of balances (a Merkle hash tree) using a Byzantine-fault-tolerant consensus protocol. They enforce constraints on the system (e.g., coin creation and distribution---no need to do it manually or premine) and blacklist dishonest or malfunctioning servers.

All the honest servers will agree to the same transaction log (of course a severe netsplit will stop transactions from committing). The clients need to come preconfigured with a list of servers (which can be updated by the network). So, unless something goes very, very wrong, there is no need for the user to worry about deciding whom servers to trust.

There are clearly some details to fill in to specify a complete implementation, scalability issues, etc., but Laurie's distributed currency uses established ingredients that are mathematically proved to work and gives you transaction confirmation in seconds (no need to "mine"). It could also be used for Bitcoin and other currency transfer/exchange (there seems to be a need for this anyway) as well as more advanced uses.

Now, I indeed remember the original ripple web-of-trust proposal being as gmaxwell described. The "new" system seems to be something else, and I echo people's concerns expressed in this thread and do not see how they have been resolved to any satisfaction. It may be unintentional on the part of the ripple developers, but something seems fishy or opaque about it (at least at this point in time), and it looks like a commercial rather than a community project.

+1. Excellent summary of the situation.

I find it near impossible to discuss this matter transparently with Joel.

Joel Katz: "I am prohibited from disclosing my opinion about XRP's future value."
(https://bitcointalk.org/index.php?topic=144471.msg1554983#msg1554983)

This is not a joke, and while some people love to suck up to power authority, most bitcoiners in this forum are smart enough to recognize a rotten egg.

Joel, I recommend to you whole wholeheartedly to either expose your commercial intentions, or commit to altering and democratizing the txn solution at hand; otherwise you will be building a ticking time bomb. You won't end up controlling 50%+ market share but you know what they say: "Power tends to corrupt, and absolute power corrupts absolutely." Don't set yourself up for failure.

From a true open source and decentralized democratized point of view, the idea of centralized txn authority is ridiculous. If this is the "only viable solution" you should either be opening up the platform to multiple fiat currencies so that users can create their own and there is a competitive free market amongst txn fee operators, or define a rock solid democratic distribution plan of all the XRP.

Yet as I find the idea of an unsustainable self destructive txn fee currency a horrible idea akin to building on sand, the focus should be on disconnecting any value system from this txn fee mechanism, and focusing on proof of work as a security measure; or allow the network node operators to have a choice of what currency they prefer be paid as a txn mechanism.

I realize this is a technical challenge but my intention is to open the debate and make sure you are open to change, otherwise I and others will fork our efforts towards bitcoin web of trust enhancement and your "ripple + get rich quick scheme" will bite the dust.

You are clearly smart enough to know that we would realize this "necessary design flaw" as an overly greedy excuse on your part for power and control; therefore your downplaying of the issue leads me to believe your actions are highly strategic and premeditated. If you truly want to succeed with your efforts and with this community your veil of secrecy and prohibited dialog needs to end.

Joel, please do not take my comments as hostile or personal. I really want ripple to succeed, and I'm simply pointing out the elephant in the room.

So many text here  ;D

Even some aspects of bitcoin are quite a bit over my head, ripple is just too complex for me to understand ;D

Is this a joke? lol

Say, hypothetically, you were the president of a publicly-traded company and you were about to announce a major new product that would likely result in an increase in your company's stock price. Or maybe you're not about to introduce a major new product but people are expecting you to. Or may you know your company is being investigated by the FBI for importing lobsters illegally (50 CFR 640.27). And say someone on a forum asks you, "So, what up with your company?" What do you do?

Way to give a straight answer to the question at hand... running around in circles. I will just leave this here

http://www.rugatu.com/questions/6452/what-is-ripple

Suppose my idea of imagining Ripples as if they are more like community shares than a community currency per se of a more normal (un-sharelike) type.

Suppose the SEC and other branches of Big Brother have not made any ruling that "community shares" are some kind of "exemption" from rules and regulations applicable to "corporate shares".

Suppose people are already in danger of predatory speculators / Uranian mafia / Ferrengi relieving them of their birthright for a mess of pottage.

What do you say/write?

a) If you are an "insider"?

b) If you are a deniable asset of the Martian Intelligence 5ervice based out of the city MI-5ius of the planet known as M5?

c) Other?

-MarkM-

To me, it looks like it is both a commercial and community project.  Is that a paradox? Not necessarily.

It looks like the pre-mined pre-issued XRP are a way for the developers/founders to monetize their work.  That's fair enough in my opinion, even though they overdid it by keeping such a large share.

I too would have preferred a "pure" community project, but the commercial element won't stop me from using Ripple.

I'm happy that someone is working hard at making this idea happen.  At least the XRP pre-issuing is giving the developers a motivation to keep working at it.  I prefer an imperfect Ripple that actually happens in the real world than a perfect, idealistic Ripple that languishes as an idea on a mailing list for 10 years. 

All this discussion about the XRP price is petty.  Speculators are gonna speculate.  There isn't much anyone can do about that in a free market, not even the Ripple founders.  Who cares if there is hoarding of XRP? Who cares if there are XRP bubbles?

It terms of Ripple functionality, none of that matters. Neither does it matter that a single entity holds 80% of XRP.  That does not make them a "central bank".  Even if OpenCoin held 99% of XRP, once Ripple transitions to a community project, this will not allow them to "buy" consensus or to block certain transactions.  Maybe they can manipulate or crash the XRP market. Who cares? That will only affect people who transact in XRP, not those who transact in other currencies.  And the ability to transact in arbitrary currencies is the main selling point of Ripple. The XRP are just an auxiliary tool.
 

In fact, not only *can* they crash the XRP market, they will, repeatedly. As long as the giveaways continue happening, XRP will be seriously hampered as a store of value. This is one of the reasons the pre-issue doesn't bother me too much: unless they're lying about how they plan to distribute XRP, it will be difficult for them to make much money by cashing out. Their stated intentions – making Ripple free to use as long as possible for as many people as possible – are incompatible with making a quick buck off of the pre-issued XRP.

Yes, precisely. That's why I'm wide eyed at some people paying up to 4 BTC for 50kXRP.

The purpose of XRPs is not to become a store of value. It's purpose is to work as an anti-spam fee token to make it more difficult to spam the network. Thus, they need to be cheap enough for pretty much anyone to be able to afford to make an account. Giving them out for free helps this as well as keeping a big portion of them for themselves, that keeps speculators in check somewhat (well ok, not the stupid ones)

I still wouldn't mind seeing an implementation of Laurie's (et al.) scheme of instantly (well, within seconds) confirming transactions via a distributed authority. Bitcoin may need that anyway, in one form or another.

Still would take on the order of a year of development to do everything right, of course. But, if you really do not like Ripple, there are things you can do about it other than complain.

Not only will the XRP market crash each time there is another dump/giveaway/massive sale by the founders, they have also explicitly stated that the reserve requirements and transaction fees may be lowered in the future, and each time these are lowered the price will drop as well.

That just makes claiming it is not a currency and warning people not to treat it as one make all the more sense.

Do you have democracy in your country?

If so, what measures are in place to ensure that there is a viable market, without crashes, for votes, so speculators buying votes are ensured the price won't crash out from under them?

Just curious... :)

-MarkM-

Hey Joel,

Thanks for answering so many questions on this thread. I'm hoping you can answer a couple more:

First, can you describe what benefits Ripple has over colored coins? The ripple client looks great, and is very easy to use, but couldn't the same IOUs be issued and traded using colored bitcoins?

I've been watching the development of colored coins over at bitcoinx.org, as I consider trade in stable currencies to be a "the next big step" for distributed currency. Ripple seems to have some great momentum, so maybe you will stay ahead of colored coins just based on getting there first.

Second, are you planning on support for IOUs denominated in user-specified units? For instance, could I use Ripple to release IOUs denominated in barrels of crude oil? Could I release IOUs denominated in future profits of a company (essentially a stock offering)?

Thanks!

Theoretically the same IOUs could be issued using colored Bitcoins, but then you're cramming a round peg into a square hole. Because Ripple is designed to do this, it has features that makes this not just possible but efficient. Colored coins are good for smart property, but I don't see how they get you things like payment paths and distributed exchanges.

The network just treats a currency as an opaque 160-bit number. A portion of that namespace is reserved for three-letter currency codes. The network itself has no list of valid codes, so if you want to use "XBL" for barrels of crude, you can. The client has a list of known currencies, but anyone can modify that list and we can add configurable currencies to store in the wallet if there's demand.

On our planned feature list is fully custom currencies. A custom currency would be created by someone and would have an entry in the ledger. Its currency code would be a hash that would allow the client to find its specification. Custom currencies could be associated with a particular web site and have custom display rules and so on. The feature set is not fully fleshed out yet as the only real use case we have to far as demurrage.

Regarding custom currencies: awesome! For me, that is the really attractive use case for something like Ripple.

Regarding colored coins: Forum user killerstorm has demonstrated atomic trades and proof-of-concept for distributed exchange of colored coins. Bitcoinx.org is (IMHO) your closest competition, so you would be wise to keep a close eye on what they are doing.

I am watching both your project and theirs with great interest. Keep up the good work!

Let's not forget other technologies and designs for "colorable cryptoassets".

Open Transactions (OT): my main objection to chaumian "cash" (apart from the badly chosen term "cash", for something that looks and cuacks like credit) is that it cannot be "rippled" in a transitive but atomic transaction, but as maaku proposed it can be implemented on top of a PoW chain and probably a ledger consensus system too and be more p2p. It has better privacy than colored coins and much better than Ripple's (is not free to cycle keypairs in the ledger). For me the non-ripplable flaw takes it out of the game, but many use cases (say stocks or bonds) don't really need that.

Two phase ripple protocol (2PR): it has good privacy too and can use both a blockchain or ledger to achieve atomicity. That's practically equivalent to hash non-public transactions into the tree, so I think the best option would be to directly integrate it in the ledger or the chain or both. Disadvantages: intermediaries must be online, which also kind of disqualifies it for some smart property use cases.
My wish is a ripple atomic transaction containing both pseudonymous and private IOU transfers, and I have a little draft for that: https://groups.google.com/d/topic/rippleusers/05c9JlxCmXs/discussion

Oh, and a shared disadvantage of both colored coins and 2PR is that they can't publish binding offers. That's a disadvantage ripplecoin didn't had. Maybe colored coins usage ends up turning bitcoin into ripplecoin (or an equivalent) through a series of convenient and non-polemic hard forks, who knows.

Certainly any of these cryptoassets/ripple implementations has the potential to be highly disruptive, but we shouldn't discard the possibility of an ecosystem with several of them disrupting the financial/monetary system together.
It is good to have various bullets: resilience.

I'm really doubtful there. Global blockchains to aggregate color coins has horrible scalability and is rife with cost externalization and commons risk.  I think schemes which do not require perpetual global consensus are more interesting especially in terms of things-that-add-to-the-bitcoin-ecosystem.

Good point. Actually I think 2PR will be the best for scalability, but there's some use cases that require public pseudonymous accounting.
And I don't know if it would have been better to start with 2PR, but public accounting of arbitrary assets is what is being developed now. The ledger of course implements Ripple, and colored coins could do it too.
Would binding offers on the blockchain make colored coins based ripple non-scalable? I don't think so, just maybe a little bit more expensive than other solutions like out-of-the-chain "advertising". That would still be possible adding the new feature (hard fork required), but you're just allowing to intermediaries to participate on transactions when they're offline and can't sign.
But of course, if you make that hard fork you would directly eliminate the necessity of "tainted satoshis" and differentiate between btc and IOU from now on.
By the way, only a bit is necessary, I don't like those three letter codes on ripple's ledger. Want to issue two denominations? Create two addresses and connect them at the rate you prefer.

In this old thread I described how the Ripple consensus model was unsound... that it could be expected to spontaneously break unless the topology met certain characteristics which were unlikely to be met by any graph except a centrally controlled one and that without additional unspecified functionality (perhaps hidden in assumed behaviour of users or via centralization) couldn't resist sibyl attacks. Unfortunately Ripple's creators responded to these concerns-- to the extent that they responded at all-- with evasion and a seeming refusal to make a clear statement of their security assumptions that, coupled with their design, supported their security claims.  And the media and finance industry seems to have largely swallowed their claims without much critical thinking seemingly counting on an orgy of social proof that seems to have been ultimately backed by the same nothingness that backs their pre-mined currency.

I wasn't the only person to point out these issues, more recently Ripple labs published a paper (https://ripple.com/files/ripple_consensus_whitepaper.pdf) claiming the soundness of their model, which made a number of clearly illogical arguments and rested on many unclear and unsubstantiated assumptions, and it was also criticized by Andrew Miller, for many of the same reasons I criticized it here.

(and in this thread I was handicapped by the fact that ripple was closed source at this time: but even so its limitations were apparent simply from the seemingly impossible claims that its creators couldn't back up)

On Tuesday at a Bitcoin event I was still being harangued by Ripple/Stellar advocates claiming the absolute soundness of the system.  I care about the whole cryptocurrency ecosystem since, in the minds of the public any failure is harmful to all of us, and I don't want to see anyone suffer losses not even the gullible... But it makes no sense for me to spend my limited time providing free consulting for the impossibly torrent of ill-advised, impossibility claiming, systems... especially when they're not thankful and/or respond with obfuscation that makes their work unrealizable or hand-waving without admitting their new assumptions. I don't want to see anyone get hurt, but ... hey, I spoke up a bit and people continued on anyways without asking the kind of tough questions they should have been asking. I'm certainly not going to spend all me time correcting everyone who is wrong on the internet, especially when altcoin folks have been known to play pretty dirty toward their critics. No one should assume that other people are going to go out of their way to beg them to not use something broken.

So, when I found out that Stellar spontaneously split consensus state, apparently just as I described in this thread (https://bitcointalk.org/index.php?topic=144471.msg1551096#msg1551096), without even an attacker (though any consensus split is easily exploited by attackers of opportunity once it exists)-- Well, the only thing that surprised me was the burst of honesty in admitting that the system was unsound, but I was also disappointed that the lack of frankness about how fundamental the limitations are in this space-- instead advocating the hope of magical fixes sure to be found by a respected authority, and I was also disappointed that no mention was given of that fact that other experienced people in this space had warned of precisely these issues, going back several years.   I also was saddened to see that no one noticed the dissonance in the 'temporary' solution of converting to a centralized model:  If a system can be converted by some loss correcting central bank into a centralized system ... can we really say it was ever decentralized in the first place?

Perhaps in the future more people will ask the hard questions and demand better answers?  If so, it would be worth more time for experienced people to spend time reviewing other systems and we could all benefit. Otherwise, perhaps those who aren't interested in standing up to some of the rigor we'd normally expect from a cryptosystem will stop calling their broken altcoins "cryptocurrencies".  Those of us who actually want to build sound systems don't want our work sullied by these predictable failures, and being able to say "I told you so" is no consolation.

Proof? To me it seems like the changes in https://github.com/stellar/stellard/commit/067d7158720331937fc782cbb230e8d422cd7341 (especially "Consider there is consensus when we detect that we've fallen behind") which are exclusive to Stellar are potentially to blame, not their validation network topology (validators that were operated by one entitiy - SDF - started to disagree with each other, even though they likely had identical UNLs).

If that "bank" is system relevant, maybe...? Consider that one day a large majority of Bitcoin exchanges and service providers (BitPay, Coinbase...) decide to only accept Bitcoins sent on their centrally mined block chain. Either they all remove themselves immediately from the Bitcoin community or the Bitcoin community has to move over to their centralized solution. While Bitcoin's community consists of lots of people with lots of different ideas, that's something that is not very likely to "fly"... Stellar on the other hand consists mainly of fake accounts that were used to grab facebook giveaways. Also not a lot of people seem competent enough to run their own nodes (it is not incentivized after all, compared to Bitcoin where at least miners need to run full nodes). In practice, the SDF likely is the only major player (main hosted wallet that contacts SDF hosted nodes by default) in that ecosystem, so it is not that hard to (re)take control over the whole network.

https://ripple.com/why-the-stellar-forking-issue-does-not-affect-ripple/