Force close transactions with Blocktank not being confirmed

[jvsena42]

Same issue from iOS synonymdev/bitkit-ios#275

[jvsena42]

How to reproduce it:

1. Have a lightning channel with Blocktank
2. To accelerate the process, do on TransferViewModel:

const val RETRY_INTERVAL_MS = 1 * 60L
const val GIVE_UP_MS = 1L

3. Close the peer connection with Blocktank
4. Confirm the force close
5. On #blocktank-alert-regtest0 bot do /regtest-mine 144 fast
6. Transaction is never confirmed ❌

Screen_recording_20260103_104916.mp4

logs.txt

[jvsena42]

Problem Summary

Force close transactions with Blocktank (trusted peer) are never broadcast to the blockchain, even after mining 144+ blocks. The issue is caused by ldk-node v0.7.0-rc.1 incorrectly ignoring force
close events for trusted peers.

Root Cause Evidence

From logs.txt line 2091:
DEBUG [ldk_node::event:2183] Ignoring BumpTransactionEvent::ChannelClose
for channel 59177c89fe3cde8fd1adffc52b8615caad2043585bac56a976adbf7c51b2dab7
due to trusted counterparty 028a8910b0048630d4eb17af25668cdd7ea6f2d8ae20956e7a06e2ae46ebcb69fc

What happens:

1. User force-closes channel with Blocktank
2. LDK fires BumpTransactionEvent::ChannelClose to broadcast commitment transaction
3. ldk-node ignores this event because Blocktank is in trustedPeersNoReserve config
4. Commitment transaction is never broadcast
5. No claimable balances appear (lightningBalances: [] and pendingBalancesFromChannelClosures: [])
6. Funds are stuck indefinitely

Why This Happens

Trusted peer configuration is designed for cooperative scenarios (0-conf channels, reduced reserves). However, ldk-node incorrectly applies this optimization to force close scenarios, which are
non-cooperative by definition and MUST broadcast the commitment transaction.

---

Log Line Breakdown

DEBUG [ldk_node::event:2183] Ignoring BumpTransactionEvent::ChannelClose
for channel 59177c89fe3cde8fd1adffc52b8615caad2043585bac56a976adbf7c51b2dab7
due to trusted counterparty 028a8910b0048630d4eb17af25668cdd7ea6f2d8ae20956e7a06e2ae46ebcb69fc

What this means:

1. Channel ID: 59177c89fe3cde8fd1adffc52b8615caad2043585bac56a976adbf7c51b2dab7 is the Lightning channel being force-closed
2. Counterparty: 028a8910b0048630d4eb17af25668cdd7ea6f2d8ae20956e7a06e2ae46ebcb69fc is Blocktank's node ID (you can verify this in app/src/main/java/to/bitkit/env/Env.kt line 218 - it's Peers.staging)
3. BumpTransactionEvent::ChannelClose: This is an LDK event that tells the application "you need to broadcast the force-close commitment transaction to claim your funds"
4. "Ignoring": THIS IS THE BUG - ldk-node is deliberately choosing NOT to handle this event
5. "due to trusted counterparty": The reason it's ignoring the event is because this peer was configured in trustedPeersNoReserve (see LightningService.kt:114)

Second Log Line

TRACE [lightning::ln::channelmanager:9757] Channel is closed, applying 0 post-update actions

What this means:

• "Channel is closed": LDK has successfully closed the channel internally
• "applying 0 post-update actions": This is the problem - normally there would be actions like "broadcast commitment transaction", but there are ZERO actions being applied
• This confirms that ldk-node skipped the force-close transaction broadcast

Why This is a Bug

The intent of trustedPeersNoReserve configuration is:

• Trust this peer for cooperative operations (0-conf channels, no reserves)
• Assume they won't try to cheat during normal operations

However, ldk-node incorrectly extended this trust to force close scenarios, where:

• The peer is disconnected or uncooperative (that's why we're force closing!)
• We MUST broadcast our commitment transaction to claim our funds
• We cannot trust the peer to broadcast fairly - they might be malicious or offline

The Consequence

Because ldk-node ignores the event:

1. No commitment transaction is broadcast
2. The funding UTXO remains unspent on-chain
3. No claimable balances appear in lightningBalances
4. Funds are stuck until manual intervention

This is a critical bug in ldk-node that affects all users who force-close channels with trusted peers.