Max HTLC limit setting
What about max_htlc_limit setting for Lightning channels? Here a summary of information and point of view from different specialists.
Setting a maximum htlc limit on a channel can limit the amount of outbound liquidity that can flow through it, based on the channel's outbound liquidity. This is beneficial because when someone attempts to forward a payment through your channel with insufficient liquidity, it results in payment failure at your node. Multiple payment failures can impact your node's reliability reputation on the network.
By setting max-htlc limits, channels are only considered when they have enough liquidity to handle the payment, reducing payment failures and enhancing the overall performance of the lightning network.
Notably, max-htlc settings do not limit incoming liquidity, which is positive. Incoming liquidity does not cause node failures and enables the replenishment of locally depleted channels without issues, regardless of low maximum htlcs.
Charge-Lnd can be used to adjust max-htlc limits on channels automatically. Looking in the public repository of the software we can see where this subject has been analyzed by accumulator.
Suggestion by accoumulator on charge-lnd
from charge-lnd/Accumulator
It would not really be a big problem if running charge-lnd once a day, but some people run it every 5 minutes.
Also, if you are careful with not running charge-lnd too often, the max HTLC limit could also limit the use of your channel if it refills, as it's out of date.
Still, it IS currently possible to limit your max-htlc, but you'll have to split it up in a few separate rules:
1: local_balance < 100_000 -> max-htlc = 50_000
2: local_balance < 1_000_000 -> max-htlc = 500_000
etc
So in summary, I understand the need to signal to the network that a channel is depleted in order to mitigate routing failures, but it should be done in a way that doesn't flood the network.
Using `htlc_maximum_msat` as a valve
from bitmex/Pickart
Some operators have been playing with the idea to signal via `htlc_maximum_msat` how much liquidity they may have available or left in the channel. For example on the gossip protocol it is notable that zerofeerouting has times where some of the channels have a very low `htlc_maximum_msat` value. This behavior effectively deactivates routing on the channel in the direction of the drain by closing the valve and allows the channel to undeplete before the valve is being opened again. While this seems to be a drastic measure for flow control the principle of utilizing this field as control valve is already in place.
Final idea
For a given drain on a channel, choosing an asymmetric pair of htlc_maximum_msat
can significantly reduce the expected payment failure rate of a channel. This flow control measure also tends to create more balanced channels. Even high drain channels that use htlc_maximum_msat
show liquidity distribution closer to the uniform distribution than those without. Network-wide adoption of this measure is expected to improve the overall reliability of the network.