@Antoine
> it's also hard to predict in advance the liquidity needs of the sub-pools.
Definitely. Better than not being able to use the pool at all when someone's offline tho.
> this fan-out transaction could interfere with the confirmation of the simple withdraw transactions
> So there is an open question about the "honest" usage of the sub-pool states themselves.
I don't follow this one. How would it interfere? How would it call into question the "honesty" of the sub-pools? Why would honesty matter? I would assume they can all be structured trustlessly.
> one could envision an accumulator committing directly to balances too
Are you suggesting that there would be some kind of opcode that operates on this accumulator to shift around balances of some participants without disturbing others? Sounds reasonable.
> I think the challenge is to find a compact accumulator with those properties.
The Merkle Sum Trees like are used in Taro sound like they could probably be useful for that.
> It's more likely a lot of them will delegate this operation to third-party providers, with the known reductions in terms of trust-minimizations.
There is of course that limitation. But a third party empowered only to keep the pool functioning is much better than one given the ability to spend on your behalf without your confirmation. This would be a big improvement despite there still being minor privacy downsides.
> Hmmm, how could you prevent the always-online service from using the receiving-key in "spending" mode if the balance stacked there becomes relevant ?
You mean if your balance in the pool is 1000 sats and the service facilitates receiving 100 sats, that service could then steal those 100 sats? And you're asking how you could prevent that? Well first of all, if you're in a channel, not only does your service need to want to steal your funds, but your channel partner(s) must also sign for that as well - so they both must be malicious for these funds to be stolen. I can't see a way to prevent that, but at least this situation prevents them from stealing your whole 1100 sats, and can only steal 100 sats.
Interesting. I'm glad someone's been working on this kind of thing
> A malicious pool participant could still commit her off-chain balance in two partitions and send spends to the A&B hosting "receiving-keys" entities without them being aware of the conflict, in the lack of a reconciliation such as a publication space ?
Actually, I was envisioning that the always-online services holding a receive-only key would *all* be online. So all participants of the pool would have a representative, either one with a spending key or with just a receiving-key (which could also be used to simply sign pool state changes that don't negatively affect the balance of the user they represent). So there still would be agreement among all participants on pool state changes.
I kind of think if both techniques (sub-pools and limited-trust services) are used, it might be able to substantially increase the ability for a pool to operate effectively (ie substantially decrease the average downtime).
@ZmnSCPxj
> Is this not just basically channel factories?
It is.
> To reduce the disruption if any one pool participant is down, have each sub-pool have only 2 participants each.
Yes. But the benefit of the pool over just having individual 2 person channels is that you can change around the structure of the channels within the pool without doing on-chain transactions. As Antoine mentioned, it may often not be predictable which 2-person channels would be beneficial in the future. So you want the pool to be as responsive as possible to the changing needs of the pool.