Published on: 2012-06-23T00:10:57+00:00
The speaker in this context has previously made comments regarding references to the wallet version, specifically mentioning nFileVersion. Since then, they have successfully updated both the nFileVersion and the actual wallet version. However, an issue still persists where the wallet rescans the last 14,000+ blocks every time it is invoked, which seems unnecessary. The speaker cannot provide an explanation for why this occurs multiple times. To address this problem, the speaker intends to transfer the balance from their old wallets (version 10500) to a new wallet in the near future.The writer suspects that there may be a bug related to the order of operations when it comes to rescanning, wallet upgrades/imports, and the markers for the last block. They inserted an old wallet into a current blockchain and ran it in rescan mode, resulting in a message indicating an old wallet version. Subsequently, the entire chain was rescanned, with certain blockhashes and blocks that were out of range or contained invalid/nonwallet transaction IDs being added to the wallet. These transactions were already present as legitimate ones in the old logs. When running the wallet in plain mode, the new wallet version was logged and the last 20k blocks (approximately) were rescanned, potentially serving as the marker for the last use of the old wallet. In subsequent runs, the second scan was duplicated, although it did not display the message 'upgrading wallet' as it sometimes does. The writer always used the detach=1 command. They question why the last 20k blocks need to be scanned again if the entire chain has already been processed, suggesting that it should only occur once if not more. Additionally, they propose that dumping the run parameters (bitcoin.conf, cmdline) to the log would be helpful, and recommend that the log should not be automatically truncated when it becomes too large, but rather appended or rolled.In summary, the speaker has encountered an issue where the wallet rescans the last 14,000+ blocks every time it is invoked, despite having updated both the nFileVersion and the wallet version. They plan to transfer the balance from their old wallets to a new one to avoid this problem. The writer suspects a bug related to the order of operations in the context of rescanning, wallet upgrades/imports, and last block markers. They have observed duplicated scans of the last 20k blocks and question why this is necessary if the entire chain has already been processed. Additionally, they suggest including run parameters in the log and changing how the log is handled when it becomes large.
Updated on: 2023-08-01T03:43:04.630963+00:00