As pointed out on #4837, MPP and max_htlc_dust_exposure_msat have a potential to collide and result in an MPP timeout/failure, depending on the routes that are being used.
c-lightning's default for max_htlc_dust_exposure_msat is 50k sats; if you attempt to send a 50k sat payment in parts that are considered dusty and those parts are all routed through the same c-lightning channel in the middle, then the payment will fail since the middle link wasn't able to accept them as htlcs.
I'm not sure what the right solution is here. The dust_exposure_msat is settable by the individual node, so we don't know exactly how much dust they'll accept. We also don't know what other htlcs are occupying that limit at the time of sending.
Further, what's considered dusty is variable, so high fee regimes will most likely result in MPP payment failures increasing.
Here's a few suggestions on how to deal with this on the MPP split side:
- Vary the size of the MPP payment according to the current feerate regime,
- Correlated, where possible make all MPP splits bigger than what's currently considered 'dusty'
As pointed out on #4837, MPP and
max_htlc_dust_exposure_msathave a potential to collide and result in an MPP timeout/failure, depending on the routes that are being used.c-lightning's default for
max_htlc_dust_exposure_msatis 50k sats; if you attempt to send a 50k sat payment in parts that are considered dusty and those parts are all routed through the same c-lightning channel in the middle, then the payment will fail since the middle link wasn't able to accept them as htlcs.I'm not sure what the right solution is here. The
dust_exposure_msatis settable by the individual node, so we don't know exactly how much dust they'll accept. We also don't know what other htlcs are occupying that limit at the time of sending.Further, what's considered dusty is variable, so high fee regimes will most likely result in MPP payment failures increasing.
Here's a few suggestions on how to deal with this on the MPP split side: