ZmnSCPxj [ARCHIVE] on Nostr: đź“… Original date posted:2022-05-10 đź“ť Original message:Good morning Billy, > Very ...
đź“… Original date posted:2022-05-10
đź“ť Original message:Good morning Billy,
> Very interesting exploration. I think you're right that there are issues with the kind of partitioning you're talking about. Lightning works because all participants sign all offchain states (barring data loss). If a participant can be excluded from needing to agree to a new state, there must be an additional mechanism to ensure the relevant state for that participant isn't changed to their detriment.Â
>
> To summarize my below email, the two techniques I can think for solving this problem are:
>
> A. Create sub-pools when the whole group is live that can be used by the sub- pool participants later without the whole group's involvement. The whole group is needed to change the whole group's state (eg close or open sub-pools), but sub-pool states don't need to involve the whole group.
Is this not just basically channel factories?
To reduce the disruption if any one pool participant is down, have each sub-pool have only 2 participants each.
More participants means that the probability that one of them is offline is higher, so you use the minimum number of participants in the sub-pool: 2.
This makes any arbitrary sub-pool more likely to be usable.
But a 2-participant pool is a channel.
So a large multiparticipant pool with sub-pools is just a channel factory for a bunch of channels.
I like this idea because it has good tradeoffs, so channel factories ho.
Regards,
ZmnSCPxj
đź“ť Original message:Good morning Billy,
> Very interesting exploration. I think you're right that there are issues with the kind of partitioning you're talking about. Lightning works because all participants sign all offchain states (barring data loss). If a participant can be excluded from needing to agree to a new state, there must be an additional mechanism to ensure the relevant state for that participant isn't changed to their detriment.Â
>
> To summarize my below email, the two techniques I can think for solving this problem are:
>
> A. Create sub-pools when the whole group is live that can be used by the sub- pool participants later without the whole group's involvement. The whole group is needed to change the whole group's state (eg close or open sub-pools), but sub-pool states don't need to involve the whole group.
Is this not just basically channel factories?
To reduce the disruption if any one pool participant is down, have each sub-pool have only 2 participants each.
More participants means that the probability that one of them is offline is higher, so you use the minimum number of participants in the sub-pool: 2.
This makes any arbitrary sub-pool more likely to be usable.
But a 2-participant pool is a channel.
So a large multiparticipant pool with sub-pools is just a channel factory for a bunch of channels.
I like this idea because it has good tradeoffs, so channel factories ho.
Regards,
ZmnSCPxj