David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-24 🗒️ Summary of this message: The author ...
📅 Original date posted:2023-08-24
🗒️ Summary of this message: The author responds to a proposal for Lightning multipeer payment channels, expressing concerns about safety and efficiency compared to existing designs.
📝 Original message:
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
🗒️ Summary of this message: The author responds to a proposal for Lightning multipeer payment channels, expressing concerns about safety and efficiency compared to existing designs.
📝 Original message:
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