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