Jérôme Legoupil [ARCHIVE] on Nostr: 📅 Original date posted:2016-03-07 📝 Original message: Hi, I am throwing out a ...

📅 Original date posted:2016-03-07
📝 Original message:
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>;