Another force close stuck in waiting close

[LNOrville]

Background
I used LNDg for force closing a channel with a peer listed as zombie by hashxp. I put the going mempool rate (32 sats/vbyte) in the input field.I checked FC. The tx abb3911e626189026728e6966885806a2681fda0fba44388a521868d6ceb8a4f was sent to mempool with a much lower fee (11 sats/vbyte according to mempool explorer), and lncli now says "waiting close" for this channel. Not able to FC from lncli, a force close attempt via lncli outputs: lncli] rpc error: code = Unknown desc = channel is already in the process of being force closed.

Then I tried lncli wallet bumpclosefee using the closing tx in the command and trying with both indexes. For both inputs I get "intercept already started"

In the waiting close output I see this:
"chan_status_flags": "ChanStatusBorked|ChanStatusCommitBroadcasted|ChanStatusLocalCloseInitiator"

pendingsweeps outputs:
"pending_sweeps": [
{
"outpoint": "86b36d4472c29752c1d9f52844a0b1785f9c33143453cc04895b4a2ac68b5ce9:0",
"witness_type": "COMMITMENT_ANCHOR",
"amount_sat": 330,
"sat_per_vbyte": 32,
"broadcast_attempts": 0,
"next_broadcast_height": 818957,
"requested_sat_per_vbyte": 0,
"requested_conf_target": 144,
"force": false
},
{
"outpoint": "abb3911e626189026728e6966885806a2681fda0fba44388a521868d6ceb8a4f:0",
"witness_type": "COMMITMENT_ANCHOR",
"amount_sat": 330,
"sat_per_vbyte": 32,
"broadcast_attempts": 0,
"next_broadcast_height": 818957,
"requested_sat_per_vbyte": 0,
"requested_conf_target": 144,
"force": false

Your environment: LND 0.17.2-beta, Bitcoin Bitcoin Core 25.1.0, Umbrel on a RasPi

Steps to reproduce: Not sure if this can be easily reproduced. It would require Umbrel and LNDg

Expected behaviour
When I started the tx in LNDg I expected a fast transacting force close.

Actual behaviour
Transaction is stuck in waiting close with a low slow fee, and my attempts to bump the fee are unsuccessful

[guggero]

Force closing means publishing the latest pre-signed state of a channel. So you cannot change the fees on the force close transaction as that would require your peer to re-sign.
This can be avoided in the future by setting max-commit-fee-rate-anchors=100 or some high value like that.

You can use lncli wallet bumpclosefee c4db96e8113f80f22048e52c3151faff344950e7814a29891513ad227c0a787c:1 to bump the anchor sweep CPFP. Or you can use the new chantools pullanchor command (not yet in a release, you need to build chantools from source from the master branch).

[LNOrville]

Thank you for looking into this. lncli wallet bumpclosefee c4db96e8113f80f22048e52c3151faff344950e7814a29891513ad227c0a787c:1 outputs "intercept already started". Would you consider releasing chantools as an Umbrel app? Or maybe it could be integrated into lnshell? Linux is not my strong side, so installing it on my node from github would feel a bit (too?) adventurous for me.

[guggero]

Hmm, that intercept already started error is weird. Are you running the command from the lightning shell?

Yeah, maybe I could integrate chantools into the lightning shell, good idea. But that will probably take me a while.
In the meantime I guess I can just create a new release version so you can download a pre-built binary for your laptop to run it there. I'll get to that tomorrow.

[LNOrville]

Yes, I am running the command from lightning shell. I am wondering if the sweeps ever get broadcasted? I just restarted lnd, and pending sweeps says:
"outpoint": "abb3911e626189026728e6966885806a2681fda0fba44388a521868d6ceb8a4f:0",
"witness_type": "COMMITMENT_ANCHOR",
"amount_sat": 330,
"sat_per_vbyte": 68,
"broadcast_attempts": 0,
"next_broadcast_height": 824192,
"requested_sat_per_vbyte": 0,
"requested_conf_target": 144,
"force": false

So when broadcast_attempts is 0, did the sweep broadcast? And will it ever broadcast when "force": false? For the command lncli wallet bumpfee a -force parameter has to be added to sweep even if the yield is negative - does the anchor fee sweep require this parameter too when the yield is negative?
I run my Umbrel node on a Raspberry Pi - would it be possible to run chantools on the RasPi?

[guggero]

It sounds to me like the sweep isn't accepted by your local mempool because of the high fees.
I'm not sure how force works in combination with anchor sweeps, since sweeping an anchor never yields a positive outcome.
But yeah, I'd expect you to need the --force flag on the command.

Yes, you can run chantools on the Raspberry Pi, you just need to download the linux-arm64 instead of linux-amd64.
I just released the latest version that includes the pullanchor sub command: https://github.com/lightninglabs/chantools/releases/tag/v0.12.1

[LNOrville]

This force close was submitted via the LNDg GUI, and I do not know how this sweep ended up with "force": false. If the sweep is not broadcasted unless yield is positive, and if this sweep cannot be modified, then i am thinking that would mean that this anchor sweep will never happen. The sweeper seems to adjust the fee to the going mempool rate. now I get
"outpoint": "abb3911e626189026728e6966885806a2681fda0fba44388a521868d6ceb8a4f:0",
"witness_type": "COMMITMENT_ANCHOR",
"amount_sat": 330,
"sat_per_vbyte": 55,
"broadcast_attempts": 0,
"next_broadcast_height": 824192,
"requested_sat_per_vbyte": 0,
"requested_conf_target": 144,
"force": false
I have set my mempool to 700 MB, and I am able to broadcast the raw tx of the original close, which is 11 sats/vByte, so I don't think my Mempool would not accept the sweep tx which is at a much higher rate.
Thank you for making chantools available. I may look into trying to use it on this close, although I wonder if it can even be categorized as a force close when the sweep of the anchor is not forced. It is not a cooperative close either, since my peer is a zombie.