Non-bidirection payment channels for lightning network

Question

I am trying to understand the technology behind LN and similar concepts.

As I understand it, LN is a network of bidirectional channels, which are created with some limited capacity, within which the channel can operate. So, we can have Alice putting 3 coins to the channel and Bob putting 20 coins to the channel and this 3:20 ratio can then change in time with each off-chain payment, until it eventually reach the point where Alice and Bob want to close the channel at some final balance ratio - say 13:10.

This bidirectional concept has some features (or disadvantages) of e.g. requirement to balance the channel (or create a new one) if payments in one direction are more common. Also each such channel connecting two parties needs two on-chain transactions.

Questions: Why do we use channels only between 2 parties? Would it not be possible to have a channel that is formed e.g. by 4 parties, e.g. Alice with 3 coins, Bob with 4 coins, Cecil with 5 coins and Daniel with 6 coins? It should allow Alice to send e.g. 2 coins to Bob, thus modifying the state of the channel from "A3:B4:C5:D6" to "A1:B6:C5:D6" etc.

If this was possible, we could have 2 on-chain transactions to interconnect 4 (or more) entities, so it seems it would be more effective than bidirectional approach. It also seems to me that keeping the channel balanced would be little bit easier than in case of bidirectional case.

Obviously there would be more communication needed for each off-chain transaction within the channel (all parties would probably have to be involved).

So, is there any fundamental problem with having more than 2 entities in one channel? Or is it just that the benefits of having them would not outweigh the additional complexity?

Answer 1

There's no fundamental reason why you couldn't use a non-bidirectional link. The onion routing protocol of lightning is ignorant of the channel between two nodes. Hypothetically, if two lightning nodes were right next to one another, you could have robotic arms pass pennies back and forth in lieu of a lightning channel.

That said, would a non-two-party lightning channel work, or would it let one channel participant defraud another?

Normal lightning works like this: before Alice and Bob create a channel, Alice signs Bob's refund transaction, and Bob signs Alice's refund transaction. Alice's refund transaction says:

Output 0: 1 BTC can be claimed by Alice, only after 48 hours, OR
                can be claimed by Bob, if Bob knows P, where hash(P) = x
Output 1: 1 BTC can be claimed by Bob

If Alice decides that she wants out of the channel, she publishes the above transaction, waits 48 hours, and claims her money. Now that we have a way to end the channel, Alice and Bob jointly pay into a transaction that can be spent by the refund transactions, or any transaction that Alice and Bob jointly sign.

That's great, but how do you move money? First, Alice and Bob create new refund transactions to reflect the new state of the channel. Then, Alice tells Bob P, the value above that hashes to x. If Alice tried to submit that transaction to the Bitcoin network now, Bob would reply by taking all of the money in the channel.

This is where we hit our first roadblock. If there are three parties with money in the channel, and Alice cheats, it's obviously unfair to Charlie for Bob to take all of the remaining money. How do we fix this?

If Alice uses her refund transaction, we drop into a two party version of the lightning protocol. We do this whether or not Alice cheats by using an old refund transaction. Alice's refund now looks like this:

Output 0: 0.33 BTC can be claimed by Alice, only after 48 hours, OR
                   can be claimed by Bob and Charlie, if they know P, where hash(P) = x
Output 1: 0.67 BTC can be claimed by Bob and Charlie

We're not done, though. When Alice uses her refund transaction, Charlie might be offline. (In fact, that might be why Alice is leaving the lightning channel.) Therefore, Bob and Charlie each need to create a sub-refund transaction before they fund the channel. Bob signs Charlie's transaction, and vice versa. Bob's transaction looks like this:

Output 0: 0.33 BTC can be claimed by Bob, only after 48 hours, OR
                   can be claimed by Charlie, if they know P, where hash(P) = x
Output 1: 0.34 BTC can be claimed by Charlie

The result is that if you have n people participating, you need n refund transactions, and n-1 sub-refund transactions, and n-2 sub-sub-refund transactions. This grows factorially, so if you have 10 participants, I estimate that you must sign and revoke about 3.6 million transactions for every channel update. This will cover every possible ordering of nodes leaving the channel.

If you're willing to trade off some security, you could have 5 lightning nodes create a 3-of-5 multisignature account, and only allow withdrawals from that account if 3 nodes agreed that the withdrawal was done by a node with enough balance. If you're interested in this, I suggest looking at federated peg.