[Lightning-dev] Multi-party channels

Mats Jerratsch mats at blockchain.com
Mon May 30 09:01:33 UTC 2016

Thats a cool idea! Instead of directed 1-to-1 payment channels, it would rather look like a cloud with multiple parties connected.

Apart from the (*huge*) added complexity and engineering work to make that happen, I see another problem with it though.

In case a participant cheats and broadcasts an old channel transaction - how do you determine the correct payout to the other participants?

Say there are 5 parties, each contributing 1 BTC.
Now after numerous payments, we end up in a state where Alice gets 4 BTC and B-E get 0.25 each. If one of the party now broadcasts an old transaction which held the initial state, how could you possibly make the blockchain cognitive to the correct payout? And what would be a correct payout to begin with?

Is it:

A: 4.0625
B: 0.3125
C: 0.3125
D: 0.3125
E: nothing (cheated)

so splitting up the balance of the cheating party equally, or is it more correct to split it proportionally?

The only way how I see this working right now is returning back to the schema of decreasing nLocktime with each update. It would make broadcasting old states impossible, as the current state has a lower nLocktime. It also means returning to very limited lifetime per channel though (you talked about timeout, is that what you meant?). With so many parties involved, it would lead to drastically increased on-chain activity (or very high refund timeouts where you can’t access your money).

It seems like you have it all thought out already, can you go into a bit more detail on your proposal? :)
I’m also interested in how exactly you would make it work, with only needing the spending party to resign the transaction. (which I cannot think of how to work out combined with the nLocktime-approach)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160530/f8dd3cc6/attachment.sig>

More information about the Lightning-dev mailing list