Bitcoin Forum

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 (http://www.ultimatestunts.nl/bitcoin/ripple_bitcoin_draft_1.pdf)

Draft 2 (added 17 jan 2013):
ripple_bitcoin_draft_2.pdf (http://www.ultimatestunts.nl/bitcoin/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.

Mike Hearn also made this too.

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

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.

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.

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.

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?

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?

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.

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.

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

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.

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.

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

This made a solid talk today in the conference.

I've created an update of my paper:

ripple_bitcoin_draft_2.pdf (http://www.ultimatestunts.nl/bitcoin/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)
  

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

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.

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

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:
http://www.ultimatestunts.nl/bitcoin/shared_accounts.png
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.

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.

True, that amount of trust still has to exist (and it has been described in the paper). You can reduce this risk by never owning 100% of the shared account: if the other party still owns some fraction, he has an interest in the link. You can make agreements with the neighboring party about this percentage.

I think this type of trust is still less than required for using regular Bitcoin services like exchanges or Bitcoin web shops. In those services, you typically fully send bitcoins first and then hope they don't disappear without delivering the service. You shouldn't do that with anonymous parties that don't have a solid reputation.

True, but that would also be limited by my own capital, unless I continually take my share from one link (e.g. the paying link) and put it in the receiving link.

Besides, this would involve a regular in-blockchain Bitcoin transaction. That would be slow (waiting for confirmations) and in the future I expect it to be expensive as well (I expect the capacity of the block chain to be too limited for global usage for all transactions, so there must be a relatively high price to using this scarce resource). But maybe this is a reasonable solution for "bootstrapping" the network: after all, right now regular Bitcoin transactions aren't that expensive yet. People need to be warned that their transaction will be as slow as a regular Bitcoin transaction.

When both nodes are up, and one node requests a withdrawal from the shared account that meets the previously agreed conditions, the other node should automatically sign the withdrawal transaction. Yes, this could be used to move funds from an inactive link (where those funds are not being used) to an active link (where those funds are more useful).

True: the protocol and the software allow for an arbitrary-shape network, and I will encourage people to form links with each other, and not just with me. But the initial shape of the network will be a star, at least until other people have set up their own nodes and advertise them to third parties.

I don't think links will be very valuable in the beginning, since in the beginning the network will be small and not very valuable. When the network goes "beta", I'll try to let some popular Bitcoin merchants join the network to add some extra value to it. I will add "transaction fee" functionality to the software, for the following reasons:

• Transaction fees from early transactions helps me fill new links with funds, hopefully increasing the rate at which transactions are possible.
• Transaction fees discourage people from linking with my node, instead linking with each other to avoid paying my fees. This will de-centralize the network.
• Transaction fees will encourage people to open up their own nodes for new links, so they can receive transaction fees themselves.
• Transaction fees will make me a bit richer  ;D

The amount of Bitcoins you put in shared link with a neighbor should be adjusted with your trust in this neighbor.
The more you trust it over time (after hundreds of tx exchanges), the more you can increase your shared account. This will limit the number of paralyzed coins and allow to connect to several nodes when arriving in the network.

I think the current problem of "deny of service" should be solved (and as you said, the nLocktime is not enough)

As said by TierNolan, new servers should not all connect to your node when arriving in the network.

Edit (i' read a bit more the paper :p) : One thing i don't understand is how the payment is performed between node 1 & 3 ?
How to be sure node 2 will "transmit" it to node 3 ?

So, a new question : what prevents a node to generate a lot of tx and asking for rollback ? (DoS)

It isn't shown in the diagram, but payer and payee also communicate directly with each other, so all parties involved in the transaction form a "ring". A transaction is only committed when all nodes in the ring sign it. The paper gives you all the details on how to make sure a transaction goes from "undecided" to "commit" or "rollback" in a limited amount of time, even in the case of communication failure or abuse, and how to make sure the commit decision is "universal" (either all links commit or all links rollback).

That form of DoS is limited by the limited capacity of their own link, similar how a communication DoS is limited by one's own bandwidth.

Ripple is a big unknown for most people, so is Bitcoin. Combining them together is like unknown². I don't see how this helps.

Ripple should be able to prove itself in the fiat domain first. In fact its usage should be growing fast with conventional currencies. Then it might be shown to complement Bitcoin.

This brings me to the reason why I can't see myself ever using Ripple: money destroys friendships.

If I need to borrow money, I want that separated from my social life. So I go to the bank and deal with them. If I fail to pay the loan back then it is my problem with my bank. It is dirty washing which I do not need flapping in the faces of my friends. With my friends (people I might theoretically trust with money) I play golf or go fishing. But as soon as money is actually changing hands in the relationship, it is not much fun anymore.

Ripple is probably a killer-app in India and its satellite countries on the subcontinent, as they have Grameen (micro) banking.
http://en.wikipedia.org/wiki/Grameen (http://en.wikipedia.org/wiki/Grameen).

In Western countries people want their financial affairs separate from their social life. I just can't see that changing.

It is true that this is a combination of two complicated concepts; I think we need some way for people to trust and accept the system without understanding all the details.

Ripple without Bitcoin is much less secure, since traditional currency is not "machine-verifiable" (you can not check with a computer program whether someone has a certain financial reserve). Bitcoin without Ripple is too slow for some applications (esp. POS transactions) and scales very badly.


You don't need to make payment links with your friends; in fact, because of the reasons mentioned by you, I think it's reasonable to only make "business-related" links (with traditional banks if they want to join the system, or with Bitcoin exchanges, or with some shop, with your employer & so on). You're free to choose. Having said that: I think that, between responsible friends, a "shared property" construction is less stressful than a "debt" construction.

I've seen multiple times that people respond to this thread without realizing that my concept works with "shared property" instead of "debt". On the other hand: I just realized that allowing for "debt" will solve the deadlock problem I described earlier. I think both concepts can easily be combined in the same software; the user should be able to configure per-link what is allowed and what is not allowed. The trade-off between the "flexible but unreliable" concept of debt and the "rigid but reliable" concept of shared property should be made by the user, not by the software designer.

Absolutely right, and this is confirmed by the principal architects of Nouveau Ripple:


And


Also confirmed by the Nouveau Ripple architects:

Now that I've found an unresolved problem with blueadept's concept (https://bitcointalk.org/index.php?topic=152334.0 (https://bitcointalk.org/index.php?topic=152334.0)), I'm thinking about going back to this concept.

The downside of this concept: it doesn't have the nLockTime "safety valve" for when your neighbor decides to leave you alone. So the only thing you have to protect you is to keep it in your neighbor's interest to stay honest. This is perfectly possible in this concept, but it doesn't protect you from e.g. your neighbor's stupidity.

I've been thinking: the reason why my concept can not be combined with the nLockTime safety mechanism is that the "commit conditions" of my concept are so complicated that they can not currently be implemented in a Bitcoin script. Interestingly, they are such that they can be evaluated by every future miner, so if the Bitcoin scripting language is extended, it becomes possible to make off-blockchain transactions completely safe.

To simplify things, I think we can switch from my "you need all participants' signatures for a commit" to blueadept's "you need a value which hashes to a certain value". Then, the part of a shared account that is "undecided" because of a transaction-in-progress should be redeemable under the following conditions:

"hash_inverse_is_known" should evaluate to true if and only if a scriptsig is given between "minblock" and "maxblock" which, when hashed (sha256), gives the value of "hash". Note that, obviously, this can only be evaluated after maxblock, so maxblock should be less than nLockTime.

Do you think people are interested enough in secure off-chain transactions to include this into the Bitcoin protocol?

PS. potential issue: this might conflict with block chain pruning. If you forget the spent transactions between minblock and maxblock, you can no longer evaluate hash_inverse_is_known.

Yes, I think so. Do you mean secure bitcoin off-chain transactions or off-chain IOUs transactions?

maaku and I are designing an extension of the protocol to allow issuance of arbitrary assets, ripple transactions and off-chain assets (integrating ripple hybrid transactions with both public and off-chain parts) using freicoin as the host chain. This could be used for bitcoin later.
Unlike Ripple, we support interest/demurrage bearing assets.
I don't think I understand your proposal, but we may have some synergies since what we're trying to achieve seems similar.
Still a little bit of a mess but you can take a look here:

https://docs.google.com/document/d/1nnul3oDO5z8sspWBKgTKKSjQ7dWoOqU4Pd8DILLmFN8

Feedback welcomed.

Is anyone still working on this?

Could a fork of Ripple be created where XRP is replaced with a less sinister crypto-currency such as Bitcoin? or are there big technical issues?

Yes I am! In fact, if I can find and secure the funding, I'm prepared to give up my job to work on this for a couple of years (going from prototype to production-level quality and features, and maybe some marketing).

For now, progress is stalled because my computer is broken and I'm being kept busy with other things. The following parts are implemented:
* Automatic connecting with peers, authentication of messages exchanged with peer
* Partial implementation of distance-vector routing

While my computer is being repaired, I've continued mentally designing the software. For the first prototype I'm going to remove routing altogether: the first prototype will simply try every possible route. This will scale very poorly with network size, but it will work reliably and it's simple to implement. Besides, routing can always be added later as an "optimization", so I consider it a valid trade-off, to allow the prototype to be finished ASAP.

I've also been thinking about the next steps in implementing this. I think the transaction sequence should be something like this:
State A: amount is reserved for this transaction with a small timeout
State B: amount is reserved for this transaction with a large timeout
State C: amount is locked for this transaction by updating the link's "Bitcoin transaction"
State D: amount is unlocked for receiving side by sending the token (and signature, depending on concept)

I'm not sure yet whether the "small timeout" vs. "large timeout" difference is necessary.


I'm not following in detail how Ripple is currently being implemented. What is this XRP thing? If I understand correctly, it's a pre-mined crypto-currency which is for some reason needed (needs to be destroyed?) to set up Ripple links. As far as I can see, we don't need something like that.

Links can be set up and destroyed at will, and if you use distance-vector routing there doesn't even need to be a global database of existing links. You need some sort of addressing scheme for the routing table entries (the meeting points); to avoid ICANN-like authorities, this can be a simple hash value. 160 bits should be sufficient for global uniqueness (otherwise Bitcoin is in trouble too). To avoid DoS attacks by route-table-spamming, a proof-of-work can be required for meeting points.

The recent news made me aware of transaction malleability, and I've been thinking about how it impacts this concept, and more generally the concept of micro-transaction channels and similar contracts.

In a microtransaction channel, you have a transaction T1, which locks the funds, and a transaction T2, which spends T1 and returns the funds to its owners (initially it returns all funds to the original owner). The general usage pattern is:
1. Make and sign T1
2. Make T2 and have it signed by both parties
3. Publish T1
4. [update T2 multiple times]
5. Publish T2

What if, during step 3, a modified version of T1 ends up in the block chain? The effect would be that T2 would no longer be valid, since it includes the hash of the original T1. Since spending of the modified T1 requires signatures of both parties, the other party (the one who did not make T1) can refuse to sign a new T2. He might benefit from this blockade by asking a "ransom" for the money, e.g. he could require 90% of the funds to be spent to himself and only 10% to the original owner.

I think the transaction malleability problem really needs to be solved in a reliable way, to make microtransaction channels (and similar concepts) possible for use between parties who don't trust each other.

As far as I understand it, over time transactions will become less and less malleable until only "canonical" transactions are considered valid.

This would however be a had fork in Bitcoin, so it might take quite a while until it is implemented/in effect. While clients and even "honest" miners might not create/relay/mine non-canonical transactions, they are currently valid, so to attack someone, you might need to mine yourself in that case (much harder than just modifyting a transaction on the go like currently). Still attackable though.

While implementing this concept, I got the feeling that something was missing concerning time-outs: (where) do you want time-outs, and how do you respond to time-outs? So I created this overview:

https://github.com/cornwarecjp/amiko-pay/blob/master/doc/payment%20sequence.ods?raw=true (https://github.com/cornwarecjp/amiko-pay/blob/master/doc/payment%20sequence.ods?raw=true)

The actual timing values don't really matter; they are a trade-off between

• making the time-out long enough to allow potentially inefficient routing over a large, busy, worldwide network
• making the time-out short enough so that transactions won't be stalled for too long (think: POS applications)

But first I wanted to be sure we won't get weird situations e.g. where people need to wait infinitely long for a non-responsive party.

What do you think?

So far, this has been the missing link in realizing a trust-free Ripple:

Would it be possible to implement this in a "side chain", once side chains are added to Bitcoin? There seems to be quite some support for side chains among core developers, and from what I've read about it, they seem to allow quite a lot of programmability. Even Ethereum is said to be implementable in a side chain! I still have to read the technical details though, but this could be really exciting.