When sync hit a reorg it stepped the scan back to just before the
invalidated block, then set the top of the re-scan range to that
point plus the full forward batch size. That window is far larger
than any reorg can be: the batch size is tuned for forward streaming
(tens of thousands of blocks), while a reorg is capped at the maximum
reorg depth and the pass aborts once it is exceeded. So the recovery
pass re-fetched and re-scanned a large span of already-good blocks
before it could resume moving forward.
- The recovery range now reaches only the maximum reorg depth (plus
one) above the rewind point, which is the most a reorg can ever
disturb. Forward syncing still uses the full batch size; only the
pass immediately after a reorg is bounded this way.
- The set of blocks that ultimately get scanned is unchanged - the
next pass picks up from where recovery stops - so the resulting
wallet is identical, just reached with far less redundant fetching
and scanning.
The wallet file format is unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
DanSandClaude Opus 4.8
be69c9bafe