Looking at comments at this point you should only be looking at the CLI to ensure you're correctly getting any errors that might be present
How did you close them? Any errors or odd behavior at the time you closed/force closed?
Did you maybe clean out the node before closing not leave enough in the wallet for anchor fees?
Use ./lncli listchannel to be sure LND doesn't they're just open
./lncli pendinchannels to get the closing tx id, if the closing tx id doesn't exist in the mempool then it might not have gotten broadcast or was pruned already due to low fee
./lncli listunspent to check if you have any utxo's that came back from closures
If some closing tx's are confirmed and you're just waiting on the timelock, you can power off the node and turn it on later to spend those UTXO's, it doesn't need to be online if you just want to keep your state for later use.
Thanks for your suggestion:
How did you close them? Any errors or odd behavior at the time you closed/force closed?
I do not remember if and what error I got when trying to close-mutually, that's why I ended up force-closing the remaining three channels
Did you maybe clean out the node before closing not leave enough in the wallet for anchor fees?
No I did not clean out the node before closing these last 3 channels, leaving all the sats from the previous closed channels in there on the onchain wallet
Now, using:
  • lncli listchannels does not provide any output. Probably because have any active channels atm
  • lncli pendingchannels provide the following
{ "total_limbo_balance": "0", "pending_open_channels": [ ], "pending_closing_channels": [ ], "pending_force_closing_channels": [ ], "waiting_close_channels": [ { "channel": { "remote_node_pub": "hidden", "channel_point": "hidden:0", "capacity": "43095473", "local_balance": "0", "remote_balance": "0", "local_chan_reserve_sat": "0", "remote_chan_reserve_sat": "0", "initiator": "INITIATOR_REMOTE", "commitment_type": "ANCHORS", "num_forwarding_packages": "0", "chan_status_flags": "ChanStatusRestored" }, "limbo_balance": "0", "commitments": { "local_txid": "", "remote_txid": "", "remote_pending_txid": "", "local_commit_fee_sat": "0", "remote_commit_fee_sat": "0", "remote_pending_commit_fee_sat": "0" }, "closing_txid": "" }, { "channel": { "remote_node_pub": "hidden", "channel_point": "hidden:1", "capacity": "30000000", "local_balance": "0", "remote_balance": "0", "local_chan_reserve_sat": "0", "remote_chan_reserve_sat": "0", "initiator": "INITIATOR_REMOTE", "commitment_type": "ANCHORS", "num_forwarding_packages": "0", "chan_status_flags": "ChanStatusRestored" }, "limbo_balance": "0", "commitments": { "local_txid": "", "remote_txid": "", "remote_pending_txid": "", "local_commit_fee_sat": "0", "remote_commit_fee_sat": "0", "remote_pending_commit_fee_sat": "0" }, "closing_txid": "" }, { "channel": { "remote_node_pub": "hidden", "channel_point": "hidden:0", "capacity": "10000000", "local_balance": "0", "remote_balance": "0", "local_chan_reserve_sat": "0", "remote_chan_reserve_sat": "0", "initiator": "INITIATOR_REMOTE", "commitment_type": "ANCHORS", "num_forwarding_packages": "0", "chan_status_flags": "ChanStatusRestored" }, "limbo_balance": "0", "commitments": { "local_txid": "", "remote_txid": "", "remote_pending_txid": "", "local_commit_fee_sat": "0", "remote_commit_fee_sat": "0", "remote_pending_commit_fee_sat": "0" }, "closing_txid": "" } ] }
  • and lncli listunspent provide many UTXO
If some closing tx's are confirmed and you're just waiting on the timelock, you can power off the node and turn it on later to spend those UTXO's, it doesn't need to be online if you just want to keep your state for later use.
Ok it make sense, thanks. I'm just worried about the channels staying n that state forever! There's a way to check the status of the timelock?
reply
The fact that they're waiting_close and not pending_force_close implies they weren't actually force closed (ui you used to do this may not have handled it correctly)
Try force closing one of them again with lncli closechannel txid vout --force and see if that changes things
There's a potential scan bug that could be at play too, if the force close doesn't change things the LL folks will be best to help https://github.com/lightningnetwork/lnd/issues/8560
Your funds don't appear to be in jeopoardy though, just don't panic and do anything dumb and you'll get your coin back eventually
reply
THat's great to hear. Thank you so much! Yeah for now I was just waiting to see if anything unfolded within the node.. but after a while I start questioning things and want to know why this is happening.
It's really weird that aren't force closing! how did you get to this conclusion?
wouldn't be better then to bump the fees as @TNStacker suggested?
In any case, the closing_txid is empty on all 3 channels (I did not delete anything else apart replacing the values on remote_node_pub and channel_point with hidden) and also the Uis (TH and RTL) does not provide me that info, so how can I (re)try to force close?
reply
Because it's "waiting close", not "pending force close"
Since there's no closing txid there's nothing to bump
Use the command in my previous comment, the txid is the channel point and the vout is the :0 digit at the end of it (usually 0 but might be higher)
reply
tried the one that has vout = 1 and...
[lncli] rpc error: code = Unknown desc = cannot close channel with state: ChanStatusRestored
reply
Gives you something to go on at least...
This is odd though since you didn't say it was a data loss / SCB closure, so its either the bug I mentioned before or something else altogether. You should take this to the discussion boards on the LND github to be safe.
My guess is they'll direct you here after further diagnosis: https://github.com/lightninglabs/chantools/blob/master/doc/zombierecovery.md
reply
Ok, this start to make sense now...
Also found this https://github.com/lightningnetwork/lnd/issues/7313 with the difference that it also has ChansStatusDataLoss so I assume the data on my side is not lost then 🤞
I'll update when I've any news
Thanks for now
reply