From dave at dtrt.org  Thu Aug 24 21:25:29 2023
From: dave at dtrt.org (David A. Harding)
Date: Thu, 24 Aug 2023 23:25:29 +0200
Subject: [Lightning-dev] Nucleus: Capital-efficient multipeer Lightning
 payment channels
In-Reply-To: <1a7c7373-5511-d5f4-4aa9-8c19c3c0303d@onionmail.org>
References: <1a7c7373-5511-d5f4-4aa9-8c19c3c0303d@onionmail.org>
Message-ID: <1a7beeccda2a78d635554d13bfa091d6@dtrt.org>

On 2023-08-20 16:25, Atomic Mr Nuclear wrote:
> Dear community,
> 
> In the attachment you will find a new proposal for Lightning multipeer
> payment channels

Hi,

Thanks for working on multiparty channel design.  Quoting from the
paper:

> in case some of the peers become unresponsive, the channel starts
> operating with partial state updates
> [...]
> outputs in the [sub-]graph can be double-spend by their owners with
> cooperation from the majority
> [...]
> this state is only temporary, since the channel security can be reset
> to the fully trustless level by excluding uncooperative peers from the
> channel.

I think it's worth mentioning two points:

1. That any construction dependent on an honest majority is not safe
    when that majority can consist of untrusted peers.  If Alice is in a
    multiparty channel consisting of random peers, she cannot safely
    accept payments in your construction without signatures from all
    other participants in the channel ("full state updates").

2. The exclusion of uncooperative peers requires getting confirmed three
    onchain transactions, one of which has one output for every original
    participant and one which has one input for every cooperative
    participant; that sounds like a lot of onchain data to me.  Until
    those transactions have confirmed to a sufficient depth, Alice cannot
    safely accept payments in a channel with uncooperative peers (where
    she does not trust a majority of all peers).  That sounds too
    expensive and too slow for an alternative to Lightning.

Given those two points, I don't think anyone desiring trustless payments
can use "partial state updates".   Without partial updates, your
proposal requires participants go onchain in an expensive way any time
even one participant becomes uncooperative, which feels to me to be
inferior to the existing designs for channel factories and multiparty
channels that you cite.

I would love to learn if I'm missing something and I appreciate the
obvious effort you put into your paper.  If you continue to innovate in
the field, I would highly encourage you to review the work posted to the
Lightning-Dev mailing list over the past year or so by John Law as I
feel you might find his own solutions for some of the same problems
inspiring (some links to his work are collected and summarized here[1]).

Thanks,

-Dave

[1] 
https://bitcoinops.org/en/newsletters/2023/03/29/#preventing-stranded-capital-with-multiparty-channels-and-channel-factories