Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-15 📝 Original message: Olaoluwa Osuntokun ...
📅 Original date posted:2018-10-15
📝 Original message:
Olaoluwa Osuntokun <laolu32 at 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
📝 Original message:
Olaoluwa Osuntokun <laolu32 at 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