[claravanstaden]

The client co-signs three variants of the static address loop-in HTLC tx (standard, high and extremely high fee). The timeout sweep always rebuilt the standard fee variant, so if a backup variant confirmed, the sweep couldn't spend it. Only the standard fee rate is persisted, so rebuilding the confirmed variant after a restart isn't possible.

This PR takes the HTLC tx from the chain instead. It waits for the spend of the first deposit, checks that the spending tx spends exactly the swap's deposits and has one HTLC output, and sweeps that outpoint with its actual value. The lookup runs before the fee rate is estimated and is bounded by a 30 minute timeout (HtlcTxLookupTimeout in the loop-in config, not exposed by loopd). A second commit rejects sweeps whose output would be dust, since the backup variants leave a smaller HTLC output.

lnd reports missing inputs and mempool conflicts as an already spent output, which the sweep counted as published without recording a txid. That's how the sweep of the wrong variant failed without an error. Now it only counts as published if a confirmed tx spends the HTLC output and pays the sweep address, and that tx is the one monitored.

Recovering swaps that are already stuck from the old behavior isn't included. See the comment below; it can follow separately if needed.

An alternative to #1217 that doesn't depend on the multi-address stack. Thanks @hieblmi for the original approach.

Before and after

Before

1. The server publishes the high fee HTLC variant and doesn't pay the invoice.
2. After the HTLC expires, the sweep rebuilds the standard variant and spends its HTLC output, which isn't on chain.
3. lnd reports the missing input as an already spent output, so the client counts the sweep as published.
4. It waits for a confirmation that never comes, and the funds stay in the HTLC.

After

1. The server publishes the high fee HTLC variant and doesn't pay the invoice.
2. After the HTLC expires, the client looks up the tx that spent the first deposit (from lnd's spend notification, or lnd's wallet if the notification never comes) and gets the high fee variant.
3. It checks that the tx spends exactly the swap's deposits and has one HTLC output, then sweeps that output with its real value.
4. The sweep confirms and the funds come back.

Example

Two deposits, aaaa:0 (60,000 sat) and bbbb:1 (40,000 sat), at static address script S. HTLC script H. The client co-signs:

Variant	Inputs	Fee	Output 0 pays H	txid
standard	aaaa:0, bbbb:1	1,000	99,000	1111
high	aaaa:0, bbbb:1	5,000	95,000	2222
extreme	aaaa:0, bbbb:1	20,000	80,000	3333

Only the fee differs, so the HTLC output value and the txid differ too. The server publishes 2222 and never pays the invoice.

• Before: the sweep rebuilds the standard variant and spends 1111:0, signed over 99,000. lnd reports the missing input as an already spent output, so the client counts the sweep as published and waits for a confirmation that never comes.
• Now: the client asks which tx spent aaaa:0 (script S, height hint the swap's initiation height) and gets 2222. htlcOutput checks that it spends exactly {aaaa:0, bbbb:1} and has one output to H, then the sweep spends 2222:0, signed over 95,000.

Testing

• TestHtlcTimeoutSweepSpendsPublishedVariant: all three variants after a simulated restart
• TestHtlcTimeoutSweepFeeRateAfterLookup: fee rate estimated after the lookup
• TestFetchHtlcTxFailures: notifier error, spend without tx, lookup timeout, shutdown
• TestHtlcOutput: input and output validation
• TestCreateHtlcSweepTxRejectsDust: dust boundary
• TestHtlcTimeoutSweepOutputAlreadySpent: HTLC output spent by an earlier sweep, by a tx paying elsewhere, and not spent
• go test -race ./staticaddr/...
• Integration test against the swap server, pinned to this PR: the high and extremely high fee htlc tx confirm instead of the standard one, and the client sweeps the htlc output that confirmed after it expires. Both cases pass with this PR (about 105 s each) and fail on Loop master, where the sweep never reaches the mempool and the swap stays stuck.
• Each commit builds and passes the tests, and lint is clean.

Pull Request Checklist

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

[claravanstaden]

Open question before this is ready: do swaps that are already stuck in the timeout sweep need recovery at all? A swap only gets there if a backup fee variant of the HTLC tx confirmed and the swap invoice was never paid. We're checking whether that has actually happened. If it hasn't, I'll keep this PR to the sweep fix plus a dust check on the sweep output. I'd drop the recovery path for already stuck swaps, since review found it adds more state machine complexity than it's worth: an unpersisted sweep hash, a retry path without backoff, and no coverage for neutrino backends.

[hieblmi]

Open question before this is ready: do swaps that are already stuck in the timeout sweep need recovery at all? A swap only gets there if a backup fee variant of the HTLC tx confirmed and the swap invoice was never paid. We're checking whether that has actually happened. If it hasn't, I'll keep this PR to the sweep fix plus a dust check on the sweep output. I'd drop the recovery path for already stuck swaps, since review found it adds more state machine complexity than it's worth: an unpersisted sweep hash, a retry path without backoff, and no coverage for neutrino backends.

Good question. This hasn't happen yet since it requires manual trigger from the server. We hence can remove the recovery path.

[hieblmi]

LGTM!

[hieblmi]

Nonblocking improvement: could we reuse input.FindScriptOutputIndex at the call site instead of adding paysTo? It already checks for an output with the given pkScript and returns (bool, uint32), so we can ignore the index. input is already imported, and this would let us remove this helper and the new bytes import.

[claravanstaden]

Done! :)

[hieblmi]

One recovery edge case: if lnd’s historical spend scan fails (e.g. a transient getblock error), it leaves the scan marked pending. Canceling the subscription and re-registering after our timeout does not restart that scan, so refund sweeping can stay stuck until lnd restarts.

A minimal mitigation would be to fall back to ListTransactions when waitForSpend times out: accept only a confirmed transaction spending the exact requested outpoint, then retain the existing HTLC/output validation. If no match is found, keep the current retry behavior. This avoids DB/FSM changes, though it cannot guarantee recovery when the wallet does not know the transaction; the underlying scan-retry bug still needs an lnd fix.

[claravanstaden]

@hieblmi thanks, good catch. I changed it to use lnd's ListTransaction in case the chain notifier lookup fails.

[hieblmi]

Re-reviewed at 3d4e29a. The wallet fallback addresses the historical spend-scan issue: it accepts only a confirmed transaction spending the exact outpoint, retains HTLC input/output validation before signing, and preserves retry behavior when no wallet spend is found. Also rechecked the fee variants, dust guard, and already-spent sweep handling. No remaining blockers found. Validation: go test -race ./staticaddr/loopin passed locally; current CI checks are green.