From jjlegoupil at gmail.com  Mon Mar  7 12:17:55 2016
From: jjlegoupil at gmail.com (=?UTF-8?B?SsOpcsO0bWUgTGVnb3VwaWw=?=)
Date: Mon, 7 Mar 2016 13:17:55 +0100
Subject: [Lightning-dev] Thoughts on JoinChannels,
	benefits for LN using Schnorr sig ?
Message-ID: <CAFnMCffRfsro967JFZhShKXJynp96kPSeieS_79gz_KsdvCr=w@mail.gmail.com>

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>