sweepbatcher: fix reorg detection #975

starius · 2025-07-09T04:40:06Z

The reorg channel is now passed to RegisterSpendNtfn, and waiting for spend notifications remains active even after the transaction receives its first confirmation. The dedicated goroutine previously used to wait for the spend is no longer needed, as we now handle both spend and potential reorg events in the main event loop while the batch is running.

Following this change, RegisterConfirmationsNtfn runs without a reorg channel, as it would only detect deep reorgs that undo the final confirmation - something we can't handle anyway. We can't track fully confirmed swaps indefinitely to guard against such rare reorgs; instead, we can mitigate the risk by increasing the required confirmation depth.

Also changed sweepbatcher to update feerate independently of AddSweep as well. AddSweep may not be called after getting the first confirmation, but feerate updates are still needed in case of reorg. Update test TestFeeRateGrows not to call AddSweep again and make sure feerate is updated itself.

Pull Request Checklist

Update release_notes.md if your PR contains major features, breaking changes or bugfixes

hieblmi

This LGTM! I just have a question about the behavior of RegisterSpendNtfn in case a reorg happens.

hieblmi · 2025-07-21T08:43:49Z

sweepbatcher/sweep_batch.go

 				return fmt.Errorf("handleSpend error: %w", err)
 			}

+		case err := <-b.spendErrChan:


unrelated to this, but since the Run method is quite long, could we move the code at the beginning for around initialDelay and initialDelayChan into a separate function?

initialDelay, initialDelayChan and related variables in the beginning of Run are too connected to each other. In the current version they are all local and it is easy to follow the logic of waiting. How to factor out these variables without sacrificing readability?

I updated the last commit: factored out feerate updates to updateFeeRate method.

hieblmi · 2025-07-21T09:02:17Z

sweepbatcher/sweep_batch.go

-		spendCtx, &primarySweep.outpoint, primarySweep.htlc.PkScript,
+	reorgChan := make(chan struct{}, 1)
+
+	spendChan, spendErrChan, err := b.chainNotifier.RegisterSpendNtfn(


Will RegisterSpendNtfn keep spendChan and spendErrChan open and signal spends/errors after the reorg chan fired?
I assume yes, so this is a nice simplification of the spend-handling flow.

Yes, I added an itest for LND to check this: lightningnetwork/lnd#10083

hieblmi · 2025-07-21T09:12:01Z

sweepbatcher/sweep_batcher.go

+}
+
+// minimumSweepFeeRate determines minimum feerate for a sweep.
+func minimumSweepFeeRate(ctx context.Context, customFeeRate FeeRateProvider,


great that you ensured that AddSweep and Run in the reorg case call the same fee rate estimates.

bhandras

LGTM 🎉 (just one comment regarding conf target!)

bhandras · 2025-07-22T12:56:53Z

test/chainnotifier_mock.go

 	"github.com/lightninglabs/lndclient"
 	"github.com/lightningnetwork/lnd/chainntnfs"
 	"github.com/lightningnetwork/lnd/lnrpc/chainrpc"
-	"golang.org/x/net/context"


Ugh, nice catch!

bhandras · 2025-07-22T13:09:22Z

sweepbatcher/sweep_batch.go

-		case <-ctx.Done():
-		}
-	}()
+	b.spendChan = spendChan


Nice simplification. I'd add a comment that this is safe to do as we're always calling monitorSpend from the runloop's goroutine.

Thanks! I added the comment.

bhandras · 2025-07-22T13:24:14Z

sweepbatcher/sweep_batcher.go

+		return minFeeRate, nil
+	}
+
+	if sweepConfTarget == 0 {


LND's walletkit will fail with conftarget of 0 or 1. A way around would be override it to 2 if smaller?

I added this check in a separate commit. Note that this check is unlikely to fire, since this is already fixed in GetConfTargetAndFeeRate.

Since bb837a4 AddSweep loads sweeps so one of possible errors is sql.ErrTxDone. Full error that is fixed: > fetchSweeps failed: failed to load sweep 0000000000000000000101:1: > failed to fetch sweep data for 010101000000: > failed to fetch loop out for 010101000000: > sql: transaction has already been committed or rolled back

The reorg channel is now passed to RegisterSpendNtfn, and waiting for spend notifications remains active even after the transaction receives its first confirmation. The dedicated goroutine previously used to wait for the spend is no longer needed, as we now handle both spend and potential reorg events in the main event loop while the batch is running. Following this change, RegisterConfirmationsNtfn runs without a reorg channel, as it would only detect deep reorgs that undo the final confirmation - something we can't handle anyway. We can't track fully confirmed swaps indefinitely to guard against such rare reorgs; instead, we can mitigate the risk by increasing the required confirmation depth.

AddSweep may not be called after getting the first confirmation, but feerate updates are still needed in case of reorg. Update test TestFeeRateGrows not to call AddSweep again and make sure feerate is updated itself.

This is already done in GetConfTargetAndFeeRate. The fix is just a double check.

starius force-pushed the spend-reorgs branch 2 times, most recently from 7763774 to c7f22b7 Compare July 9, 2025 05:33

starius marked this pull request as ready for review July 9, 2025 05:48

starius requested review from bhandras and hieblmi July 9, 2025 05:49

starius force-pushed the spend-reorgs branch from c7f22b7 to c19d1d5 Compare July 9, 2025 15:22

starius marked this pull request as draft July 9, 2025 17:31

starius force-pushed the spend-reorgs branch from c19d1d5 to 9d795ea Compare July 10, 2025 02:23

levmi assigned starius Jul 10, 2025

starius marked this pull request as ready for review July 15, 2025 04:17

starius force-pushed the spend-reorgs branch from 9d795ea to d67a41b Compare July 16, 2025 18:23

hieblmi approved these changes Jul 21, 2025

View reviewed changes

starius force-pushed the spend-reorgs branch from d67a41b to 49932d9 Compare July 22, 2025 01:40

bhandras approved these changes Jul 22, 2025

View reviewed changes

starius added 6 commits July 24, 2025 02:19

test: golang.org/x/net/context -> context

36c5d6c

loopout: more logging in sweeping code

5c9f6f7

sweepbatcher: update feerate outside AddSweep

8431784

AddSweep may not be called after getting the first confirmation, but feerate updates are still needed in case of reorg. Update test TestFeeRateGrows not to call AddSweep again and make sure feerate is updated itself.

sweepbatcher: minimumSweepFeeRate fixes confTarget

534c71b

This is already done in GetConfTargetAndFeeRate. The fix is just a double check.

starius force-pushed the spend-reorgs branch from 49932d9 to 534c71b Compare July 24, 2025 05:30

starius merged commit bce9b5d into lightninglabs:master Jul 24, 2025
4 checks passed

starius deleted the spend-reorgs branch July 24, 2025 06:12

sweepbatcher: fix reorg detection #975

sweepbatcher: fix reorg detection #975

Uh oh!

Conversation

starius commented Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Pull Request Checklist

Uh oh!

hieblmi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bhandras left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

starius commented Jul 9, 2025 •

edited

Loading