It is possible to have a wallet.dat file without any bestblock record at all (if created offline, for example), which - when loaded into a client with a up-to-date chain - does no rescan and shows no transactions.
Also make sure to write the current best block after a rescan, so it isn't necessary twice.
It is possible to have a wallet.dat file without any bestblock
record at all (if created offline, for example), which - when
loaded into a client with a up-to-date chain - does no rescan and
shows no transactions.
Also make sure to write the current best block after a rescan, so
it isn't necessary twice.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/2aceeb01a9b0b0c6bfa0d56211453e87bc33d6e4 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
ACK.
Tested by removing the bestblock record from a -testnet wallet.
ACK
Looks like if you delete your wallet after Bitcoin creates the new one it triggers a rescan of every block.
Indeed, I'll look at this. It's not a regression though, before there was just a chance of missing stuff, as no accurate bestblock was written either.
The solution is doing an explicit write of the bestblock record at wallet unload/exit time.
If we knew the bestblock at the time we created the wallet (I don't think we've loaded the chain at that point) it would be simple to just have it set the best block to be the current best block when creating it.
Another possible fix is doing the key birthday thing and using the min(birthday) to control the rescan.