From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy
Date: Tue, 16 Jun 2020 05:23:01 +0000 [thread overview]
Message-ID: <_VqB84inr1oM8O9n4r1BZ_t7BPRFaJQ3ifZqnsLwFKNlQAKtPdwUFK825Wja0PTyllzLERlmiWWMLSiamYR83d7MXH3ERCON-u-IkH5R5XA=@protonmail.com> (raw)
In-Reply-To: <7BPgx65Eh5HE5wLIqeG9G-bdsxxkDJJIzcyOJvS6_FIxXfA10sbFe5dfwQDNiEOExZ9Y72lHq88lKzcBRIFnYGFY5I2vwk6Dg7BcCMjmS2Y=@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
prev parent reply other threads:[~2020-06-16 5:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 8:53 Antoine Riard
2020-06-11 17:21 ` Jeremy
2020-06-12 23:45 ` Antoine Riard
2020-06-12 8:39 ` ZmnSCPxj
2020-06-13 0:28 ` Antoine Riard
2020-06-13 0:45 ` ZmnSCPxj
2020-06-13 1:20 ` ZmnSCPxj
2020-06-16 5:23 ` ZmnSCPxj [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='_VqB84inr1oM8O9n4r1BZ_t7BPRFaJQ3ifZqnsLwFKNlQAKtPdwUFK825Wja0PTyllzLERlmiWWMLSiamYR83d7MXH3ERCON-u-IkH5R5XA=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox