lnd: [bug]: unable to retry coop close attempt with higher fee rate (between two nodes running v0.15.3)
Background
I tried to coop close a channel (lncli closechannel XXX 0 --sat_per_vbyte 1) which failed with [ERR] RPCS: [closechannel] unable to close ChannelPoint(xxx:0): unable to process close msg: latest fee proposal exceeds max fee: 0.00000602 BTC > 0.00000585 BTC. The channel appeared in lncli pendingchannels | jq .waiting_close_channels with an empty closing_tx.
Following attempts of coop closing the channel also failed:
unable to gracefully close channel while peer is offline (try force closing it instead): channel link not found
In my understanding, nodes running recent versions of lnd should be able to resume the close process.
The other node is running v0.15.3 with Thunderhub.
Note that I also have this issue with fixedfloat.com, although I don’t know which version this node is running.
Your environment
- version of
lnd: v0.15.3 with a few patches (Watchtower related & no more warnings as errors) - Linux server 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux
- bitcoind v23
Steps to reproduce
- attempt to coop close with fee suggestion too low for peer
- attempt to coop close with higher fee
Expected behaviour
Channel closes, at least with higher fee.
Actual behaviour
unable to gracefully close channel while peer is offline (try force closing it instead): channel link not found
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 12
- Comments: 18 (11 by maintainers)
You can fix this by using similar fee settings as your peer, and restart lnd. In
lnd.confsetcoop-close-target-confs=6andbitcoind.estimatemode=CONSERVATIVE. Note that you might end up with more expensive coop-close transactions, which I think is better than having to force-close the channel.In my understanding a coop-close attempt works if the two (lnd) peers start suggesting values where the difference between the two values is at most 9 (each peer is allowing 1/3x to 3x). You can call
bitcoin-cli estimatesmartfee 6 CONSERVATIVEetc. to see the fee rates that are used in this computation.We added the max fee setting for the initiator as people complained they had situations where they wanted to close with 1 sat/byte (as the initiator), but ended up accepting 20 sat/byte or w/e eventually due to our “satisficement algorithm”. In this case, the initiator rejected things since it exceeded the max they wanted to pay.
Ultimately, the whole “closing fee negotiation” aspect of the spec is pretty ill defined. It’s easy to end up in a state where neither side “compromises” so you end up in a deadlock. After we merge https://github.com/lightningnetwork/lnd/pull/7062, we’ll likely go to a mode where the responder just accepts w/e fees the initiator wants, since they’re paying fees at the end of the day, and the responder can always do CPFP assuming they have an output.
#7062 also starts to persist the delivery script that the RPC caller wanted to use, which can also be extended to commit their specified fee range.