Force close transactions with BlockTank not being confirmed

[jvsena42]

What I got so far:

• Blocktank node is a trustedLnPeers
• Trusted peer channels use anchor outputs
• Anchor outputs have a different outputs scripts with different CSV conditions

DEBUG: Current block height: 31732
WARN⚠️: 🔑 CLAIMABLE HEIGHT: 0 ← Output becomes spendable at this block
WARN⚠️: ⚠️ Claimable height is 0 - this may indicate LDK hasn't calculated the timelock yet

LDK has claimableHeight = 0, which means LDK is failing to calculate when this force-close output becomes spendable. This is why the funds are stuck indefinitely.

External node channels are not on trusted list so they use a non-anchor channel format. That is why it worked on the tests

Another strange this is that transactionName = 0
It suggests LDK might be completely missing the force-close transaction details.
It would be helpful is I could see the commitment transaction in the mempool

WARN⚠️:   📄 TRANSACTION NAME/ID: 0
WARN⚠️:   🔑 CLAIMABLE HEIGHT: 0 ← Output becomes spendable at this block
WARN⚠️:   ⚠️ Claimable height is 0 - this may indicate LDK hasn't calculated the timelock yet
WARN⚠️:   🔍 ANCHOR CHANNEL BUG: LDK cannot determine when CSV timelock expires

    func sync() async throws {
        guard let node else {
            throw AppError(serviceError: .nodeNotSetup)
        }

        Logger.debug("Syncing LDK...")
        try await ServiceQueue.background(.ldk) {
            try node.syncWallets()
            // try? self.setMaxDustHtlcExposureForCurrentChannels()
        }
        Logger.info("LDK synced")

        await refreshChannelCache()

        // Log detailed balance information after sync
        let balanceDetails = node.listBalances()
        let nodeStatus = node.status()
        let currentHeight = nodeStatus.currentBestBlock.height

        Logger.debug("=== LDK Balance Details After Sync ===")
        Logger.debug("Current block height: \(currentHeight)")
        Logger.debug("Total onchain: \(balanceDetails.totalOnchainBalanceSats) sats")
        Logger.debug("Total lightning: \(balanceDetails.totalLightningBalanceSats) sats")
        Logger.debug("Lightning balances count: \(balanceDetails.lightningBalances.count)")

        for (index, balance) in balanceDetails.lightningBalances.enumerated() {
            Logger.debug("Lightning Balance #\(index + 1):")

            switch balance {
            case let .claimableOnChannelClose(
                channelId,
                counterpartyNodeId,
                amountSat,
                transactionName,
                confirmationHeight,
                claimableHeight,
                paymentHash,
                paymentPreimage
            ):
                Logger.warn("  Type: ClaimableOnChannelClose")
                Logger.warn("  ⚠️ This is a FORCE-CLOSED channel balance waiting to be claimed!")
                Logger.debug("  Channel ID: \(channelId)")
                Logger.debug("  Amount: \(amountSat) sats")
                Logger.warn("  📄 TRANSACTION NAME/ID: \(transactionName)")
                Logger.debug("  Confirmation height: \(confirmationHeight)")
                Logger.warn("  🔑 CLAIMABLE HEIGHT: \(claimableHeight) ← Output becomes spendable at this block")

                // Calculate blocks remaining until claimable
                let currentHeightUInt64 = UInt64(currentHeight)
                if claimableHeight > currentHeightUInt64 {
                    let blocksRemaining = claimableHeight - currentHeightUInt64
                    Logger.warn("  ⏰ Blocks until claimable: \(blocksRemaining) (need to mine \(blocksRemaining) more blocks)")
                } else if claimableHeight > 0 {
                    Logger.warn("  ✅ Output is NOW CLAIMABLE (claimable height \(claimableHeight) <= current height \(currentHeight))")
                    Logger.warn("  🚨 LDK should sweep this automatically - if it hasn't, there may be an issue")
                } else {
                    Logger.warn("  ⚠️ Claimable height is 0 - this may indicate LDK hasn't calculated the timelock yet")
                    Logger.warn("  🔍 ANCHOR CHANNEL BUG: LDK cannot determine when CSV timelock expires")
                    Logger.warn("  💡 This is a known issue with anchor channels - funds are stuck until LDK is fixed or manual intervention")
                }

                if paymentHash != 0 {
                    Logger.debug("  Payment hash: \(paymentHash)")
                }
                if paymentPreimage != 0 {
                    Logger.debug("  Payment preimage: \(paymentPreimage)")
                }
                Logger.debug("  Counterparty: \(counterpartyNodeId)")

            case let .claimableAwaitingConfirmations(channelId, counterpartyNodeId, amountSat, confirmationHeight, transactionName):
                Logger.info("  Type: ClaimableAwaitingConfirmations")
                Logger.info("  ⏳ Sweep transaction is pending, waiting for confirmations")
                Logger.debug("  Transaction: \(transactionName)")
                Logger.debug("  Confirmation height: \(confirmationHeight)")
                Logger.debug("  Counterparty: \(counterpartyNodeId)")

            case .contentiousClaimable:
                Logger.warn("  Type: ContentiousClaimable")
            case .maybeTimeoutClaimableHtlc:
                Logger.debug("  Type: MaybeTimeoutClaimableHTLC")
            case .maybePreimageClaimableHtlc:
                Logger.debug("  Type: MaybePreimageClaimableHTLC")
            case .counterpartyRevokedOutputClaimable:
                Logger.warn("  Type: CounterpartyRevokedOutputClaimable")
            }
        }
        Logger.debug("=====================================")

        // Emit state change with sync timestamp from node status
        if let latestSyncTimestamp = nodeStatus.latestLightningWalletSyncTimestamp {
            let syncTimestamp = UInt64(latestSyncTimestamp)
            syncStatusChangedSubject.send(syncTimestamp)
        } else {
            let syncTimestamp = UInt64(Date().timeIntervalSince1970)
            syncStatusChangedSubject.send(syncTimestamp)
        }
    }

Originally posted by @jvsena42 in #207 (comment)

[jvsena42]

need to retest this after the last updates

[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.

[jvsena42]

The last two comments should be in
synonymdev/bitkit-android#528

But are also applied to this issue