[Bug]: Spending balance briefly doubles after coop close + second channel open

[piotr-iohk]

What happened?

While QA-testing hardware-wallet transfer to spending (PR #1039), after:

1. MAX transfer from Trezor → spending (first LSP channel),
2. Coop close → savings (full channel to on-chain),
3. 25% transfer to spending (opens a second channel),

the Spending balance on home briefly showed the old channel amount plus the new channel (e.g. ₿ 1,593,281 = ~1,531,123 + ~62,158), and the total header was inflated accordingly (~₿ 3,311,656). After a few regtest blocks mined, balances returned to normal (Spending ~62,158, Savings ~1,531,123).

Reproduced once in session; subsequent attempts did not reproduce (timing-sensitive).

Not believed to be hardware-wallet-specific — same DeriveBalanceStateUseCase path for any coop close + new channel while LDK still lists coop-close funds in lightning.

Expected behavior

After coop close funds appear in Savings (on-chain), they should not also count toward Spending (totalLightningSats) until LDK clears the coop-close claimable entry. Opening a second spending channel should only add the new channel balance to Spending.

Steps to Reproduce

1. Regtest wallet with LSP channel(s).
2. Fund spending with a large first channel (e.g. MAX from Trezor or savings → spending).
3. Transfer to savings (coop close entire spending channel). Confirm savings balance updates on home.
4. Immediately start another transfer to spending (e.g. 25%) to open a second channel — do not wait several minutes / many blocks.
5. Complete funding until the second channel is ready (ChannelReady).
6. Open home and compare Spending + total header.

Tip: Window is narrow (~few blocks on regtest while ClaimableAwaitingConfirmations remains in LDK after on-chain sweep). Slowing block production after coop close may widen the window.

Logs / Screenshots / Recordings

Logs:

bitkit_logs_2026-06-24_08-27-21.zip

Screenshots

State	Screenshot	Notes
Inflated spending / total		Spending ~₿ 1,593,281; total header ~₿ 3,311,656 (old coop-close amount + new second channel).
Corrected		Spending ~₿ 62,158; total ~₿ 1,780,533 after coop-close claimable cleared (~few blocks).

Log signature (when bug visible):

• DeriveBalanceStateUseCase: totalOnchainSats ≈ coop-close amount; totalLightningSats ≈ coop-close + new channel; balanceInTransferToSavings = 0; Active transfers: []
• LDK lightningBalances: ClaimableAwaitingConfirmations (source: COOP_CLOSE) + new channel ClaimableOnChannelClose
• Example inflated totalLightningSats: 1,593,281 at block height ~136343; corrected to 62,158 after height ~136348

Bitkit Version

2.3.0 (182)

Device / OS

Samsung Galaxy S22, Android 16

Reproducibility

Rarely (once or twice)

Additional context

• Environment: Regtest (remote Blocktank electrum), Trezor Safe 7 via BLE — HW used in discovery flow but root cause is general balance derivation, not Trezor signing/BLE.
• Discovered during: QA of PR feat: transfer to spending from hw wallet #1039 (HW transfer to spending).
• Related issues (different symptoms): [Bug]: pending transfer not reflected in total balance #808, android: transfer to savings completes on spending details screen #809, android: transfer to savings button missing after transfer to spending until refresh #810
• Suspected cause: TransferRepo settles COOP_CLOSE when swept to on-chain; active transfer removed → DeriveBalanceStateUseCase no longer subtracts coop-close ClaimableAwaitingConfirmations from totalLightningSats while LDK still includes it in totalLightningBalanceSats. Second channel ready adds new balance on top → transient double on Spending line.
• iOS: BalanceManager.getOrphanClosedChannelBalance may mask this; Android lacks equivalent logic.
• Fix direction: Port iOS orphan closed-channel subtraction and/or always subtract ClaimableAwaitingConfirmations with COOP_CLOSE source from displayed lightning; add unit test for settled coop close + lingering claimable + second channel.

[ovitrif]

Interesting findings @piotr-iohk!

Great that you've shared so much context, it should be enough to figure out the wrong logic which allows for this bug to occur, this is probably the next best thing when a reliable repro scenario can't be found by manually testing.

Pretty sure you're on point about the issue existing in the balance derivation math before the changes brought by #1039.

[ovitrif]

I’m keeping this open as its own bug rather than marking it duplicate.

Related Android tracking:

• Broader transfer/balance UI area: [Bug]: Transfer UI Improvements #599
• Same balance-derivation family, opposite pending-transfer direction: [Bug]: pending transfer not reflected in total balance #808

Implementation note for the fix: this ports the iOS orphan closed-channel balance concept from synonymdev/bitkit-ios#336, introduced for synonymdev/bitkit-ios#264; the helper landed in synonymdev/bitkit-ios@38b27d27810c. On Android, #806 only covered the active-transfer case, so it did not cover the Active transfers: [] window captured here.

I also added prio:high: a wrong displayed wallet total is serious even when transient.