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

[cjp]

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

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.

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.

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.

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.

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

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.

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 

[1713585406]

1713585406

[1713585406]

1713585406

[1713585406]

1713585406

[1713585406]

1713585406

[khal]

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)

[cjp]

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 ?

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

[cjp]

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

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.

[solex]

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.

[cjp]

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.

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.

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.

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.

[misterbigg]

You don't need to make payment links with your friends;

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

...we're not relying on community/social credit. We're promoting Ripple as a payment system based on gateways. The social credit system will always be there should people be ready to use it.

And

I think it's reasonable to only make "business-related" links...

Also confirmed by the Nouveau Ripple architects:

...the path will almost always be either:

Payer -> Gateway -> Recipient

or

Payer -> Payer's Gateway -> Middle -> Recipient's Gateway -> Recipient

[cjp]

Now that I've found an unresolved problem with blueadept's concept (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:

Code:

(signature_is_given(payee_address) and hash_inverse_is_known(minblock, maxblock, hash))
 or
(signature_is_given(payer_address) and not hash_inverse_is_known(minblock, maxblock, hash))

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

[jtimon]

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

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.

[greBit]

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?

[cjp]

Is anyone still working on this?

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:

Code:

payee->payer: description, amount, hash, {meetingpoint, ...}
payer->payee: OK(hash, meetingpoint)
payer -> node 1: makeRoute(meetingpoint, amount, hash)
  link: state A
node 1 -> node 2: makeRoute(meetingpoint, amount, hash)
node 2 -> node 1: routeFailed(hash)
node 1 -> node 3: makeRoute(meetingpoint, amount, hash)
etc.
node N -> meetingpoint: makeRoute(meetingpoint, amount, hash)
meetingpoint -> node N: haveRoute(hash)
etc.
node 1 -> payer: haveRoute(hash)
  link: state B
(same protocol from payee to meetingpoint, with -1*amount)
payer -> payee: haveRoute(hash)
payee -> payer: haveRoute(hash)
payer -> node 1: lock(hash)
  link: state C
etc. to meetingpoint
etc. from meetingpoint to payee
payee -> payer: commit(token)
payer -> node 1: commit(token)
  link: state D
etc. to meetingpoint
etc. from meetingpoint to payee
payee -> payer: OK

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.

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?

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.

[cjp]

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.

[Sukrim]

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.

[cjp]

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?

[cjp]

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

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:

Code:

(signature_is_given(payee_address) and hash_inverse_is_known(minblock, maxblock, hash))
 or
(signature_is_given(payer_address) and not hash_inverse_is_known(minblock, maxblock, hash))

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

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.