Help with legacy wallet.dat recovery (bounty)

[anon743294]

I used Bitcoin Core to create a wallet.dat in probably around 2014 (pre-HD, that is). I bought some Bitcoin from an exchange in a few different times and stored those in that wallet. The wallet is encrypted. I have the wallet.dat and I have its passphrase.

The problem is, I didn't know you need to create a new backup of the wallet.dat any time you spend Bitcoin from it. I had ass-u-med, you only need to backup it, after you receive more coins to it.

I had my Bitcoin Core and my wallet on a dedicated Linux laptop that I updated to a new Linux distribution, at which time I lost the currently in use copy of wallet.dat, I only have the original copies of it.

After I realized my mistake (i.e. copying the original wallet.dat to a new computer and using Bitcoin Core again, and the wallet showing almost zero balance), I used a live Linux USB to create a disk image of the laptop's drive using the dd command. I have used different file recovery tools, such as PhotoRec to recover files from that disk image.

I have a couple of recovered files that look like they could be the lost, updated version of the wallet.dat.

The restored wallet files are about 1 MB in size, while the original wallet.dat copy is about 115 KB in size. I have used a binary file comparison tool to see how the files look, and the recovered 1 MB wallets have identical content for the first 115 KB bytes, and after that, new content. The new content doesn't look like random mess, but it looks similar to the other content of the original wallet file.

I have tried to use bitcoin-cli (of Bitcoin Core 28.1) to load up the recovered wallet, and I have tried the Bitcoin Core's "bitcoin-wallet salvage" method as well. Neither have been able to load the restored wallet, so clearly there is some corruption there.

I have tried to use pywallet to dump the private keys from the restored wallet but that fails as well. I'm using Linux (Fedora 42).

I'm offering a bounty of $200 to anyone who helps me to recover the coins. If the recovery happens with help of multiple people, they all will receive the bounty.

[LoyceV]

The problem is, I didn't know you need to create a new backup of the wallet.dat any time you spend Bitcoin from it.

I don't think that's entirely accurate. It was for the earliest version of Bitcoin-qt, but they quickly added a 100 key "pool": the wallet.dat would create 100 unused private keys, so your backup would still be valid for a while. But if you set or changed a password, those 100 keys would be replaced by new ones and a new backup was indeed required.

I had ass-u-med, you only need to backup it, after you receive more coins to it.

Each time you sent a transaction, the change was sent to a new address in your wallet. So it's kinda like receiving coins.

I have used different file recovery tools, such as PhotoRec to recover files from that disk image.
~
I have tried to use pywallet to dump the private keys from the restored wallet but that fails as well.

Instead of using other recovery software first, have you tried to use pywallet on the partition (image) directly? See [GUIDE] Recover your deleted keys.

[anon743294]

The problem is, I didn't know you need to create a new backup of the wallet.dat any time you spend Bitcoin from it.

I don't think that's entirely accurate. It was for the earliest version of Bitcoin-qt, but they quickly added a 100 key "pool": the wallet.dat would create 100 unused private keys, so your backup would still be valid for a while. But if you set or changed a password, those 100 keys would be replaced by new ones and a new backup was indeed required.

Indeed, this is as much as I learned after I started to figure out what could be the reason why my balance was showing almost zero. And I have not made many transactions with the wallet to begin with. But nevertheless, Bitcoin-cli shows almost zero balance. I tried to do "bitcoin-cli -rpcwallet=legacy rescanblockchain 0" as well, to see if that would somehow fix the situation, but it didn't help.

Running bitcoind on the original wallet.dat says:

Code:

2025-06-01T06:59:51Z [legacy] Wallet file version = 10500, last client version = 290000
2025-06-01T06:59:51Z [legacy] Legacy Wallet Keys: 0 plaintext, 206 encrypted, 0 w/ metadata, 206 total.

EDIT: I have not changed the password of the wallet since originally creating it.

Instead of using other recovery software first, have you tried to use pywallet on the partition (image) directly? See [GUIDE] Recover your deleted keys.

I have not tried that. Does the pywallet's --recov_device parameter accept a path to the disk image, or do I do something with the disk image first, such as mount it?

[LoyceV]

Does the pywallet's --recov_device parameter accept a path to the disk image, or do I do something with the disk image first, such as mount it?

It probably has an option to use the image instead of partition, or maybe it just works (Everything is a file):

Code:

--recov_device /home/user/file.iso

Alternatively, you could just use the partition on which you saved the image, but that may be much bigger than needed.

[anon743294]

It probably has an option to use the image instead of partition, or maybe it just works (Everything is a file):

Code:

--recov_device /home/user/file.iso

Alternatively, you could just use the partition on which you saved the image, but that may be much bigger than needed.

At least there was no instant error message when trying to do that, so I now have pywallet with the recover option running, with --recov_device pointing to the image file from the dedicated Linux laptop that hopefully contains some private keys. The image file is about 1 TB in size, so this will take a moment to run. I will report back when it has completed.

Thank you very much for your help so far.

[nc50lc]

-snip- But if you set or changed a password, those 100 keys would be replaced by new ones and a new backup was indeed required.

A slight correction, changing the password of an already-encrypted wallet wont set a new keypool.
Or was it different in the first implementation of wallet encryption in version 0.4.0? Please CMIIAW.

I have tried to use pywallet to dump the private keys from the restored wallet but that fails as well. I'm using Linux (Fedora 42).

You can also try to paste a copy of those corrupted recovered wallet.dat to a small partition that you'll set as --recov-device and see if pywalet --recover can find private keys in those.

[LoyceV]

A slight correction, changing the password of an already-encrypted wallet wont set a new keypool.
Or was it different in the first implementation of wallet encryption in version 0.4.0? Please CMIIAW.

I'm not entirely sure, all this happened before my time in Bitcoin

[anon743294]

It probably has an option to use the image instead of partition, or maybe it just works (Everything is a file):

Code:

--recov_device /home/user/file.iso

Alternatively, you could just use the partition on which you saved the image, but that may be much bigger than needed.

I ran it with the --recov_device pointing to the path that contains the dd created disk image file. It ran and created a "pywallet_partial_recovery_xxxx.json" file. It didn't create a new wallet.dat file, as it said it would.

Any tips what should I do now?

[LoyceV]

It ran and created a "pywallet_partial_recovery_xxxx.json" file. It didn't create a new wallet.dat file, as it said it would.

I can't really tell you, I haven't had to deal with this in a long time. But I'd start by reading what's in that file (and don't post it of course).

[anon743294]

I can't really tell you, I haven't had to deal with this in a long time. But I'd start by reading what's in that file (and don't post it of course).

I also ran the pywallet --recover directly with drive instead of the disk image input, and after it ran, it outputs:

Code:

Read xxx Go in zzz minutes

Found 9 possible wallets
Found 2820 possible encrypted keys
Found 0 possible unencrypted keys

Possible wallet #1
    with passphrase #1  Traceback (most recent call last):
  File "/home/username/recovery/pywallet/pywallet.py", line 4034, in <module>
    recoveredKeys=recov(device, passes, size, 10240, options.recov_outputdir)
  File "/home/username/recovery/pywallet/pywallet.py", line 1799, in recov
    res = crypter.SetKeyFromPassphrase(pp, mk.salt, mk.iterations, mk.method)
  File "/home/username/recovery/pywallet/pywallet.py", line 951, in SetKeyFromPassphrase
    strKeyData = ctypes.create_string_buffer (vKeyData)
  File "/usr/lib64/python3.13/ctypes/__init__.py", line 67, in create_string_buffer
    raise TypeError(init)
TypeError: yyyy

This output seems to indicate that it does find something, but for some reason crashes at the very end.

The json files that it outputs are 30+ KB in size, they contain things like mkey: [xxxx,zzzz], and ckey: [qqqq,yyyy] etc. Where the data itself seems to consist of 12 digit numbers. Something like this:
ckey: [194857392812, 3948595949192, 384759284843] and so on.


To me, the mkey sounds like it is a reference to the wallet's master key and ckey sounds like the encrypted private keys.

[Cricktor]

Which version of Pywallet did you use (source link)? Because the guide [GUIDE] Recover your deleted keys tells you that Pywallet from thread Pywallet 2.2: manage your wallet [Update required] needs Python 2.7 and you used Python 3.13.

In jackjack's Github https://github.com/jackjack-jj/pywallet I don't quite see yet support for Python 3.x.

This post from nc50lc mentions above latest version of Pywallet to work properly with Python v2.7.17.

[anon743294]

Which version of Pywallet did you use (source link)? Because the guide [GUIDE] Recover your deleted keys tells you that Pywallet from thread Pywallet 2.2: manage your wallet [Update required] needs Python 2.7 and you used Python 3.13.

In jackjack's Github https://github.com/jackjack-jj/pywallet I don't quite see yet support for Python 3.x.

This post from nc50lc mentions above latest version of Pywallet to work properly with Python v2.7.17.

I'm using pywallet from jackjack's Github. You are correct, I was using Python 3.x to run it. I have now installed Python 2.7 via pyenv, and re-ran it, and it produces the exact same output, I'm afraid. It seems to crash while trying to save the possible wallets.

[nc50lc]

-snip-
This post from nc50lc mentions above latest version of Pywallet to work properly with Python v2.7.17.

-snip- I was using Python 3.x to run it. I have now installed Python 2.7 via pyenv, and re-ran it, and it produces the exact same output, I'm afraid. It seems to crash while trying to save the possible wallets.

Since you've said "exact same output" in your previous reply above,
Does it include this quoted error line: ?

Code:

  File "/usr/lib64/python3.13/ctypes/__init__.py", line 67, in create_string_buffer

Because even though v2.7 is installed via pyenv, it may still be using your python v3.13 environment to run Pywallet.
If so, try this pyenv tutorial to set it to v2.7.x: realpython.com/intro-to-pyenv/#specifying-your-python-version

[anon743294]

Since you've said "exact same output" in your previous reply above,
Does it include this quoted error line: ?

Code:

  File "/usr/lib64/python3.13/ctypes/__init__.py", line 67, in create_string_buffer

Yes it does, I found that Python 3 reference to be a bit odd, too. But when I ran "python --version" before running pywallet, that does say "Python 2.7.18"

Because even though v2.7 is installed via pyenv, it may still be using your python v3.13 environment to run Pywallet.
If so, try this pyenv tutorial to set it to v2.7.x: realpython.com/intro-to-pyenv/#specifying-your-python-version

I shall give this a read. Thank you!

[achow101]

I started writing a modern pywallet replacement that may work: https://github.com/achow101/wallet-manipulator. You should be able to install it with pip install . and then the wallet-manipulator command should be available. You can then export your private keys with

Code:

wallet-manipulator <path to file> export privkeys

You can use an additional --importable option after export to get json formatted output that can be dropped directly into a Bitcoin Core importdescriptors command.

However, since you said that these files are recovered rather than the original files, this may not get all of your private keys nor will it necessarily be able to even read the files. It uses my own implementation of a BDB file parser and it generally requires that the file is properly formatted. In possible corruption scenarios, it may not behave as expected.

You may want to try

Code:

wallet-manipulator <path to file> dump

first to see if it is able to parse the file and get any records out of it.

[Forsyth Jones]

I started writing a modern pywallet replacement that may work: https://github.com/achow101/wallet-manipulator. You should be able to install it with pip install . and then the wallet-manipulator command should be available. You can then export your private keys with

Code:

wallet-manipulator <path to file> export privkeys

Wonderful! Eager to see the final and practical result of this implementation. I also had difficulties running Pywallet due to this confusion with Python versions and other errors that I don't remember (it's reported somewhere on the forum).

I have a question: will this wallet-manipulator implementation workfor recovering descriptor wallets as well or only legacy wallet.dat files?

Do descriptor wallet.dat files store any WIF private keys?

In other words, can I restore WIF private keys from a descriptor wallet without needing third-party tools such as web pages (iancoleman)?

[achow101]

I have a question: will this wallet-manipulator implementation workfor recovering descriptor wallets as well or only legacy wallet.dat files?

Yes, it can export from descriptor wallets.

Do descriptor wallet.dat files store any WIF private keys?

Not in a way that you would expect or would get useful results from.

The default mode of operation for descriptor wallets is to have a descriptor which contains a xprv from which the keys for the addresses in the wallet are derived. However, the derived keys are not stored in the wallet like they are for descriptor wallets. Instead, they are derived from the xprv when needed.

The xprv itself is not actually stored as an xprv. The actual private key component of the xprv is stored separately in the same format used for storing private keys that legacy wallets used. The xprv is essentially reconstructed at derivation time by taking the xpub in the descriptor and swapping out the pubkey for the privkey. So if you were to parse the records of descriptor wallet naively, you could create a WIF key that corresponds to the private key component of the xprv. But this WIF key would be absolutely useless to you as it is not directly used as the private key for any of your wallet's addresses, and it is not enough information to derive any of the actual private keys (you need the chaincode from the xpub to do derivation).

If your wallet has a descriptors for things that have the key directly in them rather than deriving keys, then yes, you would be able to get the WIF and have them be usable. But this really only happens if you import those things yourself, or if you migrated a pre-HD legacy wallet.

wallet-manipulator won't be exporting the keys for descriptors as WIF. It will instead reconstruct the descriptors with the full xprv so that users don't shoot themselves in the foot.