Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Antoine, Gleb, and list,

In some ways, CoinPool is really part of a swarm of ideas:

* CoinPool
* Multiparticipant (N > 2) channels
* Channel factories
* Nodelets

What CoinPool and multiparticipant channels buy us is better flexibility with forwarding.
For example, if we compare a multiparty channel to a channel factory, suppose there exists three entities A, B, and C in the multiparty construction.

In a channel factory, each entity has to decide how much of its liquidity to tie up in a channel with a specific other peer in the multiparty construction.
This limits the practical payment forwarding when integrated into the Lightning Network.

In a CoinPool, any of the entities can forward to any of the other entities, without tying their liquidity to a channel specifically with those entities.

However, in a CoinPool, once any of the entities goes offline, the entire CoinPool can no longer update.
This is in contrast with channel factories, where, if entity C goes offline, the channel between A and B remains useable for forwarding.
In other words, channel factories degrade gracefully.

Further, we already have a decent solution for liquidity redistribution: JIT Routing by Rene Pickhardt.
Thus the liquidity issue with channel factories are somewhat mitigated (and if all participants are online, they also have the option of redistributing channel funds *inside* the factory as well, not just JIT routing), while gaining graceful degradation of the factory.


Another is that pathfinding algorithms work best if graph edges are edges and not in fact some kind of twisted multi-edge that connects more than two nodes together.

On the other hand, the participants of a CoinPool could create a "virtual node" that is a MuSig of their individual keys, and report that as the "real" node on LN gossip (each of them pretending to have a large channel with that virtual node), so that the rest of the network only sees edges that link two nodes (and existing pathfinding algos still work seamlessly, never realizing that this node is actually a virtual node that represents a CoinPool).
This is basically them creating a sort of Nodelet node, which other nodes cannot make channels to, and which uses channels with the Nodelet node as proxies for the CoinPool as a whole.


Regards,
ZmnSCPxj