Channels with LND nodes stuck disabled because non-negotiable fees. err=update_fee outside range about lightning HOT 8 OPEN

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!

from lightning.

Related: #6953

from lightning.

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.

from lightning.

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?

from lightning.

@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.

from lightning.

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.

from lightning.

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).

from lightning.

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.

from lightning.