Channel stuck in CLOSINGD_COMPLETE if funding never confirms

[ksedgwic]

When a mutual close negotiation completes on a channel whose funding
tx never confirmed, the channel state is stuck. The signed close tx
is permanently invalid — its input is a 2-of-2 funding output that
does not exist on chain — so the state machine has no path from
CLOSINGD_COMPLETE to FUNDING_SPEND_SEEN / ONCHAIN. The channel
sits indefinitely with no cleanup.

Similar to #9112

Concrete instances

More details about the following channels can be found in clboss
issue #312. @ksedgwic
operates one node; the issue reporter operates the other.

Channel A

• channel_id: 98f1632d48f0d94d86161a8b4745a97d34c72beb3a6f1db4050210d18aae1e6e
• funding_txid: 6f1eae8ad1100205b41d6f3aeb2bc7347da945478b1a16864dd9f0482d63f198 — never confirmed on chain
• close tx (signed, in DB on both sides): 92ce9629985b686b1b9b433b78561fe33d188c71c1131d100798bb24354fe57d — never broadcast; 404 on every explorer
• opener: counterparty; closer: us
• created 2026-01-31; reached CLOSINGD_COMPLETE 2026-02-24
• still in CLOSINGD_COMPLETE on both sides as of 2026-04-30

Channel B

• channel_id: 264d24bdade7908c31e4d8338368d321c08f4b50fbaf92761da239302ac2cf45
• funding_txid: 45cfc22a3039a21d7692affb504b8fc021d3688333d8e4318c90e7adbd244d26 — never confirmed
• close tx (signed, in DB on both sides): d00300b5acb9b7105d2e11d176a1bee5cf05db8e38b6edc6cd8224ff226665f8 — never broadcast
• opener: counterparty; closer: us
• created 2026-02-28; reached CLOSINGD_COMPLETE 2026-03-11
• still in CLOSINGD_COMPLETE on both sides as of 2026-04-30

Reproducer

Reproduced by #9103

[ddustin]

What CLN is doing with the channel sounds like the correct behavior. It seems better to search indefinitely for potentially lost funds than give up.

What does make sense to me is a double-spend system. Take the reserved UTXOs that went into awaiting channels that are in AWAITING_UNILATERAL or CLOSINGD_COMPLETE and unreserve them.

We need essentially the same thing for splices where our peers fail or refuse to sign.

For this case where he just wants out, it also makes sense to me to have a command that just unlocks all the funds in the wallet. Something like a unreserveallinputs version of unreserveinputs.

[ddustin]

Dove in a bit more and dualopen channels automatically unreserves inputs in 2016 blocks (14 days).
Splicing automatically unreserves inputs in 72 blocks (12 hours).

[ksedgwic]

I'm a little confused ... none of these are reserved ... they are permanently "stuck" ...

#9103 adds a (failing) unit test which puts an channel in this situation.

[ddustin]

The funds (UTXOs) are reserved -- not the channels 👍

This is to say the outputs table for the given UTXO has its reserved_til set to a specific block height. This can be observed through the listfunds rpc which outputs it as reserved_to_block.

As far as I understand, the funds will stay reserved until they move on chain or the given block height is reached.

It's all seperate from channels and whatever state they may be in.

Once the block height passes, you can use them from the onchain wallet (withdraw, etc).

[ksedgwic]

But the bug has nothing to do with reserved utxos.

It's that the channels are "stuck" and can't be cleared w/o using developer force commands.

[ddustin]

First off just want to back up and say this a great subject to be talking about. I've been using this as a moment to get myself fully up to speed with what the codebase currently does and verify my assumptions around this.

What I understand your test to do is open a channel and mutually close it. The behavior you're expecting is this channel to move to 'FUNDING_SPEND_SEEN / ONCHAIN', despite the funding never going on chain.

The signed close tx
is permanently invalid — its input is a 2-of-2 funding output that
does not exist on chain

Missing from your specification is if UTXOs used in channel in the channel open are spent or not. Lets assume they aren't spent (which I believe your test assumes). If this is the case the 2-of-2 funding input is very much valid and we must have code alive to handle if it is published on chain.

The behavior I expect in this scenario is exactly what we see. The channel waits in perpetuity for the channel open, after which it will apply the mutual close.

I wouldn't call this a bug but a policy decision and I agree with the current policy.

Some areas around this I could see worth investigating and potentially working on:

• Communicating to the user more clearly what is happening
• If one of more of the UTXOs for the funding are spent
• Force-close behavior

[ksedgwic]

Are you saying it's ok to have channels in "stuck" states that can never be cleared except w/ developer mojo? This doesn't seem good ...

[ddustin]

I'll try to say it simpler:

Without something monitoring the funding tx, customer funds will be lost. channeld is the daemon that monitors those funds.

Turning off channeld means customer funds will be lost should the funding tx go onto chain.

To prevent the loss of user funds, channeld must be kept alive if it is possible for the funding tx to go on chain.

In the case of a force close, that responsibility moves onto closingd.

Your proposal, as I understand, will result in lost funds.

Maybe it would be better to talk about this in person

[ksedgwic]

I wasn't actually making a proposal ...

But if the funding tx can't ever confirm because it's inputs are double-spent do you think CLN should clear up the channel?

[ksedgwic]

@ddustin see also #9112 ... an adjacent, but different case