From mats at blockchain.com Mon May 30 09:01:33 2016 From: mats at blockchain.com (Mats Jerratsch) Date: Mon, 30 May 2016 10:01:33 +0100 Subject: [Lightning-dev] Multi-party channels In-Reply-To: References: Message-ID: <498BC0FC-E8D1-4831-9412-BED3F9B20DB0@blockchain.com> 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) Cheers! Mats > -------------- 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: