Channels with LND nodes stuck disabled because non-negotiable fees. err=update_fee outside range

[JaviLib]

I own both LND and CLN node, but the issue I have is mainly with LND trying to renegotiate fees. LND failed to give a proper fee, and CLN is unable from then on to renegotiate the new fee after LND is finally giving a proper one. As a consecuence, both nodes get connected but inmedietly disconnected and therefore the channel is stuck disabled most of the time.

This is the error:

2024-04-22 22:19:29.296 [WRN] HSWC: ChannelLink(XXX:7): received warning message from peer: chan_id=YYY, err=update_fee 253 outside range 1990-2880830 (currently 77071)

Somebody suggested that changing ignore-fee-limits to true in CLN could help, but others report that doesn't help. You may follow the conversation on Telegram: https://t.me/lightningd/32098

Related LND bug: lightningnetwork/lnd#8675

Is there a problem with inappropriate communication between the two nodes?
I have 4 channels stuck, but others are having even more, even with pending htlc which is obviously not ideal.

[PsySc0rpi0n]

I think it's more that LND is not fully compying with specs and CLN is not willing to go that way. So problem is definitely on LND side!

[silenzara]

Related: #6953

[cryptoteun]

I've got a similar issue. I had a channel (with a LND node) with a pending HTLC. The channel was offline with the following error:
Peer transient failure in CHANNELD_NORMAL: channeld WARNING: Too much dust to update fee (Desired feerate update xxxxx)

Reconnecting to the node constantly resulting in the same error. Running CLN v23.08 and had --ignore-fee-limits set to true. Next to that I tried to set max-dust-htlc-exposure-msat to try to fix the issue, without result.

Finally the channel FC.

[Roasbeef]

I think it's more that LND is not fully compying with specs and CLN is not willing to go that way. So problem is definitely on LND side!

I don't detect any spec compliance issues based on the log above. The decision to reject a fee update or not is based on an individual node.

What stands out at me though is that lnd is proposing a rock bottom fee of 253 sat/kw.

@JavierRSobrino can you give some more details re the set up of your lnd node? Is it running with neutrino, or a full node backend? If it's neutrino, what are you setting for the feeurl value? If it's a full node, then are you constraining the default mempool size at all?

[ziggie1984]

@wtogami seems like CLN should soften the dust check as well when updating the feerate, in LND we only do the dust_exposure check when sending or forwarding and HTLC but not when updating the feerate which of course can increase the dust-exposure as well but there we don't have any control of failing HTLCs back because they are already locked-in.

[endothermicdev]

You can override a single channel with the setchannel rpc and the ignorefeelimits=true parameter. I wouldn't recommend it as anything more than a temporary fix - 253sats/kw will not even make it into a standard mempool. If the opening node doesn't want to propose a sane feerate, there's not much recourse:

A receiving node:
    if the update_fee is too low for timely processing, OR is unreasonably large:
        MUST send a warning and close the connection, or send an error and fail the channel.

[ziggie1984]

You can override a single channel with the setchannel rpc and the ignorefeelimits=true parameter. I wouldn't recommend it as anything more than a temporary fix - 253sats/kw will not even make it into a standard mempool. If the opening node doesn't want to propose a sane feerate, there's not much recourse:

Agree, though if you trust your peer I think it's safe to soften this limit for a short while because there was an edge case in the LND daemon where we would propose a feerate of the min_relay feerate in case bitcoind did not have enough data to have a reliable conf-target estimation. (This is fixed in 18.0).

[JaviLib]

I think it's more that LND is not fully compying with specs and CLN is not willing to go that way. So problem is definitely on LND side!

I don't detect any spec compliance issues based on the log above. The decision to reject a fee update or not is based on an individual node.

What stands out at me though is that lnd is proposing a rock bottom fee of 253 sat/kw.

@JavierRSobrino can you give some more details re the set up of your lnd node? Is it running with neutrino, or a full node backend? If it's neutrino, what are you setting for the feeurl value? If it's a full node, then are you constraining the default mempool size at all?

I'm using Neutrino right now, and I have tried these two feeurl:

feeurl=https://bitcoinchainfees.strike.me/v1/fee-estimates
#feeurl=https://nodes.lightning.computer/fees/v1/btc-fee-estimates.json

I suspect the problem may have appeared when my internet connection was bad for some reason, and the fee estimates could not have been retrived. But from that moment on, LND is unable to sucessfuly renegotiate fees with the other CLN nodes. I'm not sure which one of the two programs is the culprit.

Since that moment I have 4 channels with CLN nodes which are constantly trying to connect and disconnect every few minutes, but there is no success in renegotiating fees.