Checking sanity before migrating old wallets

Can anyone break down all the sanity checks I should do to make sure that moving my old 2013 wallet to the latest version goes smoothly? Also, I’m kinda curious what’s the oldest wallet that the migration tool can handle in the GUI? Like, if Satoshi popped up with a 2009 wallet, would it migrate just fine, or is there a cutoff where it wouldn’t work? I’ve heard that since Core 30 is dropping support for non-descriptor wallets (I’m on Knots, so I’m not clear on what’s going to happen there). Honestly, I’m still a bit nervous about this whole thing. I’m used to how my old wallet operates, and I’ve caught wind of some theories about potential derivation attacks with this new format. The PSBT feature seems pretty handy though, so I’m torn on what to do.

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

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.

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. 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.

It's not so easy as I expected, see this: https://bitcointalk.org/index.php?topic=5559987.msg65838895#msg65838895

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.

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 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.