Combining Bitcoin and the Ripple -> fast, scalable, decentralized and more

[cjp]

I've put some more work into combining Bitcoin and the Ripple. From a Bitcoin point of view, the main objectives are to make transactions fast and make Bitcoin more scalable towards global-scale usage, while still keeping a decentralized approach, respecting the privacy of participants and minimizing the amount of trust you need to put in other people in order to trust the system.

Draft 1:
ripple_bitcoin_draft_1.pdf

Draft 2 (added 17 jan 2013):
ripple_bitcoin_draft_2.pdf

Please comment on these ideas, and let me know if something is not clear. I think many of the ideas I wrote down are independent of each other, so even if you can show that one particular choice is wrong, then the other ideas can still be useful.

[jimbobway]

Mike Hearn also made this too.

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

[Sukrim]

There's also too much social pressure in the system in my opinion: What if I give some good friends of mine only 10 USD of credit, even though they might need more? Why would I make better financial decisions, without even the possibility (out of social conventions) to first audit my client or at least demand statements of owned property etc. . but just by knowing they're nice people to get along with?

Also I think organizations and/or vocal minorities might have too much trust in such a system - see Bitcoinica, they would have been able to draw MASSIVE amounts out of such a Ripple system based on trust alone and generated a much heavier loss.

[cjp]

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.

[jimbobway]

Ok, I read your paper.  Lot of good ideas.  I'm trying to relate it to real life where my friends borrow money from me or vice versa.  I imagine this could be a facebook app where one can import a social graph and use that as an initial network for an individual user.

I am not sure I agree with the rollback concept.  If Bob and Alice do in fact trust each other then they can "rollback the transaction" by performing another transaction.  For example, Bob gives $3 to Alice.  But, there was an communication error somewhere, so instead of rolling back Alice can just give $3 to Bob back since they trust each other.

It seems like a rollback is like putting the money into escrow and having it "locked" up until it is committed.

I'm just typing out some ideas, not really sure if they are really solid.

[Mike Hearn]

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?

[cjp]

Ok, I read your paper.  Lot of good ideas.  I'm trying to relate it to real life where my friends borrow money from me or vice versa.  I imagine this could be a facebook app where one can import a social graph and use that as an initial network for an individual user.

I am not sure I agree with the rollback concept.  If Bob and Alice do in fact trust each other then they can "rollback the transaction" by performing another transaction.  For example, Bob gives $3 to Alice.  But, there was an communication error somewhere, so instead of rolling back Alice can just give $3 to Bob back since they trust each other.

It seems like a rollback is like putting the money into escrow and having it "locked" up until it is committed.

I'm just typing out some ideas, not really sure if they are really solid.

Given their current reputation, I doubt that Facebook would be the best party to host your finances. But others might disagree, and I think it will be possible to add Ripple-connectivity to social network sites, in a similar way as it is possible to add e-mail functionality.

Talking about e-mail: I think that, for the user experience, a Ripple account will look very similar to an e-mail account, and some hosts might actually make a link between both services. Although not technically correct, the user experience could be that you can actually "send money to an e-mail address".

If you already performed a successfully committed transaction and then you want to roll it back, then, yes, performing a transaction in the opposite direction is the way to go. The rollback problem I dealt with in the paper is about how to deal with a transaction that somehow gets stuck halfway to being committed. You want to make an agreement between all parties to either rollback this transaction (and then maybe retry), or commit it. And you want that agreement within a reasonable amount of time.

It's not the rollback that puts money into escrow, it's the "promising" phase of the transaction that puts money into escrow. Both commit and rollback are ways to unlock the money.

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?

I don't see big problems with the pathfinding; to me it looks very much like the Internet, except we don't have subnets, so you can't route based on netmasks, and maybe availability of routes changes a bit faster. But I don't have a formal IT education, and maybe you have more experience, so maybe you can enlighten me about the great problems in Ripple pathfinding.

I've not yet considered sequence numbers and lock times. Do you think they could prevent the "hijacking" mentioned in my paper? Can the relationship between direct neighbors be made completely trust-free?

[Mike Hearn]

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.

[socrates1024]

Combining Bitcoin with Ripple is a very important idea. The "Ripple" is an abstract kind of transaction involving a chain reaction / bucket brigade / relay of value between multiple people. The basic Ripple goes like this:
      Alice pays Carol via Bob. Before the transaction, Carol owed Bob, but now Alice owes Bob instead, and Carol's debt is canceled. Bob had also previously granted Alice a 'line of credit' allowing her to do this.

Again this is an abstract transaction, the units of value are arbitrary and may as well be denominated in "BobBux" or "Beers from Bob" or the like. There are potentially many ways of implementing this, mostly varying by whether a central party manages the accounts and whether or not the funds are frozen in escrow. This is the technical challenge, it's about an atomic commit for multiple transactions.

Notice that in the above example, Bob was central to the transaction, yet he played a passive role. Alice was able to initiate and commit the transaction all on her own, as Bob had already granted her the capability to do so. There are potentially several middle parties, perhaps Bob1, Bob2, Bob3. This is a truly different structure than Bitcoin, since it requires storing both the credits (which are like account balances) and the credit lines (which are like potential credits or capabilities).

As far as I can tell, Mike Hearn's proposal and cjp's proposal are two different ways of performing the commit, although both of them require the passive parties like Bob to play an online role. They both involve collecting signatures from everyone involved in the transaction, including the intermediaries. Both involve the potential for funds to be held up in Escrow, at least temporarily, resulting in loss of liquidity.

CJP's proposal:
   If I understand this correctly, the central novelty of this paper is that the initiator of a Ripple transaction can post a Bitcoin bounty to be given as a reward to the first party that publishes the N valid Ripple signatures (N=5 means Alice, Bob1, Bob2, Bob3, Carol, all need to sign). The BTC bounty has a timeout, so if the transaction fails it can be reclaimed by the initiator. Could you elaborate on what model of rationality might be used to show that this incentive scheme makes a difference between a failed Ripple transaction and a success? Except for this incentive scheme, the Ripple transactions themselves are handled out of band - in particular, not on a blockchain.

Mike Hearn's proposal:
   This is about implementing Ripple in an alternate blockchain. But it seems to require that each transaction is committed separately. Not only must each party respond online, including the intermediaries, but there is also no guard against a partially committed Ripple.


Open question:
    Can we use a blockchain to implement Ripple with the following desirable qualities?
     - Once a line of credit is extended, it can be exercised (spent) without further intervention from the creditor. (Intervention from the creditor may still occur, though, e.g. to revoke the line of credit)
     - Atomic commits: Multiple transactions (from Alice to Bob1, Bob1 to Bob2, Bob2 to Carol) should be processed in a single transaction update, without any escrow period.

[socrates1024]

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

[ben-abuya]

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.

Thanks for the great post! It's really cool to see computer science theory applied to social questions, such as what would happen on a ripple network if somebody far removed screwed up. Trust systems are a huge factor in bringing about a more p2p economy, and ripple is one really interesting way to do supply it.

[jimbobway]

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.

[cjp]

and specifically

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

That looks almost like what we need: the main difference is that a Bitcoin-based Ripple, as I described it, would work best if every connection is bidirectional (money can flow in both directions): that way, the connections can be used longer without a need to correct imbalances with regular Bitcoin transactions.

For instance: imagine you have Ripple contact with your employer and your landlord. Both are very asymmetrical: you only receive salary from your employer, and you only pay rent to your landlord. If both contacts were unidirectional, you'd need a regular Bitcoin transaction every now and then to transfer money from your employer contact to your landlord contact. With bidirectional contacts you can fix it without regular Bitcoin transactions: just make a Ripple transaction to yourself, using your employer contact on the payer side and your landlord contact on the payee side.

Do you think sequence numbers and lock times can be used for bidirectional payments (balance can change in both directions)?

Another requirement for completely trust-free neighbor contacts is that the actual Ripple commit/rollback conditions should determine the validity of the updated "balance transaction". Unfortunately, I made these conditions so complicated that I don't know whether they can be described in a Bitcoin script.

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.

Are you aware that my proposal uses routing tables? The routing tables don't include all nodes: instead they only include nodes that wish to act as "meeting points". I can imagine that a typical routing table will be a matrix of "meeting point"/"interface" combinations, with each entry in the matrix saying things like successful/failed ratio for last 100 attempts, average hop count, expected maximum transaction size for paying and receiving, and so on. Routing tables will be updated based on routing experience, and possibly by exchanging information with neighbors. And, of course, if neighboring nodes are on the same host, the host is internally capable of optimizing routing behavior.

Not all meeting points will be known to all nodes, especially if storage space is limited and the least popular ones have to be removed from the routing tables. I think "blind routing" (where you have no idea what direction is the best) is a fall-back method for the case of unknown meeting points. But most people will use well-known meeting points anyway, so this will only be a small part of the traffic.

So, can you explain to me why the routing algorithms of the Internet can not work on this network if it has a global scale (say 10 billion nodes)?

[muyuu]

This made a solid talk today in the conference.

[cjp]

I've created an update of my paper:

ripple_bitcoin_draft_2.pdf

In the update there are several additions; the largest one is probably an analysis of the scalability of different payment systems.

Another thing I added (section 4.3) is some thoughts on how interoperability between different Ripple concepts might be achieved. This gave me the confidence that I can start experimenting with my own code in the short term, without having to worry too much about interoperability: if I do things the right way, interoperability can be added later as a feature.

I know there is a lot of Ripple activity going on right now; I don't know whether all of it is good. I know my concept is how I want it; I hope others in this community will also prefer my concept. I think my concept is the most Bitcoin-like of all Ripple concepts I've seen: you hardly need to trust anyone, and unlike most Ripple systems, this one is not based on debt. That doesn't mean all other concepts are bad: for instance, this concept of using Ripple as a decentralized currency exchange solves an entirely different problem (thereby being useful in its own way), and AFAICS working with "fiat" currency is not possible without some form of trust or even some form of debt.

For the future, I have the following plans:

• Find out what important remaining design decisions need to be made before coding can start, and do some research to make good decisions on these issues
• Choose a software license (I tend to agree with the FSF philosophy and use the GPL; is it appropriate here?)
• Choose a catchy project name ("Ripple" is already taken, at least unofficially)
• Choose a programming language (currently I think I'll use C++. Fast, easy to make cross-platform and allows for future integration with Bitcoin client code)
  

[cjp]

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  .

[cjp]

Is it a problem that I keep replying to myself? I'm doing this because I have some new things to share with you.

The name
I'm currently using the working name "Amiko pay". Amiko is esperanto for "friend", and I thought it would be sort of appropriate for a network where participants sort of "pay for each other". Besides, I wanted to get rid of the "Ripple" name: it could create a trademark conflict with that other Ripple, and I don't like some of the developments in Ripple. Amiko pay will be more in the spirit of Bitcoin.

The code
I've started coding. You can soon expect a new project to appear in GitHub, but don't expect much of it yet. By keeping the first version to an absolute minimum, I hope to release a first "functional, but very experimental" version somewhere in March, or else in April. I'll make a separate thread about the actual coding progress if you'd like to be informed; this thread can stay focused on the conceptual design.

A problem
I discovered a problem, and I hope you can help me with it: as soon as I have a first version, I plan to set up a server with my software, to act as the first node of the network. Since Amiko links are relatively trust-free, my plan was to allow everyone to link with my server, as long as they bring their own bitcoins to set up the link. The idea was:

• Someone wants to join the network
• He sets up his own Amiko node, and links it with my Amiko node
• He adds some of his own bitcoins to the "shared property" Bitcoin account of the link. Initially, these would all be assigned to him
• He then spends some of his bitcoins through the Amiko network, through our link. This would transfer some percentage of the shared account to me

This seems to work, as long as spending is concerned. But you can't spend unless someone else receives, so it must also be possible for people to receive. And this is a problem: if the initial network has a star-topology around my node, and everybody starts with owning 100% of their link's shared account, then nobody can receive: you can't have more than 100%.

An initial "ownership percentage" of 50% on each link sounds better, since it allows for spending and receiving equal amounts. However, to initialize a link at 50%, I would have to put an equal number of bitcoins into the link as the other person. Since I'm only willing to (and capable of) using a limited number of bitcoins for this purpose, I can only invite a limited number of people to link with my node. This seriously limit initial growth of the network.

This problem seems to be caused by my extremely rigid "no debts, no IOUs, no fractional reserve" design: the original Ripple would probably not have this problem. Can you help me solve it?

BTW instead of a problem, maybe it is a feature? After all, it would make it extremely hard to centralize the network: in a star-shaped network with "50%" links, the center node would have to own half of the money in the network.

[TierNolan]

This problem seems to be caused by my extremely rigid "no debts, no IOUs, no fractional reserve" design: the original Ripple would probably not have this problem. Can you help me solve it?

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

[cjp]

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

No, it's not about trust: the trust mainly comes from using reliable software, and not from dealing with reliable people. So, my preparedness of putting my own funds in this is not limited by my trust in those who link with me. Instead, in the beginning, it will be limited by my trust in my own software(*), and later it will be limited by how many bitcoins I actually have.

Maybe a diagram will explain it a bit better:

Figure 1 shows how the system is supposed to work. The circles are nodes, the rectangles are (shared) Bitcoin accounts, and the colors indicate which fraction of the shared account is property of which node. In figure 1, a payment is performed from node 1 to node 3, through node 2. Notice how the fractions are adjusted because of the payment - this happens off-blockchain, but the nodes digitally sign statements that prove the adjustment. The core of the security is that the shared Bitcoin account requires two signatures for withdrawing, so the two nodes have to agree about the fraction in order to withdraw.

Figure 2 shows how I intended to allow anyone to link with me. Here, "node 2" = my node, and "node 1" = anyone. The shared account's initial funding comes from node 1's private Bitcoin account. After setting up the link, node 1 is ready to spend Bitcoins, but not yet to receive Bitcoins.

Figure 3 shows the problem: if all people set up links like that to me (node 1), nobody can receive, so effectively, nobody can send either. In order to prevent this "deadlock", I could add funds to all links (so each link in the figure would have some white fraction added to it). However, since my funds are limited, that would be a very small amount per link, if the number of links is large. For instance, if all people (including me) are initially prepared to put 100BTC in a link, and there are 100 people who link with me, then, while each person adds 100BTC to his own link, I can only add 1BTC to each link.

(*) My trust in my own software will have to increase over time, of course: how else could other people trust it? But I tend to be very careful with new concepts, and I first want to "see it work", even if it's my own creation.

[TierNolan]

No, it's not about trust: the trust mainly comes from using reliable software, and not from dealing with reliable people.

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.