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

Jérôme Legoupil jjlegoupil at gmail.com
Mon Mar 7 12:17:55 UTC 2016


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).



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.

       |2       ??
 1->2\         /1->2 ??
         \      /
    1->0\   /1->0

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

     A        B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160307/16727742/attachment.html>

More information about the Lightning-dev mailing list