Open xmrk-btc opened 1 month ago
Both channels were coop closed eventually, so immediate problem is resolved. It happened mostly thanks to peer changing his mind and accepting lower fees, but my node also changed its bounds (now: 288-864 sats, before: 450-750 sats).
2024-10-27 01:13:49.085 [INF] CHCL: ChannelPoint(0f8c769434265108924bf2b48f4cc9ebd113836114477877076aac97e402bb67:4): shutdown response received, entering fee negotiation
2024-10-27 01:13:49.085 [INF] CHCL: Ideal fee for closure of ChannelPoint(0f8c769434265108924bf2b48f4cc9ebd113836114477877076aac97e402bb67:4) is: 288 sat (max_fee=864 sat)
2024-10-27 01:13:49.195 [INF] CHCL: ChannelPoint(0f8c769434265108924bf2b48f4cc9ebd113836114477877076aac97e402bb67:4): proposing fee of 288 sat to close chan
2024-10-27 01:13:49.256 [INF] CHCL: ChannelPoint(0f8c769434265108924bf2b48f4cc9ebd113836114477877076aac97e402bb67:4): computing fee compromise, ideal=288, last_sent=288, remote_offer=496
2024-10-27 01:13:49.256 [INF] CHCL: ChannelPoint(0f8c769434265108924bf2b48f4cc9ebd113836114477877076aac97e402bb67:4): proposing fee of 316 sat to close chan
2024-10-27 01:13:49.314 [INF] CHCL: ChannelPoint(0f8c769434265108924bf2b48f4cc9ebd113836114477877076aac97e402bb67:4): computing fee compromise, ideal=288, last_sent=316, remote_offer=447
2024-10-27 01:13:49.314 [INF] CHCL: ChannelPoint(0f8c769434265108924bf2b48f4cc9ebd113836114477877076aac97e402bb67:4): proposing fee of 347 sat to close chan
2024-10-27 01:13:49.391 [INF] CHCL: ChannelPoint(0f8c769434265108924bf2b48f4cc9ebd113836114477877076aac97e402bb67:4) fee of 0.00000347 BTC accepted, ending negotiation
But still, it took 7 hours to get it resolved, so it could be useful to be able to override maximum accepted by my node (as I wrote previously).
This should be addressed with the upcoming RBF coop close flow right?
This should get addressed with the upcoming coop close v2, which basically ensures that the peer initiating the channel closure will be paying the closing fee regardless of who initiated the channel open. This will basically cut short the need to negotiate on the fee rate for channel closure.
relevant prs currently tagged for v0.19: https://github.com/lightningnetwork/lnd/pull/8512 https://github.com/lightningnetwork/lnd/pull/8453
Background
I tried to cooperatively close a channel with this command
bin/lncli closechannel --sat_per_vbyte 3 --max_fee_rate 5 --delivery_addr bc1ppz3xa7efg3559qjgfw9ufhgt5z0e7yanr5yzgsjagh8cel6e377q248e6y 0f8c769434265108924bf2b48f4cc9ebd113836114477877076aac97e402bb67 4
They start negotiating (see below), but the peer offers rather large fee, so my node ends the negotiation.When the two nodes connect again, they again try to negotiate, with slightly higher fee, but not enough, so they fail again:
Your environment
lnd
: 0.18.3uname -a
on *Nix): Debian 12btcd
,bitcoind
, or other backend: bitcoind 0.28.0, mempool=300mcoop-close-target-confs=24
bitcoind.estimatemode=ECONOMICAL
Expected behaviour
I'd like to change the bounds when the negotiation starts again. Ideally, I would be able to run
lncli closechannel
again for the same channel, with say--max_fee_rate 10
, and the maximum of 10 sats/vB would be used in the next negotiation.Although I wonder why the peer wants so high fee, whether it is misconfigured.
This happened to me twice today already.