Peer crashed during splice-in, channel now unrecoverable

[PdlNode]

The following situation occured while attempting a splice-in with CLN v24.11:

I initiated a splice as described in the documentation. The splice_init and splice_update commands returned successfully, however splice_signed aborted with an error indicating that the peer was unreachable. Indeed the peer has been offline ever since and no splice transaction has been published.

At the same time, my node apparently detected that the channel was in an error state and attempted to force-close it. However, the force-close doesn't work, because it tries to spend the UTXO of the splice transaction which hasn't been published. If my understanding is correct, the fully-signed splice transaction cannot be known to my node since the peer crashed before it could add their signature and send it. Therefore, the channel cannot be closed now without the peer coming back online and publishing the splice transaction, which hasn't happened and potentially won't.

I don't know what happened on the side of the peer. Obviously, their node also seems to be in trouble, so hopefully they will read this and collaborate to resolve the issue, if possible.

I don't know whether the splicing protocol can be changed to avoid this dangerous state, this might be a matter for research.

This is an excerpt from my log during the splicing operation:

XXXX-XX-XXXXX:X6:53.121Z UNUSUAL XXXXXX-channeld-chan#8: STFU complete: we are quiescent
XXXX-XX-XXXXX:X6:53.122Z UNUSUAL XXXXXX-channeld-chan#8: STFU complete: setting stfu_wait_single_msg = true
XXXX-XX-XXXXX:X7:36.662Z INFO    XXXXXX-channeld-chan#8: Splice negotation, will not send commit, not recv commit, not send signature, recv signature as initiator
XXXX-XX-XXXXX:X7:36.663Z INFO    XXXXXX-channeld-chan#8: Splice signing tx: 020000000XXXXXX
XXXX-XX-XXXXX:X9:22.305Z INFO    XXXXXX-chan#8: Peer transient failure in CHANNELD_NORMAL: Disconnected
XXXX-XX-XXXXX:X9:22.319Z INFO    XXXXXX-channeld-chan#8: Unable to resume splice as user sigs are missing.
XXXX-XX-XXXXX:X9:22.534Z INFO    XXXXXX-channeld-chan#8: We are initiating tx_abort for reason: next_funding_txid not recognized. Sending tx_abort.
XXXX-XX-XXXXX:X9:26.464Z UNUSUAL XXXXXX-chan#8: Peer permanent failure in CHANNELD_NORMAL: channeld: received ERROR channel XXXXXX: tx_abort is not allowed after I have sent my signature. msg: XXXXXX (reason=protocol)
XXXX-XX-XXXXX:X9:26.464Z INFO    XXXXXX-chan#8: State changed from CHANNELD_NORMAL to AWAITING_UNILATERAL
XXXX-XX-XXXXX:X9:29.323Z INFO    XXXXXX-connectd: Received WIRE_WARNING: WARNING: channel_announcement: no unspent txout XXXXXX
XXXX-XX-XXXXX:X9:29.699Z INFO    XXXXXX-connectd: Received WIRE_WARNING: WARNING: channel_announcement: no unspent txout XXXXXX

This is my node trying to force-close the channel, which fails (bad-txns-inputs-missingorspent) because the splicing transaction is unknown.

XXXX-XX-XXXXX:X9:43.073Z DEBUG   lightningd: sendrawtransaction: 02000000000XXXXXX
XXXX-XX-XXXXX:X9:43.159Z DEBUG   plugin-bcli: sendrawtx exit 25 (bitcoin-cli -rpcclienttimeout=60 -rpcconnect=X.X.X.X -rpcuser=... -stdinrpcpass sendrawtransaction 02000000000XXXXXX) error code: -25\nerror message:\nbad-txns-inputs-missingorspent

[ddustin]

However, the force-close doesn't work, because it tries to spend the UTXO of the splice transaction which hasn't been published.

This is my node trying to force-close the channel, which fails (bad-txns-inputs-missingorspent) because the splicing transaction is unknown.

This is the normal force close behavior -- it will aggressively attempt to publish all potential force close transactions (regardless of which are actually valid). This will include the old channel and the potential spliced channel. The "bad-txns-inputs-missingorspent" message is from bitcoin core and is expected for the invalid close transactions.

I initiated a splice as described in the documentation. The splice_init and splice_update commands returned successfully, however splice_signed aborted with an error indicating that the peer was unreachable.

Did you splice in funds but not call signpsbt before calling splice_signed? That would have caused the initial failure.

After reconnect, the node is trying to resume the splice but it can't because it believes it is missing user signatures (which would have been added by splice_signed). Your peer is requesting to resume the splice with the next_funding_txid field -- but we cannot resume because we're missing these signatures.

Normally, this would cause the splice abort process to abort the splice and resume normal operation -- however there is a chance our peer recieved the primary splice signature (signing the old funding), so we force close out of caution.

The force close for the original channel should go through normally.

What we should do here is error earlier by immediately refusing to finish the splice if user signatures are missing.

[ddustin]

Do you have a copy of your peers logs? It would be useful to see what happened during the disconnect.

Did it disconnect with a warning? If so that should show up on your side as well.

[PdlNode]

This is the normal force close behavior -- it will aggressively attempt to publish all potential force close transactions (regardless of which are actually valid). This will include the old channel and the potential spliced channel. The "bad-txns-inputs-missingorspent" message is from bitcoin core and is expected for the invalid close transactions.

This makes sense, thank you for the clarification. Nevertheless, the force-close attempts of my node don't seem to work. The channel has been in state AWAIT_UNILATERAL for several weeks now and no valid closing transaction has arrived in the mempool or blockchain. Is it possible to see whether my node is trying to publish other force-close transactions?

Did you splice in funds but not call signpsbt before calling splice_signed? That would have caused the initial failure.

Yes, I spliced in, but definitely called signpsbt before splice_signed. That doesn't seem to be the problem, here.

Do you have a copy of your peers logs? It would be useful to see what happened during the disconnect.

Unfortunately not, I was unable to contact them until now. Their node has come back online, but hasn't done anything about the channel.

Did it disconnect with a warning? If so that should show up on your side as well.

I posted all relevant log entries above and double-checked. The only warnings that appeared in my log were the Received WIRE_WARNING, of these there were several.