📅 Original date posted:2018-11-07
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
>> However personally I do not really see the need to create multiple
> channels
>> to a single peer, or increase the capacity with a specific peer (via
> splice
>> or dual-funding). As Christian says in the other mail, this
> consideration,
>> is that it becomes less a network and more of some channels to specific
> big
>> businesses you transact with regularly.
>
> I made no reference to any "big businesses", only the utility that arises
> when one has multiple channels to a given peer. Consider an easier example:
> given the max channel size, I can only ever send 0.16 or so BTC to that
> peer. If I have two channels, then I can send 0.32 and so on. Consider the
> case post AMP where we maintain the current limit of the number of in flight
> HTLCs. If AMP causes most HTLCs to generally be in flight within the
> network, then all of a sudden, this "queue" size (outstanding HTLCS in a
> commitment) becomes more scarce (assume a global MTU of say 100k sat for
> simplicity). This may then promote nodes to open additional channels to
> other nodes (1+) in order to accommodate the increased HTLC bandwidth load
> due to the sharded multi-path payments.
I think I see the issue now, thanks for explaining. However I get the
feeling that this is a rather roundabout way of increasing the
limitations that you negotiated with your peer (max HTLC in flight, max
channel capacity, ...), so wouldn't those same limits also apply across
all channels that you have with that peer? Isn't the real solution here
to lift those limitations?
> Independent on bolstering the bandwidth capabilities of your links to other
> nodes, you would still want to maintain a diverse set of channels for fault
> tolerance, path diversity, and redundancy reasons.
Absolutely agree, and it was probably my mistake for assuming that you
would go for the one peer only approach as a direct result of increasing
bandwidth to one peer.
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:52:12
in reply to nevent1q…lm64
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:52:12Event JSON
{
"id": "5909f020cda73a36f8007bc9cf4a160ae16d644b9b36748562a5b103d978a499",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315132,
"kind": 1,
"tags": [
[
"e",
"6249b5cbcd15e73033b86549ca3dd2a2a34ac342c0fc458a69709e8965065331",
"",
"root"
],
[
"e",
"35f294edd9082583f23f26c74e9f08e6e68bd3bf1557659a4dc218857d5dc2d3",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2018-11-07\n📝 Original message:\nOlaoluwa Osuntokun \u003claolu32 at gmail.com\u003e writes:\n\n\u003e\u003e However personally I do not really see the need to create multiple\n\u003e channels\n\u003e\u003e to a single peer, or increase the capacity with a specific peer (via\n\u003e splice\n\u003e\u003e or dual-funding). As Christian says in the other mail, this\n\u003e consideration,\n\u003e\u003e is that it becomes less a network and more of some channels to specific\n\u003e big\n\u003e\u003e businesses you transact with regularly.\n\u003e\n\u003e I made no reference to any \"big businesses\", only the utility that arises\n\u003e when one has multiple channels to a given peer. Consider an easier example:\n\u003e given the max channel size, I can only ever send 0.16 or so BTC to that\n\u003e peer. If I have two channels, then I can send 0.32 and so on. Consider the\n\u003e case post AMP where we maintain the current limit of the number of in flight\n\u003e HTLCs. If AMP causes most HTLCs to generally be in flight within the\n\u003e network, then all of a sudden, this \"queue\" size (outstanding HTLCS in a\n\u003e commitment) becomes more scarce (assume a global MTU of say 100k sat for\n\u003e simplicity). This may then promote nodes to open additional channels to\n\u003e other nodes (1+) in order to accommodate the increased HTLC bandwidth load\n\u003e due to the sharded multi-path payments.\n\nI think I see the issue now, thanks for explaining. However I get the\nfeeling that this is a rather roundabout way of increasing the\nlimitations that you negotiated with your peer (max HTLC in flight, max\nchannel capacity, ...), so wouldn't those same limits also apply across\nall channels that you have with that peer? Isn't the real solution here\nto lift those limitations?\n\n\u003e Independent on bolstering the bandwidth capabilities of your links to other\n\u003e nodes, you would still want to maintain a diverse set of channels for fault\n\u003e tolerance, path diversity, and redundancy reasons.\n\nAbsolutely agree, and it was probably my mistake for assuming that you\nwould go for the one peer only approach as a direct result of increasing\nbandwidth to one peer.",
"sig": "f79daff7309fe9e81ce305113a22954529855a7a4a620dc2674248bfe64319e22febbc193b087c69b080735233da9883af8ebfaafb80ec591bbc3516a8ce9b1e"
}