[Lightning-dev] Thoughts on JoinChannels, benefits for LN using Schnorr sig ?

Hi, I am throwing out a thought about multi-party channels (a payment channels that involve > 2 participants). I'm going to call them JoinChannels (I haven't found anything in the literature regarding these objects). I see significant benefits of JoinChannels over 2-2 payment channels for Lightning Network : - JoinChannels take less blockchain space : for example 3 parties linked together with 2-2 channels require 3 channels, that is to say 3 multisig(2/2) transactions on the blockchain to open, while a JoinChannel only takes 1 multisig(3/3). The space efficiency really kicks in with Schnorr sigs and the signature time is only 2 rounds (independent of the number of participants !). - JoinChannels enable bigger transfers of value threw LN (higher connectivy) : if Alice wants to transfer X to Bob threw LN, all of the intermediate 2-2channels (of the path found) need to all have at least X locked in the right direction. With JoinChannels, an intermediate LN node is more efficient because instead of spreading his funds in multiple 2-2 channels, he can put the sum of his funds in a JoinChannels and the threshold condition of a transfer to occur is consequently higher. I have a little example below. The downside, is that all the participants of a JoinChannel need to be online in order to participate in a LN transfer (which may become a problem if the payment needs to through multiple JoinChannels that contain hundreds or thousands of participants). Cheers, Jerome --- This little example shows that JoinChannels enable bigger transfers of value threw LN. In this configuration, Sender can't send "2" to Receiver because B doesn't have enough funds in AB channel. Receiver |1 | |2 ?? A1-------0B 1->2\ /1->2 ?? \ / 1->0\ /1->0 C |1->3 | |2->0 Sender If (A,B,C) had performed a (3/3) JoinChannel : Sender could have sent "2" to Receiver for a same value of funds locked in the previous example Receiver |1->3 | |2->0 A B 1->3\\\\////1->1 \\\/// \\// \/2->0 C |1->3 | |2->0 Sender -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160307/16727742/attachment.html>