đź“… 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
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-07 23:08:59
in reply to nevent1q…kl9e
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 23:08:59Event JSON
{
"id": "ae1e583536e5a7a09f80a4e1db559006c073f60f61941d8760aea829d2b4eaca",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686179339,
"kind": 1,
"tags": [
[
"e",
"670a187cea23e6528a4e432133cd6920267d3224856b28c52f4a16f7339a65e8",
"",
"root"
],
[
"e",
"9492674e72ec23c981248f41b128e9185ed7250e7de69af09dbac10f8af1792a",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2022-05-10\n📝 Original message:Good morning Billy,\n\n\n\u003e 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. \n\u003e\n\u003e To summarize my below email, the two techniques I can think for solving this problem are:\n\u003e\n\u003e 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.\n\nIs this not just basically channel factories?\n\nTo reduce the disruption if any one pool participant is down, have each sub-pool have only 2 participants each.\nMore 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.\nThis makes any arbitrary sub-pool more likely to be usable.\n\nBut a 2-participant pool is a channel.\nSo a large multiparticipant pool with sub-pools is just a channel factory for a bunch of channels.\n\nI like this idea because it has good tradeoffs, so channel factories ho.\n\nRegards,\nZmnSCPxj",
"sig": "36d78e0f908e3ede5777f24027ef0feeaff0c663a1ec5242bb5864f0b5d44c79fc29e16f2fa41d2606f9a8aeb8177c88c8821a744a417522e4db2dad47a38e99"
}