📅 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
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:51:45
in reply to nevent1q…9ev7
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:51:45Event JSON
{
"id": "5ebd515592162f3ff15e9af880b73fbf084efe452886340538a8bbdfcb685367",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315105,
"kind": 1,
"tags": [
[
"e",
"d33837a10906296cdab5e5ff391835a12bd3f5d27bdac072961b20f094855a4d",
"",
"root"
],
[
"e",
"6fb97c028fae697ee8b0d8446edf1d78e7057fee025d0887db7492b51c39d52c",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2018-10-15\n📝 Original message:\nOlaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n\u003e Splicing isn't a substitute for allowing multiple channels. Multiple\n\u003e channels allow nodes to:\n\u003e\n\u003e * create distinct channels with distinct acceptance policies.\n\u003e * create a mix of public and non-advertised channels with a node.\n\u003e * be able to send more than the (current) max HTLC amount\n\u003e using various flavors of AMP.\n\u003e * get past the (current) max channel size value\n\u003e * allow a link to carry more HTLCs (due to the current super low max HTLC\n\u003e values) given the additional HTLC pressure that\n\u003e AMP may produce (alternative is a commitment fan out)\n\nWhile these are all good points, I think they are equally well served if\nby creating channels to other peers. This has the added benefit of\nreducing the node's reliance on a single peer. In fact it seems we are\ncurrently encouraging users to have a small number of fat channels that\nare manually maintained (dual-funding, splicing, multiple channels per\npeer), rather than making the default to create a diverse set of\nchannels that allow indirectly routed payments.\n\nInstead of obsessing about that one peer and hoping that that peer is\nonline when we need it, we should make routed payments a first-class\ncitizen. If we can route correctly and with confidence we can stop\nworrying about that one peer and our connectivity to it. On the other\nhand, if routing doesn't work, and people have to worry about that one\nchannel that connects them directly to the destination, then we're not\nmuch of a network, but rather a set of disjoint channels.\n\nUltimately users should stop caring about individual channels or peer\nrelationships, and multipath routing gets us a long way there. I'd\nreally like to have a wallet that'll just manage channels in the\nbackground and not expose those details to the users which just want to\nsend and receive payments, and we can start that now by de-emphasizing\nthe importance of the peer selection.\n\nRegards,\nChristian",
"sig": "6444480c6aceb4c509cd921f0ce258122691e9e096884585adb36d3212459e2936bdafe404dad0d0e759d6a3e612574790e0c9470c2a31cb83fada72c8faad7f"
}