Wallet migration issue in Bitcoin Core versions 30.0 and 30.1

@BitcoinNewsCom Heads up: The Bitcoin Core dev team just put out a warning about a bug related to wallet migration in versions 30.0 and 30.1. This could lead to users losing their funds if they're moving from really old Bitcoin Core wallets that haven’t been renamed or updated.

Imagine running a very old legacy wallet for all those years without having a backup, and then finally deciding to upgrade your only version of your wallet. I have no doubt those people still exist, but damn!

I hope these reach as many as possible before they make regretful decision, but why will someone literally do something like this , I guess some might have backed up theirs before but lost it unknowingly to them.

Yeah I have always backed mine up, multiple times, I have to be honest. I moved all my Legacy address Bitcoin to Segwit a couple of years ago. I think the next time we will have to move coins for something other than selling is if Quantum becomes an actual threat. I haven’t read up in too much detail but I believe there will be Quantum Proof addresses or a patch to avoid any potential losses. That’s a discussion for another day any way but I thought it was the right thing to post this here after seeing it, even if like you said, only a few people are careless enough to not have backups.

It's been two weeks since the reports were posted on Github https://github.com/bitcoin/bitcoin/issues/34128#issue-3750246491; there could be more damage or maybe less. I think an old legacy user ought to know the importance of wallet back up than anyone. If you know the process, the wallet migration, wallet back up will be the first thing that will comes to your mind before you even start.

Why doesn't Bitcoin Core do this by default? Instead of overwriting your wallet.dat, shouldn't the default behaviour be to rename it to wallet.backup20260501.dat before creating a new wallet.dat?

It does. The problem is that the backups are stored in a directory that is accidentally deleted by the bug as well. Obviously this is a major bug and it took a little while to figure out the scope of the issue.

Terrible prospect, I can’t even imagine this with Bitcoin Core. Luckily, I use Bitcoin Core 30.0 solely as a node, not as the wallet. My stash is controlled by hardware wallet, namely Passport Core. But the chance that someone could be caught by this bug if they haven’t been already isn’t zero. Brrrr.

Wallet Migration Failure May Delete Unrelated Wallet Files In Bitcoin Core 30.0 and 30.1 We have become aware of a wallet migration bug introduced in Bitcoin Core 30.0 and 30.1. Under rare circumstances, when the migration of a wallet.dat file fails, all files in the wallet directory may be deleted in the process, potentially resulting in a loss of funds. A fix is forthcoming and will be released as 30.2, but out of an abundance of caution we have removed the binaries for affected releases from bitcoincore.org. At this time, we ask users to not attempt wallet migrations using the GUI or RPC until v30.2 is released. All other users, including existing wallet users, are unaffected and can keep using existing installations. Specifically, it requires the presence of a default (unnamed) wallet.dat file, which has not been created by default since 0.21 (released 5 years ago), that fails to be migrated or loaded. One condition that may trigger this is when pruning is enabled, and the wallet was unloaded while pruning happened. https://bitcoincore.org/en/2026/01/05/wallet-migration-bug/

What are the odds: this pretty much describes my current wallet! But I have no intention to upgrade yet, I like the possibility of easily importing a private key when needed. And of course I have backups.

I don’t like to upgrade very often but I did upgrade to 29.0 not long back because of all the Knots nonsense going on. I just wanted to make sure I was pre 30.0 as I had a feeling there could be problems. As for importprivkey, I have ‘t done that for a very long time but literally only became aware a few days ago after reading on here that the process has changed to a slightly more techie way of doing it. I don’t know why that was messed with, it was fine as it was.

Luckily, I'm not affected by this since I'm still using v29.0. Good thing that the previous migration process of v29 and below isn't affected since I've used it a few times and it never failed, Or is it? I'm not persuading you to upgrade but it should be easy for you to learn the new importdescriptors command to import WIFs wrapped as single-key descriptors. Once you get the hang of it, it should be simple enough to do within a minute (excluding rescan of course)

I've seen your posts explaining it, and I can do it, but it feels so pointless to upgrade to something that makes a basic task 30 times more work. I'll upgrade after they make a single command to import them

This particular bug is not reachable on 29.x and earlier.

I don't get the resistance to use importdescriptors as you describe it with modern descriptor wallet versions of Core. It's actually not very hard and if you use e.g. the combo(WIF) descriptor your wallet "understands" all major standard public address types, except Tapscript to my knowledge, that a single private key can derive (P2PK, P2PKH, P2WPKH and P2SH-P2WPKH). "Understands" meaning your wallet would recognize coins sent to any of the four redeem script types. There's really no need to use ancient Bitcoin Core versions just to import single private keys. It's a piece of cake with modern descriptor wallets once you get the hang of it as nc50lc described. I admit it took me some time to get "the hang of it", too. There are some good posts in this forum about descriptors and how to use them and then it's a matter of doing it and getting confident with 'em. Needless to repeat: do your stuff with "open" private keys always in a safe environment (e.g. disposable live Linux running only in RAM; no persistent storage that could be exploited). Play with Testnet to avoid costly mistakes.

Maybe you misunderstand my post in some way? Misquote perhaps? Because I haven't mentioned any resistance about using importdescriptors command. In fact, I even described that it's easy to learn (based on LoyceV's expertise) and the next snipped sentence says that it will not take a minute to do.

That's kinda my point: I don't want to have to do this, for something that was so simple. So I see no reason to upgrade, and if I do, I may just switch to Electrum permanently. But it's not even a big deal, as I barely deal with private keys.

I didn't want to say that you were speaking of or having a resistance towards descriptors. I meant that other users are reluctant and have some resistance to get in touch and deal with descriptors. Yes, it may have a bit of a learning curve but it's doable. There's not much heavy lifting involved as there are some good brief usage examples here in the forum or elsewhere. At first I wasn't amused when deprecation of importprivkey or dumpprivkey and similar RPCs were announced (for legacy wallets). But once I learned to use descriptors, it wasn't really a problem anymore. I don't have to do a lot with private keys outside my software and hardware wallets. It's just that I want to know and be able to use proper tools if I had to.

Can someone please answer me a simple question? Why doesn't Bitcoin Core just support a mnemonic solution? What's acting as obstacle to the BIP39 proposal? Every reputable wallet software supports it. Most people that take self-custody seriously use seed phrases. What's the justification for the most reputable Bitcoin client not to support some sort of seed phrase scheme? This kind of bug is pretty much the point we're using seed phrases, and the holders who lost their coins this way could still have access if they had a seed phrase written down. It's just a no-brainer to me.

While your question is off-topic to this thread, I would give you this answer. If Core would support to create a wallet based on BIP39 recovery words and derivation paths, it would limit such a wallet to only support the keys that such a wallet could derive. You shouldn't be able to add more private keys to such a wallet because that would mean, you couldn't restore your wallet completely by the mnemonic recovery words alone. I guess Core devs or whoever steers the development don't want such a limitation. And frankly I'm fine with that. I wouldn't want Core to be limited by above described scenario. Btw, it's perfectly possible to create a descriptor wallet in Core that completely matches a BIP39 derived wallet. You do this by importing the appropriate descriptors for receiving and change addresses derivation paths of the xpriv master key derived from BIP39 recovery words and appropriate derivation path for the desired address type. You could even have a descriptor wallet that matches a BIP39 wallet but recognizes all public address types at once which is rarely seen with other BiP39 compatible wallets. You can't do all the steps with Core alone, you need to do the BIP39 derivation to the appropriate xpriv master key outside of Core. Core is older than HD wallets and BIP39 wallets aren't the best, last and only solution to those.