Since the reorg-aware txconfirm lifecycle landed, a TxConfirmed
delivery is provisional and the boarding-sweep durable bookkeeping (the
boarding_sweeps row flipping to confirmed, the ledger fee entry, and
the in-memory watch teardown) only commits on TxFinalized, which the
chain backends synthesize at chainsource.DefaultFinalityDepth = 6
inclusive confirmations.
To be clear about the blast radius: nothing operational gates on that
status. The sweep broadcasts immediately, the swept coins are ordinary
wallet UTXOs spendable under the wallet's own confirmation policy, and
the only consumer of the confirmed status is
isTerminalSuccessSweepStatus (the guard that stops a spurious late
TxFailed from rolling back already-booked accounting). What users see
is purely observability lag: ListBoardingSweeps reports published
for ~an hour on mainnet before flipping, and the ledger fee entry books
equally late. Downstream test suites also need to know about the
horizon — the lumos itests had to bump their post-broadcast mining from
3 to 6 blocks so the terminal status becomes observable at all
(lightninglabs/lumos#680).
For the upcoming reorg PR series: consider whether the durable
bookkeeping should instead commit on first confirmation and repair on
TxReorged (act-then-repair), rather than waiting out the full
reorg-safety horizon (wait-then-act). The general design lean elsewhere
in the daemon is to take the next action as soon as a confirmation
lands and treat reorgs as the exceptional path to recover from; the
sweep bookkeeping is currently the odd one out. If wait-then-act stays,
the finality depth should probably become configurable (regtest/test
rigs want 1-2) and the RPC could surface a distinct finalizing state
so the long published window doesn't read as a stuck sweep.
Related surfaces already reconciled to the lifecycle in #972: the
unroll subscriber maps TxFinalized to an idempotent confirmation
(it used to terminally fail the job) and drops best-effort TxReorged;
the wallet's log-only sweep subscriber treats finality as a repeat
confirmation. Whatever shape the redesign picks, those adapters and the
boarding-sweep classifier should move together.
Since the reorg-aware txconfirm lifecycle landed, a
TxConfirmeddelivery is provisional and the boarding-sweep durable bookkeeping (the
boarding_sweepsrow flipping toconfirmed, the ledger fee entry, andthe in-memory watch teardown) only commits on
TxFinalized, which thechain backends synthesize at
chainsource.DefaultFinalityDepth = 6inclusive confirmations.
To be clear about the blast radius: nothing operational gates on that
status. The sweep broadcasts immediately, the swept coins are ordinary
wallet UTXOs spendable under the wallet's own confirmation policy, and
the only consumer of the
confirmedstatus isisTerminalSuccessSweepStatus(the guard that stops a spurious lateTxFailedfrom rolling back already-booked accounting). What users seeis purely observability lag:
ListBoardingSweepsreportspublishedfor ~an hour on mainnet before flipping, and the ledger fee entry books
equally late. Downstream test suites also need to know about the
horizon — the lumos itests had to bump their post-broadcast mining from
3 to 6 blocks so the terminal status becomes observable at all
(lightninglabs/lumos#680).
For the upcoming reorg PR series: consider whether the durable
bookkeeping should instead commit on first confirmation and repair on
TxReorged(act-then-repair), rather than waiting out the fullreorg-safety horizon (wait-then-act). The general design lean elsewhere
in the daemon is to take the next action as soon as a confirmation
lands and treat reorgs as the exceptional path to recover from; the
sweep bookkeeping is currently the odd one out. If wait-then-act stays,
the finality depth should probably become configurable (regtest/test
rigs want 1-2) and the RPC could surface a distinct
finalizingstateso the long
publishedwindow doesn't read as a stuck sweep.Related surfaces already reconciled to the lifecycle in #972: the
unroll subscriber maps
TxFinalizedto an idempotent confirmation(it used to terminally fail the job) and drops best-effort
TxReorged;the wallet's log-only sweep subscriber treats finality as a repeat
confirmation. Whatever shape the redesign picks, those adapters and the
boarding-sweep classifier should move together.