-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug]: cooperative closure stuck after failed fee negotiation #9224
Comments
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).
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. |
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.
The text was updated successfully, but these errors were encountered: