Skip to content

staticaddr: map reclaimed loop-in deposits back to their swap - #1251

Draft
claravanstaden wants to merge 2 commits into
lightninglabs:masterfrom
claravanstaden:static-reclaim-swap-hash
Draft

claravanstaden wants to merge 2 commits into
lightninglabs:masterfrom
claravanstaden:static-reclaim-swap-hash

Conversation

@claravanstaden

@claravanstaden claravanstaden commented Oct 14, 2026 •

Copy link
Copy Markdown
Collaborator

A static loop-in's deposits can end up mapped in deposits.swap_hash to a swap that never spends them:

Step Swap A Swap B Deposits mapped to
1 Selects the deposits A
2 Deadline passes, gives them back A
3 Selects them B
4 Htlc confirms, takes them back B (wrong)

In step 2 the htlc hasn't confirmed yet, so swap A cancels its invoice but keeps watching the htlc. In step 4 it takes the deposits back to sweep the htlc timeout path.

This maps the deposits back to swap A in step 4, in transitionDepositsToHtlcTimeout, once they are locked in SweepHtlcTimeout, and again if they already were, in case loopd stopped before mapping them. Deposits that can't be locked, for example because swap B completed with them, stay mapped to swap B. The loop-in store interface gains the existing BatchMapDepositsToSwapHashes for this.

What changes is everything that goes through the mapping: which deposits a swap recovers after a restart, and so which htlc it rebuilds for its htlc timeout sweep, and which swap the deposits' on-chain cost is reported for in #1248. A restart while swap B holds only some of the deposits isn't covered here and will be fixed separately.

Tests

TestMonitorInvoiceAndHtlcTxRemapsReclaimedDeposits runs the monitor with the real loop-in store through the steps above, with swap B taking one of swap A's two deposits, and checks that each swap loads its own deposits from the store. It fails on master. TestMonitorInvoiceAndHtlcTxMapsOnlyLockedDeposits checks that a deposit swap B completed with stays mapped to it, and that an already locked deposit is mapped again. TestMonitorInvoiceAndHtlcTxRetriesFailedMapping checks that the monitor retries if the mapping fails, and TestMonitorInvoiceAndHtlcTxNilDeposit that a nil deposit fails the transition before any deposit is moved.

Pull Request Checklist

  • Add an entry to docs/release-notes/release-notes-next.md, or apply the
    no-changelog label (required by CI)

If a static loop-in's payment deadline passes before its htlc confirms,
the swap cancels its invoice, gives its deposits back and keeps
watching the htlc. Another swap can then select the deposits, which maps
them to that swap in deposits.swap_hash. If the first swap's htlc
confirms after all, the first swap takes the deposits back to sweep the
htlc timeout path, but they stay mapped to the other swap, which never
spends them.

Map the deposits to the swap that sweeps them once they are locked for
its htlc timeout sweep, also when they already were, in case loopd
stopped before mapping them. Deposits that can't be locked, for example
because the other swap completed with them, stay mapped to that swap.
A nil deposit now fails the transition instead of being passed on. The
loop-in store interface gains the existing BatchMapDepositsToSwapHashes
for this.
@claravanstaden
claravanstaden force-pushed the static-reclaim-swap-hash branch from 98b99ac to 225407c Compare October 16, 2026 11:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants