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