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

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.

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

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?

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.

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.

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.

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

Now that I've found an unresolved problem with blueadept's concept (https://bitcointalksearch.org/topic/decentralized-networks-for-instant-off-chain-payments-152334), 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.

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


And


Also confirmed by the Nouveau Ripple architects:

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.

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.

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

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.

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

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)

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 

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.

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.

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

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.

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  .