AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 19 Bitcoin

Merge bitcoin/bitcoin#34681: wallet: move rescan logic into ChainScanner and wallet/scan

Public commit record

What the developer wrote

Authored by merge-script

91/100 · Strong
Merge bitcoin/bitcoin#34681: wallet: move rescan logic into ChainScanner and wallet/scan

e67f75cf7d3e5a8f161d1525695c8653d225a01f wallet/scan: extract progress tracking helpers from `ChainScanner::Scan` (Novo)
062aa3ce56d72c03569743aa4142bcec2400bf8f wallet/scan: extract QueueNextBlock (Novo)
3655beb8f1531f780fffcbf2f1018d893b87e98e wallet/scan: extract block scanning logic to ScanBlock (Novo)
4535dc0c7885ad678074699627b363f382f29906 wallet/scan: extract block filter matching to ShouldFetchBlock (Novo)
72a37031d325e9f50bc95ef7496fc495b755962e wallet/scan: move WalletRescanReserver to scan files (Novo)
0274e80130af2cc58847b5d8f3628fa97a6f4b79 wallet/scan: move RescanFromTime to ChainScanner as ScanFromTime (Novo)
db9185a44464b241dec7a20fdedd7142bc728b1e wallet: introduce ChainScanner as a CWallet member (Novo)
525163c2413ed595a6b9adbc682cc182339c0600 wallet/tests: pin rescan behavior (Novo)

Pull request description:

Part of https://github.com/bitcoin/bitcoin/pull/34400

This PR refactors the wallet rescan logic for improved readability and maintainability, and prepares the rescan logic for the changes in https://github.com/bitcoin/bitcoin/pull/34400.

CWallet previously owned all rescan-related concerns: atomic state variables, the WalletRescanReserver RAII type, RescanFromTime, and the entire block-scanning loop (ScanForWalletTransactions) as a single large member function.

This PR separates those concerns into a dedicated ChainScanner class, introduced in wallet/scan.h and wallet/scan.cpp:

- Scan state (fAbortRescan, fScanningWallet, progress, start time, passphrase flag) moves into ChainScanner atomics, exposed through Scanner().
- WalletRescanReserver
- RescanFromTime becomes ChainScanner::ScanFromTime, keeping all scan entry points in one place.
- ScanForWalletTransactions is replaced by ChainScanner::Scan and decomposed into focused helpers: ShouldFetchBlock, ScanBlock, ReadNextBlock, UpdateProgress, UpdateTipIfChanged, and ProcessBlock.

CWallet retains only a ChainScanner member and a Scanner() accessor. Callers that previously reached into CWallet for scan state now go through Scanner().

One slight behaviour change is introduced in this PR and is documented in the associated commit message. We previously attempted to read the block to scan before checking that it is active; now we check that it is active before the read attempt. It has no significant effect, but the change is documented.

This PR should be reviewed with the `--color-moved=dimmed-zebra` git option to aid review.

ACKs for top commit:
achow101:
ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f
polespinasa:
re-ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f
pablomartin4btc:
ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f
rkrux:
lgtm ACK e67f75cf7d3e5a8f161d1525695c8653d225a01f

Tree-SHA512: 7c59bcf71ca94365bfceccdeb0aa187434405dc24ddde327b645d59a7e9d036d28fa0858bb093810ce70d67162f463f5cd4020392dda3da3a88ae2393b235211
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This is a code cleanup change in Bitcoin Core's wallet. It moves the wallet's blockchain rescan logic out of the main CWallet class into a new dedicated ChainScanner class, without changing what the rescan does. The only intentional behavior change is the order of two internal checks: the code now verifies a block is still on the active chain before trying to read it, rather than after. The change is documented and tested, and appears to reduce risk rather than introduce it.

Recommended action

No immediate action required. Treat as routine maintenance/refactor. Reviewers should verify the documented order-of-operations change does not affect rescan failure reporting in edge cases (e.g., pruned blocks that are also no longer active).

Security signals we found

01

Refactor only: no new network surface, no new RPCs, no cryptographic changes

02

One documented behavior change: active-chain check now precedes block read in rescan loop

03

New test explicitly validates reorged-block handling: filter-matched stale block causes FAILURE; filter-skipped stale block returns SUCCESS

04

WalletRescanReserver reservation/abort semantics preserved and tested

05

No vendor security disclosure or CVE referenced in commit or supplied materials

Risk score

Why this scored 19/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 3/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.