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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
