Summary
Adding a standalone address with a rescan resets the whole wallet to genesis (Wallet::reset_wallet_to_genesis, called from WalletRpc::add_standalone_watch_only_address / add_standalone_private_key / add_standalone_multisig). It would be better to scan the chain for the newly added destination without discarding the wallet's scan state and without moving the wallet's best block.
Why
Resetting to genesis makes the operation all-or-nothing and unnecessarily expensive:
- If the rescan is interrupted (process exit, Ctrl-C, node restart, RPC timeout), the wallet is left at genesis and everything scanned so far has to be scanned again. On mainnet that currently means ~673k blocks on every wallet open until one rescan is allowed to finish.
- The wallet already had the full history for its own addresses; it is thrown away to look for one new destination.
- A rescan for a watch-only/multisig address is conceptually independent of the wallet's own sync position, so it does not need to move the best block pointer at all.
If instead the new destination were scanned without resetting, an interrupted scan would cost nothing beyond "the new address's history is not known yet", and the operation could be retried or resumed cheaply.
Context
The immediate bug — that the announced rescan was never actually performed in wallet-cli non-interactive mode, leaving wallets stuck at genesis — is fixed in PR #2107 by syncing synchronously after the reset. That makes the current behaviour correct but keeps the full-reset cost and the "interrupted rescan loses everything" property. This issue tracks removing the reset itself.
Sketch
- Add a scan path in
wallet/src/wallet + wallet/src/account that scans a block range for a given set of destinations and records the resulting transactions/UTXOs, without calling scan_genesis on the accounts or updating their best block.
- Use it from the three
add_standalone_* methods instead of reset_wallet_to_genesis().
- Keep
wallet_rescan as is — a full reset is the point of that command.
Summary
Adding a standalone address with a rescan resets the whole wallet to genesis (
Wallet::reset_wallet_to_genesis, called fromWalletRpc::add_standalone_watch_only_address/add_standalone_private_key/add_standalone_multisig). It would be better to scan the chain for the newly added destination without discarding the wallet's scan state and without moving the wallet's best block.Why
Resetting to genesis makes the operation all-or-nothing and unnecessarily expensive:
If instead the new destination were scanned without resetting, an interrupted scan would cost nothing beyond "the new address's history is not known yet", and the operation could be retried or resumed cheaply.
Context
The immediate bug — that the announced rescan was never actually performed in
wallet-clinon-interactive mode, leaving wallets stuck at genesis — is fixed in PR #2107 by syncing synchronously after the reset. That makes the current behaviour correct but keeps the full-reset cost and the "interrupted rescan loses everything" property. This issue tracks removing the reset itself.Sketch
wallet/src/wallet+wallet/src/accountthat scans a block range for a given set of destinations and records the resulting transactions/UTXOs, without callingscan_genesison the accounts or updating their best block.add_standalone_*methods instead ofreset_wallet_to_genesis().wallet_rescanas is — a full reset is the point of that command.