Topic: Combining Bitcoin and the Ripple -> fast, scalable, decentralized and more - page 2. (Read 8959 times)

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)
  

This made a solid talk today in the conference.

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.


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

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.

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.

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

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.

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.

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.


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?

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?

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.

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.

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.

Mike Hearn also made this too.

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

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.