Mike Hearn also made this too.

https://en.bitcoin.it/wiki/Ripple_currency_exchange

I think you both didn't read my document. Maybe I should be a bit more verbose in my original post?

There are many possible ways to combine Bitcoin and the Ripple, depending on what you want to achieve. What Mike Hearn made was specifically designed for currency exchange. On the other hand, my design is specifically for Bitcoin-only transactions, and does not (yet) feature other currencies.

By only using Bitcoins, my variation of the Ripple actually works without credit relationships! Please read my PDF file for the technical details. I think it is quite different from other Ripple concepts.

Hmm, I'm not totally sure I followed the paper, but it's great to see more research in this direction (even though I think Bitcoin can scale pretty well with enough effort).

My understanding is that the hardest part of making Ripple scale is the distributed graph pathfinding algorithms, and that actually Ryan never really managed to make this work. Are you sure Ripple scales better than Bitcoin, in this regard?

I like the commitment scheme where miners resolve race conditions.

For the case of adjusting the credit relationship, have you considered using sequence numbers and lock times?

See here:

  https://en.bitcoin.it/wiki/Contracts

and specifically

  https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

Re: distributed pathfinding. This is a hard problem in computer science. Internet routing is not an example of that, because internet routing is based on a Bitcoin-style broadcast network in which the entire routing table is loaded into every router. When you want to send a packet, you don't go and explore the network. The router knows immediately where to send it.

In some senses this design does not scale indefinitely and at times routing table exhaustion has in fact been a problem for the internet. The solution was simply for people to upgrade their routers.

This is why I don't believe Bitcoin will have scaling issues. Practical experience with floodfill networks suggests that a combination of smart software and stronger hardware can often make them scale far beyond original expectations.

If you want to do Ripple-style pathfinding but within a single CPU/address space, that's a lot easier of course. Then you have something rather like what I proposed for currency exchanges.

For anyone interested in understanding Ripple better, I know a handful of academic papers proposing the same idea with variations:
   - [1] is most similar to Ripple or OpenTransactions, in that each Node creates its own currency and only accepts currencies of adjacent nodes that it 'trusts'. The point of this paper is to show that for some reasonable models of transaction behavior, 'bankruptcy' is isolated and doesn't spiral out of control.
   - [2] is about 'insurance,' rather than credit. Each node 'vouches' for the adjacent nodes that it trusts by putting up some collateral.
   - [3] is also about self-issued currency, except the units are related to storage utilization in a peer-to-peer filesharing network. Nodes only accept currency from adjacent nodes they trust.

All of these have the same basic structure as Ripple. There are three key features:
   a) "Local" assessments of trust. Alice is never left holding debts/credits to a stranger, instead she indicates ahead of time who she's willing to have such a relationship with, e.g. with Bob but not Carol.
   b) Indirect (transitive) transactions. Alice can pay Carol without presuming or creating any trust/relationship between them. Instead, Bob acts as a conduit.
   c) Non-scarce self-issued on-demand currency. Whether it's credit, insurance collateral, trust, or a promise to buy a beer, these transactions are about a fundamentally different currency that is unlike gold: it is not money, it is not universal, and it is not scarce. Alice can inflate her IOU currency at will, but Bob is only vulnerable if he extended a line of credit to her - and then he's only vulnerable up to the 'credit limit' he indicated.

This leads to a very simple web-like topology that models how humans actually socialize! If I invite you to my party, and you bring your asshole friend who pisses on my carpet, then you're the one that needs pay to get my floor cleaned. That is a transitive economic/trust relationship.

Again, Ripple credit is unlike money and therefore unlike BTC: it's not scarce, it's not universal, and it depends on an out-of-band assessment of trustworthiness. So, a Ripple credit won't be as broadly valuable as a Bitcoin. But, since the Ripple transaction mechanism makes transitive exchanges efficient, a Ripple credit is much more broadly useful than an ordinary static debt between two parties. Example: If I owe you a beer, then maybe you'll get a beer. But if I owe you a beer and post it on a Ripple network, then it might help one of your friends buy a used video game from one of my friends. People _do_ establish such trust/credit relationships, and Ripple is about extending these to facilitate exchange within a wider network of indirect trust. The overall economic effect is that we make better utilization of latent trusting relationships in order to increase cooperation and exchange.

I hope this post brings a bit of clarity about the purpose of Ripple and doesn't just add noise. May this thread bear fruitful discussion!

[1] Pranav Dandekar, et al. "Liquidity in Credit Networks: A Little Trust Goes a Long Way" http://www.stanford.edu/~ppd/papers/cn-liquidity.pdf
[2] Dimitri do B. DeFigueiredo and Earl T. Barr. "TrustDavis: A Non-Exploitable Online Reputation System" http://www.cs.ucdavis.edu/~defigued/index_files/trustdavis.pdf
[3] D Levin, et al. "Making Currency Inexpensive with iOwe" http://people.csail.mit.edu/katrina/papers/iowe.pdf

Yes, nice post socrates1024.  The core of ripple is to build a network based on trust relationships.  Trust relationships can have different levels between people.  I believe "financial trust" is different from only "trust" in general.  Financial trust is similar to a credit rating.  If I go to Equifax I can get my credit rating which can be as high as 800.  If you get a rating of 750, you can get a car loan, a $400K house loan, a high level of credit, etc.  A credit rating is primarily a score that loan companies in the United States use to determine if a person is creditworthy for loans.  Ripple is different in that financial trust levels are not universal to everyone.  A ripple financial score or credit rating will become greater for people who I know and trust.  I would not give a stranger a high credit rating unless I know him directly or if my friend can vouch for him.

Another type of real life rating is "bankruptcy."  If you have ever filed for bankruptcy then you can't get a loan for x years.

I think the key to implementing ripple effectively is to import social network data from multiple sources and determine levels of financial trust between friends, family, strangers, and people.  Right not bitcoin-otc, bitcoinary.com, facebook, gmail, google+ could have valuable import data for a ripple implementation.

To summarize:

1) Build ripple by simulating real life factors such as credit rating and bankruptcy.
2.) People in ripple improve their credit score by paying on time and in full.
3.) If you supply your identity and location you credit score can greatly improve.  (Not sure how to make this p2p.)
4.) If you have a high net-worth you can borrow more money.  That means if you supply a bitcoin address loaded with money on it and can prove you own it then your credit rating will improve.

This made a solid talk today in the conference.

Regarding the name of the implementation of this concept: I just realized this is very similar to the Rai stones on the Yap islands: the "shared property" bitcoins are like the stones (big, and hard to move), while the transactions over the network are like the Yap people settling a transaction by orally agreeing to change ownership of some stones (easy, fast). So, is there some way to turn this into a good-sounding name for a payment system?

About the license: I think I'll release the first versions under GPLv3. As long as I am the only author, I can always decide to "downgrade" to a more liberal license, if you can convince me  .

So basically, each other use would be trusting you with money, but you wouldn't trust them?

You could charge fees that cover risk.  If someone pay a certain amount in fees, then you would give them a debt limit of 50% of that amount.

This can't be gamed, but adds some flexibility.  Effectively, when you receive fees, 50% of the fee is added to the link itself.

You could build up trust over time.  For example, send a small amount to the other node, and if they send it back, you know you can trust them for at least that amount.  As more money flows over and back through the link you could increase their credit rating.

The credit limit could be increased by a fraction of the fees generated by having the connection.  Initially, if there are few links, then the links that do exist would generate high fees.  As more trust is created, then the fees drop, but there is less need to generate trust "capital".

Ahh, so they are trusting you with their money?  The only guarantee that they are going to get it back is that you will co-sign the release.

So, they can send you money, by reducing their share of the common property.

You could set it up so that you use your capital to send money as required.

If node 9 sends to node 5, then you could add your money to the link with 5, and complete the transfer.

Do you have automatic settling of transactions?  When you run out of capital, you could settle up on the link that has been inactive for longest, using the bitcoin network.

Having said that I think a star system is not the most optimal.  In the beginning, trust links will be valuable and fees high.  This creates incentives to take risks and trust random nodes.

You system risks losing money due to other nodes losing interest in the network.  The money placed in common ownership could very easily go up in smoke.

Another option is a trust test.  If you send money to an address and it is returned, then you can trust that address for at least that amount.