CJIT channel force closed while attempting LNURL withdrawals

[piotr-iohk]

What happened?

I created a CJIT channel successfully via incoming payment from another wallet. I then attempted multiple LNURL withdrawals which all failed with "recipient node is offline or unreachable". The CJIT channel was force closed by Blocktank. After I created another CJIT channel, the LNURL withdrawal succeeded.

Timeline:

• 14:00:09 - CJIT channel loaded (612k sat capacity), appeared operational
• 14:00:19 - LNURL withdraw 1 failed: "recipient node is offline or unreachable"
• 14:03:56 - LNURL withdraw 2 failed: "recipient node is offline or unreachable"
• 14:06:12 - Channel force closed by counterparty (COUNTERPARTY_FORCE_CLOSED)
• 14:08:08 - LNURL withdraw 3 failed: "routing fees are insufficient"
• ~14:10 - I created new CJIT via payment from another wallet
• 14:12:58 - LNURL withdraw 4 succeeded

Observations:

• Channel appeared operational (sent ChannelReady, connected to peer)
• Channel was at update_id: 0 - no state changes after creation
• I had 761 sats on my side, counterparty had ~611k sats (CJIT inbound liquidity)
• Force close happened while I was actively using the app

Steps to Reproduce

1. Close existing Lightning channels (or start fresh)
2. Create a CJIT channel by receiving a payment from another wallet
3. Immediately scan LNURL-withdraw QR (e.g., from demo.lnbits.com)
4. Attempt the withdrawal
5. Observe failure with "recipient node is offline or unreachable"
6. Channel may be force closed by Blocktank

Logs / Screenshots / Recordings

Log files: bitkit_2026-01-27_12-44-14.log, bitkit_2026-01-27_14-00-06.log

bitkit_logs_1769523217388.zip

14:00:09.711 INFO - Successfully loaded channel 9db433d6... at update_id 0
14:00:10.870 DEBUG - Handling SendChannelReady event for node 03816141... for channel 9db433d6...
14:00:19.939 WARN - Failed to request LNURL withdraw [AppError='requestLnurlWithdraw error: withdraw not working. Payment failed: recipient node is offline or unreachable']
14:06:12.062 ERROR - Closed channel 9db433d6... due to close-required error: Channel closed because commitment or closing transaction was confirmed on chain.
14:06:12.177 TRACE - ChannelClosed { channel_id: 9db433d6..., reason: CommitmentTxConfirmed, channel_capacity_sats: 612000, last_local_balance_msat: 761000 }

Environment

Android, mainnet, block height ~933,978, Bitkit 174
Ln withdrawals from https://demo.lnbits.com/withdraw/

[jvsena42]

@piotr-iohk could you provide the node id too?

[jvsena42]

Summary of Findings

1. The CJIT channel was a 0-conf channel created at 13:32
2. The user's node was offline for ~28 minutes (app backgrounded/closed from 13:32 to 14:00)
3. The LSP (Blocktank) likely initiated force close while the node was offline
4. When the user reopened the app, the node saw the channel as operational and created valid invoices with route hints
5. But from the network's perspective, the channel was already being closed
6. The LNURL sender couldn't route through a closing channel, hence "recipient offline"
7. Force close confirmed on-chain at 14:06 (must have been broadcast earlier)

The logs clearly show:

• Node was running and connected to all 3 peers when LNURL was attempted
• Invoice was created correctly with route hints
• Error came from external sender (demo.lnbits.com), not local node

[piotr-iohk]

@piotr-iohk could you provide the node id too?

From the logs:

Starting up LDK Node with node ID 03382eb8dbb587197cb8eecfff38ca47eb296940ae0cfc29f3659acb1b5526912b on network: bitcoin

[jvsena42]

Channel IDs:

• Channel: 9db433d6f3e05b3a9b327281c0af52525675b992f8254d249620877d434ff0c0
• Funding TX: c0f04f437d872096244d25f892b975565252afc08172329b3a5be0f3d633b49d
• Force Close TX: 7482e605f1d4e34e8719475d36a23acffe67d6c937e57ee38464678263b3fb7b

[jvsena42]

The funding and closing transaction were confirmed in the same block

https://mempool.space/tx/7482e605f1d4e34e8719475d36a23acffe67d6c937e57ee38464678263b3fb7b
https://mempool.space/tx/c0f04f437d872096244d25f892b975565252afc08172329b3a5be0f3d633b49d

[jvsena42]

The LSP logs reveal the exact cause of the force close:

sync failed: remote's next commit height is 0, while we believe it is 1!
possible remote commitment state data loss

The LSP believes the channel is at commitment height 1, but the client (LDK) is stuck at commitment height 0!

This confirms your suspicion - it's NOT about the node being offline or funding tx timing. It's a channel state desynchronization.

Timeline from LSP logs (reading bottom-to-top):

1. New inbound connection from client (193.164.254.212:57138)
2. LSP attempts to re-synchronize the channel
3. Sync fails: "remote's next commit height is 0, while we believe it is 1"
4. LSP detects "possible remote commitment state data loss"
5. LSP force-closes to protect against potential fraud

Root Cause:
The LSP sent a commitment update that advanced the channel to height 1, but the client never received/acknowledged it. When they reconnected, the client reported being at height 0, which the LSP
interpreted as potential data loss or replay attack.

[jvsena42]

Yes, there is a retransmission mechanism in the Lightning protocol (BOLT 2), but the situation here is more nuanced.

How channel_reestablish Works

When peers reconnect, they exchange channel_reestablish messages containing:

1. next_commitment_number - The commitment number the sender expects to receive next
2. next_revocation_number - The last revocation secret the sender has sent

The protocol does support retransmission:

• If peer A's next_commitment_number indicates peer B's last commitment_signed wasn't received, B should retransmit it
• If peer A's next_revocation_number indicates B's last revoke_and_ack wasn't received, B should retransmit it

What Happened Here

From the LSP logs:
sync failed: remote's next commit height is 0, while we believe it is 1!
possible remote commitment state data loss

The LSP (LND) detected that:

• It expected the client to be at commitment height 1
• But the client reported commitment height 0

This is interpreted as potential data loss, not a normal retransmission scenario.

Why Force-Close Instead of Retransmit?

The critical distinction is:

Normal disconnect (peer behind by 1) -> Retransmit missing messages
Data loss suspected (peer at initial state) -> Force-close to protect funds

When the LSP sees the client at height 0 while expecting height 1, it could mean:

1. Client lost its channel state (dangerous - could attempt fraud)
2. Client never persisted the state update (software bug)
3. Client is attempting to broadcast old state (fraud attempt)

The protocol cannot distinguish between these cases, so it defaults to force-close to protect funds.

The Gap in LDK's State

Looking at the client logs:
Channel loaded from disk: update_id 0 against monitor at update id 0

The LDK node never advanced past update_id: 0. This suggests:

1. The commitment update from the LSP was either never received or never persisted
2. When LDK reconnected, it honestly reported its state as height 0
3. LND saw this as "data loss" and force-closed

Potential Bug Areas

The question becomes: Why didn't LDK persist the commitment update?

Possible causes:

1. Race condition during shutdown - App was stopped (ACTION_STOP_SERVICE_AND_APP at 13:59:42) while a commitment update was in-flight
2. VSS sync failure - State wasn't backed up before shutdown
3. Message ordering - commitment_signed received but not processed before disconnect

The retransmission mechanism can't help if the client honestly reports it's at height 0 - that triggers the "data loss" protection path, not the "retransmit" path.

Summary

There is retransmission for normal disconnects, but not for suspected data loss. The issue is that LDK's state didn't advance from height 0 to 1 before the disconnect, causing the LSP to interpret this as
data loss rather than a simple retransmission scenario.