Topic: Emulation of the Lightning network by using partially trusted escrow services (Read 1478 times)

Not that I am aware of.

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.

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.


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.

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?

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.

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.

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.

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

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

I'm thinking of implementing this in Amiko Pay.