Emulation of the Lightning network by using partially trusted escrow services

[cjp]

Emulation of Hash-Time-Locked Contracts of the Lightning network by a trusted, but publically auditable escrow service
http://cornwarecjp.github.io/amiko-pay/doc/lightning_emulation.pdf

The Lightning network is a design for a decentralized, scalable network that allows for fast, cheap Bitcoin transactions without requiring trusted third parties. However, it requires the presence of new functionality in Bitcoin: without this new functionality, the Lightning network can not exist. So, in order to make the Lightning network a reality, the Bitcoin community must be convinced to accept this new functionality. While none of this new functionality is known to have any controversial characteristics, some of it has, so far, no use case outside the Lightning network.

Since any new functionality makes Bitcoin more complex, and more complex systems have more places where vulnerabilities can exist, the Bitcoin community might be reluctant to accept new functionality, unless convincing evidence is provided about the value of the new functionality. However, so far, the Lightning network only exists on paper, and has not been demonstrated to be useful in real-life conditions. This creates a catch-22 situation: in order to convince the Bitcoin community, we would like to make a working implementation of the Lightning network, but in order to do that, we need to convince the Bitcoin community to include the required functionality.

There are a couple of ways to escape this catch-22 situation:

• The Bitcoin community might accept the required functionality, even without a working Lightning network.
• It is possible to demonstrate the Lightning network on an alt-coin (possibly one specifically designed for this purpose), or on a side-chain, once side-chains are realized.
• It might be possible to emulate the missing functionality, with some loss of desirable properties, using only the already existing functionality of Bitcoin. This would allow Bitcoin users to become familiar with Lightning-like technology, while simultaneously increasing the pressure to "fix" the loss of desirable properties by including the missing functionality in Bitcoin.

This paper describes a design that follows the third approach. The "no trusted third parties" requirement is relaxed, by introducing a partially trusted escrow party, which can be audited by arbitrary third parties. The design is such that, after the missing functionality is introduced to Bitcoin, the migration to a full- featured Lightning network can happen gradually: pairs of neighboring nodes are free to choose when they upgrade their link to a real Lightning link, and during the migration period, transactions can be routed through both old-style and new-style channels (in any order).

I'm thinking of implementing this in Amiko Pay.

[Mashuri]

Nicely done.  I understand the basics of what you're proposing but will need to dedicate more time to fully grasp it.

[Mashuri]

I noticed in all your examples that the emulated HTLC is solely between Alice and Bob (with an escrow to help facilitate.).  Can this system work with passing the emulated HTLC multiple hops, settling between people not in a direct channel with each other?  To me, that is a very distinguishing feature of HTLC's.

[cjp]

I noticed in all your examples that the emulated HTLC is solely between Alice and Bob (with an escrow to help facilitate.).  Can this system work with passing the emulated HTLC multiple hops, settling between people not in a direct channel with each other?  To me, that is a very distinguishing feature of HTLC's.

You are right that it is a very distinguishing feature of the Lightning Network to allow payments between people who do not share a direct link. The Lightning Network uses HTLCs as building blocks in a larger system that accomplishes this.

The answer to your question is: yes!

These emulated HTLCs can be used as building blocks in exactly the same way as Lightning's HTLCs. In fact, they can be mixed: in one and the same network, some links might use emulated HTLCs and others might use true Lightning HTLCs, and payments can be freely routed between them. In a way, this is similar to how some links in the Internet use Ethernet, some use PPP or something else, and Internet Protocol traffic can be freely routed between them.

In essence, all a HTLC has to accomplish is that, if a payment token is given before a time-out passes, funds go to one side, and if the time-out passes before the token is given, funds go to the other side. Then, HTLCs on different links can be chained together, by requiring the same payment token on each link, and using an increasing time-out when going from payee-side to payer-side. This is described in the Lightning paper.

Requirements for inter-operability between links seem to be very low. The same hashing algorithm has to be used on all links. The same address space has to be used for routing, but even cross-address-space routing might be enabled by gateway services(*). In fact, now that I think of it, you don't even need to be on the same block chain: this might enable trust-free, de-centralized exchange between different crypto-currencies. Trust-free exchange with fiat currencies is more difficult (read: impossible), since fiat currency is not bound to cryptographic rules. However, "colored coins" which represent fiat currency can be moved in this way, and even exchanged against non-colored coins. I already described that in a different thread.

(*) This is similar to how you can use IPv6 even when your ISP doesn't provide it, by tunneling your IPv6 traffic over IPv4 to a gateway service that connects you to the IPv6 Internet. Analogies with the Internet seem to be everywhere.

[cjp]

I'm now implementing this in Amiko Pay. In the implementation, I made a minor change to the concept:

To reduce coin fragmentation, I've put the funds of all locked transactions of a channel into a single output. In case of disagreement, the escrow service calculates how much of the locked amount is sent to which party. To enable the escrow service to do this, the amount of BTC in a microtransaction will be added to its TCD.

The down-side is that only a single escrow service can be used at a time for a micro-transaction channel; this is not considered to be a problem, since both sides have to agree to the choice of escrow service anyway. It is possible to switch to a different escrow service without closing the channel, if both sides agree to the choice of the new escrow service. In case they can not come to an agreement, then it's just a matter of settling the on-going transactions and closing the channel.

Note that this reduction of coin fragmentation is no longer possible once real Ligthning-style HTLCs are used. Also note that this coin fragmentation only really occurs in case of non-cooperating (mis-behaving) neighbors: cooperating neighbors will always settle their micro-transactions.

My major concern is that coin fragmentation leads to a large withdraw transaction and high fees; if the fee becomes high w.r.t. micro-transaction amounts, this could change the incentive-structure.

[Mashuri]

OP_CHECKSIGDATAVERIFY seems like a useful op-code for bitcoin.  Has this, or something similar, been brought to the attention of the developers before?

As you pointed out, this system can work with E being the only link between parties (a main hub) and escrowing HTLC-style contracts between them.  What I'm specifically interested in seeing illustrated, is a hypothetical scenario where E is a BTC-denominated derivatives exchange escrowing contracts between users with payment channels only directly connected to E.  Furthermore, W's distribution would need to be determined by a live data feed.  Do you think something like that is workable?

[cjp]

OP_CHECKSIGDATAVERIFY seems like a useful op-code for bitcoin.  Has this, or something similar, been brought to the attention of the developers before?

Not that I am aware of.

As you pointed out, this system can work with E being the only link between parties (a main hub) and escrowing HTLC-style contracts between them.

E (the escrow service) is not really a hub: as long as parties can settle their conflicts without involvement of E, E is not involved in any of the transactions (this is a major advantage in terms of privacy and liberty). Also, there is no inherent, architectural reason why escrow servicing should be centralized to a single entity: in theory, every channel in the network can use a different escrow service. However, in practice, due to the difficulty of reputation building, I'd expect some kind of centralization to occur here, just like Bitcoin exchanges today are, to some degree, centralized entities.

What I'm specifically interested in seeing illustrated, is a hypothetical scenario where E is a BTC-denominated derivatives exchange escrowing contracts between users with payment channels only directly connected to E.

If you have a direct payment channel to E and E is also the escrow service of that payment channel, then E has two out of three private keys, which is sufficient to unlock any locked micro-transaction funds, so this situation is really sensitive to abuse by E. Note that this situation can also occur by a sybil attack, or by conspiracy between E and either A or B.

In the event that E abuses such a situation, though, it is still possible for the victim to publish cryptographic proof of the abuse. This would destroy E's reputation, so hopefully that will deter E from performing the abuse in the first place. This would only work though, if E's reputation is really worth anything, e.g. if E is a large business that profits from having lots of other customers.

Furthermore, W's distribution would need to be determined by a live data feed.  Do you think something like that is workable?

Why would W's distribution need to be determined by a live data feed? Maybe you need to clarify your concept. In my concept, the non-final versions of W are only exchanged between neighbors, and in case of a conflict, to the escrow service, and in case of escrow service misbehavior, to the public. The final version of W is sent to the public (on the block chain). Publishing to other parties wouldn't hurt the integrity of the system, but it would be a loss of privacy.

I do think though that, for the report of proof-of-(abuse by an escrow service), there should be a P2P exchange between users of that escrow service. It is essential, of course, that there should be no way for the escrow service itself to control this P2P network: it has a large interest in censoring such a network.