Olaoluwa Osuntokun <laol...@gmail.com> writes: > Splicing isn't a substitute for allowing multiple channels. Multiple > channels allow nodes to: > > * create distinct channels with distinct acceptance policies. > * create a mix of public and non-advertised channels with a node. > * be able to send more than the (current) max HTLC amount > using various flavors of AMP. > * get past the (current) max channel size value > * allow a link to carry more HTLCs (due to the current super low max HTLC > values) given the additional HTLC pressure that > AMP may produce (alternative is a commitment fan out)
While these are all good points, I think they are equally well served if by creating channels to other peers. This has the added benefit of reducing the node's reliance on a single peer. In fact it seems we are currently encouraging users to have a small number of fat channels that are manually maintained (dual-funding, splicing, multiple channels per peer), rather than making the default to create a diverse set of channels that allow indirectly routed payments. Instead of obsessing about that one peer and hoping that that peer is online when we need it, we should make routed payments a first-class citizen. If we can route correctly and with confidence we can stop worrying about that one peer and our connectivity to it. On the other hand, if routing doesn't work, and people have to worry about that one channel that connects them directly to the destination, then we're not much of a network, but rather a set of disjoint channels. Ultimately users should stop caring about individual channels or peer relationships, and multipath routing gets us a long way there. I'd really like to have a wallet that'll just manage channels in the background and not expose those details to the users which just want to send and receive payments, and we can start that now by de-emphasizing the importance of the peer selection. Regards, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev