wallet/wallet: prevent always rescanning from birthday block
In this commit, we address an issue with the wallet where it would always request a rescan from the birthday block. This is very crucial for older wallets, as it'll potentially go through thousands of blocks. To address this, we'll now only request a rescan from our birthday if we're recovering our wallet from our seed, the birthday block was rolled back, or if we're performing our initial sync. Otherwise, we'll request a rescan from tip.
This commit is contained in:
parent
4c01c0878c
commit
4f5baed780
1 changed files with 12 additions and 1 deletions
|
@ -653,8 +653,10 @@ func (w *Wallet) syncWithChain(birthdayStamp *waddrmgr.BlockStamp) error {
|
|||
// If a birthday stamp was found during the initial sync and the
|
||||
// rollback causes us to revert it, update the birthday stamp so that it
|
||||
// points at the new tip.
|
||||
birthdayRollback := false
|
||||
if birthdayStamp != nil && rollbackStamp.Height <= birthdayStamp.Height {
|
||||
birthdayStamp = &rollbackStamp
|
||||
birthdayRollback = true
|
||||
|
||||
log.Debugf("Found new birthday block after rollback: "+
|
||||
"height=%d, hash=%v", birthdayStamp.Height,
|
||||
|
@ -681,9 +683,18 @@ func (w *Wallet) syncWithChain(birthdayStamp *waddrmgr.BlockStamp) error {
|
|||
return err
|
||||
}
|
||||
|
||||
// If this was our initial sync, we're recovering from our seed, or our
|
||||
// birthday was rolled back due to a chain reorg, we'll dispatch a
|
||||
// rescan from our birthday block to ensure we detect all relevant
|
||||
// on-chain events from this point.
|
||||
if isInitialSync || isRecovery || birthdayRollback {
|
||||
return w.rescanWithTarget(addrs, unspent, birthdayStamp)
|
||||
}
|
||||
|
||||
// Otherwise, we'll rescan from tip.
|
||||
return w.rescanWithTarget(addrs, unspent, nil)
|
||||
}
|
||||
|
||||
// defaultScopeManagers fetches the ScopedKeyManagers from the wallet using the
|
||||
// default set of key scopes.
|
||||
func (w *Wallet) defaultScopeManagers() (
|
||||
|
|
Loading…
Reference in a new issue