Old wallet migration: sanity checks

[takuma sato]

Could you please describe all possible sanity checks you should perform in order to triple check the migration from an old 2013 wallet to the latest wallet format is successful?

Also just curious as to how old could the wallet be for the migration tool on the GUI to work? I mean, could satoshi just show up with a 2009 wallet and it would successfully migrate to a new wallet or if it's too old it wouldn't work? I assume there is a way since Core 30 is going to deprecate non descriptor wallets (im running Knots so im not sure what will be done with this)

Im still a bit paranoid about doing this. Im used to the old wallet and how it works since I have heard some theoretical arguments as far as possible derivation attacks being more possible with new format but PSBT feature is really useful so im debating about this.

[DireWolfM14]

As long as you're confident that you downloaded bitcoin core from the official Bitcoincore.org site, and follow the instructions to verify the download, you can be confident that you have the real software, and not malware.  You should be able to import your old wallet without any issue.

Here're my instructions on how to verify on Windows:
https://bitcointalk.org/index.php?topic=5528029.msg65003133#msg65003133

If you just want to import an old private key, the steps are bit more complicated, but here's a set of instructions I put together:
https://bitcointalk.org/index.php?topic=5545286.msg65435592#msg65435592

[BattleDog]

You're fine to migrate even from very old wallets. Core still opens legacy BerkeleyDB wallets and the current builds include a one-click / RPC migration to descriptor wallets. If you showed up with a 2009 wallet.dat, it would load; what takes time is the rescan, not the file age.

If this were mine, my sanity path would be: first make multiple offline backups of the original wallet.dat and write down a SHA256 of each copy so you can prove they're identical later. Open it on a machine that's offline (or start Core with networking disabled) just to check getwalletinfo, getaddressesbylabel, and that your expected receive addresses and labels are there. If your node is pruned, do the migration on a full node so the post-migration rescan can actually find everything.

Then use the built-in migration (GUI button or migratewallet) to convert to descriptors and let it rescan. After it finishes, make another backup of the migrated wallet. Verify by listing the active descriptors and spot-checking a few funded addresses. At this point you can simply keep using the migrated wallet, but for maximum peace of mind I like to sweep: create a brand-new descriptor wallet, do a tiny test PSBT spend to it, confirm the change goes to an address you control, then move the rest. Keep the legacy wallet backed up forever and stop touching it.

[nc50lc]

Could you please describe all possible sanity checks you should perform in order to triple check the migration from an old 2013 wallet to the latest wallet format is successful?
-snip-
Im still a bit paranoid about doing this.

I've already covered the necessary steps in your other thread
So I'll just add this important note that you need to get rid of that uncertainty in the migration process:

Remember that your wallet.dat contains private keys, not your bitcoins.
And a private key is just a number. Basically, your wallet.dat is numbers written in a file.

So in an unlikely event of a disastrous failed migration, it's just a copy of your private keys that would be unusable, a failed attempt wont mess with your total balance.
A backup (that everyone suggested) will ensure that you can do it as many times as you want without the risk of losing your coins.

Im used to the old wallet and how it works since I have heard some theoretical arguments as far as possible derivation attacks being more possible with new format but PSBT feature is really useful so im debating about this.

If this is about the unhardened addresses that the descriptor wallets is using,
Then it's easily mitigated by not exporting any private key from your cold-storage wallet to an online environment that can potentially be exposed to an attacker.
The old non-HD loose keys are unaffected by it, each of those should be "hacked" separately.

[takuma sato]

You're fine to migrate even from very old wallets. Core still opens legacy BerkeleyDB wallets and the current builds include a one-click / RPC migration to descriptor wallets. If you showed up with a 2009 wallet.dat, it would load; what takes time is the rescan, not the file age.

If this were mine, my sanity path would be: first make multiple offline backups of the original wallet.dat and write down a SHA256 of each copy so you can prove they're identical later. Open it on a machine that's offline (or start Core with networking disabled) just to check getwalletinfo, getaddressesbylabel, and that your expected receive addresses and labels are there. If your node is pruned, do the migration on a full node so the post-migration rescan can actually find everything.

Then use the built-in migration (GUI button or migratewallet) to convert to descriptors and let it rescan. After it finishes, make another backup of the migrated wallet. Verify by listing the active descriptors and spot-checking a few funded addresses. At this point you can simply keep using the migrated wallet, but for maximum peace of mind I like to sweep: create a brand-new descriptor wallet, do a tiny test PSBT spend to it, confirm the change goes to an address you control, then move the rest. Keep the legacy wallet backed up forever and stop touching it.

It's not so easy as I expected, see this:

https://bitcointalk.org/index.php?topic=5559987.msg65838895#msg65838895

[takuma sato]

So I have been busy with other things and did not finish doing this whole thing and I recently saw how there has been some insane bug that would delete your wallet file during migration. Just wanted to check here if I was no affected. I assume I was not because the wallet file was not deleted, however, the migration was done on the airgap setup with no internet, and I didn't find the time to finish setting up the watch-only wallet to confirm the funds are there, but even without syncing, I was able to load the wallet and I saw the transaction history, however like I said, I still need to create a watch-only wallet for the wallet, but now with this bug im paranoid.

Just to confirm, if I used a pre-30 Knots version, I should be fine right?

If im update to the latest Knots version (29.3.knots20260210) does this include the fixes? I assume they do as here there is a lot of mentions of the migration thing:

https://github.com/bitcoinknots/bitcoin/blob/v29.3.knots20260210-release-notes/doc/release-notes.md

In any case, I find this whole thing ridiculous. Like, did the bug delete all wallet.dat files? or only the ones inside the wallet folder?

Like let's say:

.bitcoin/wallets/wallet1/wallet.dat

If you tried to migrate with Core 30, and you meet al criteria (pruned mode and a few other things I can't remember now) then the file wallet.dat inside wallet1 would be deleted? or it would even delete all .dat files inside any folder in .bitcoin/wallets ??

Why isn't there a backup system before anything even happens? Like just copy and paste the file in a new folder called /backups/ and guarantee it does not overwrite any existing files. I don't get it. A crazy bug in any case. Luckily I think I wasn't affected and the migrated wallet.dat file is in good standings and not corrupted in any way.. I hope? I will try to get the watch-only wallet for this done and see if all the funds show up.

I do have backups on other devices, but I was in the middle of moving backups and so on, so this is scary in any case.

[nc50lc]

If im update to the latest Knots version (29.3.knots20260210) does this include the fixes? I assume they do as here there is a lot of mentions of the migration thing:

It's resolved in that version, not that Knots is affected in the first place.
Newer versions that has this commit should have the fix to the back-ported wallet migration-related bugs.
commit: /bitcoinknots/bitcoin/commit/115172ceb893f6ec6c043ada85160628802009d8

Why isn't there a backup system before anything even happens? Like just copy and paste the file in a new folder called /backups/ and guarantee it does not overwrite any existing files. I don't get it.

There's an auto-backup scheme, but the thing is, it's saved inside the same directory of the to-be-migrated wallet.dat file.
If the bug occurs, it includes the provided relative wallet path or entire wallet directory path so it includes the backup.