Good morning rusty, If we are going to switch to a new gossip version, should we prepare now for published channels that are backed by channel factories?
Instead of a UTXO serving as a bond to allow advertisement of a *single* channel, allow it to advertise *multiple* channels. This does not require us to flesh out the details of channel factories in the gossip protocol, especially post-Taproot --- we could simply require that a simple BIP-340 signature of the gossip message attesting to multiple channels is enough, and the details of the channel factories can be left to later protocol updates. The reason for this is that for a set of N published nodes, there is an incentive to make as many channels as possible between pairs of nodes. We expect that for N published nodes, all (N * (N - 1)) / 2 possible channels will be created, as that maximizes the expected fee return of the N published nodes. Without the ability to gossip channel factories, channel factories can only be used for unpublished channels. Due to not being available for routing, given an "LSP" and N clients, there is no incentive for the N clients to make direct channels to each other. (In particular, one of the reasons given for unpublished channels is that the clients of an LSP may not have high onlineness, thus an unpublished channel would really only exist between a public LSP and a non-published client of that LSP.) This means that for N clients we expect only N channels backed by the channel factory (and thus by the UTXO). It seems to me to be a good idea to have as much of the public network backed by fewer UTXOs, as the published network has far more channels for every N participants. (as well, supporting channel factories for the public graph does not preclude the unpublished graph from using channel factories, so even if the unpublished graph turns out to be much larger than the published graph, reducing the UTXO set of the published graph does not prevent reducing the UTXO set of the unpublished graph anyway.) Against this, we should note that it makes stuffing the public graph cheaper (a single UTXO can now justify the addition of multiple edges on the public routing graph), which translates to making it easier to increase the complexity of the public graph and thus increase the cost of pathfinding. Thoughts? Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
