<p><strong>Using wallet /import</strong></p>

<p>If you load the wallet file in a modern Bitcoin Core version, you can use the <code>dumpwallet</code> command (to create an unencrypted dump of the keys), and the <code>importwallet</code> command in a fresh instance with a new empty wallet.dat of the dump. You will need to rescan afterwards, though, which may take a while.</p>

<p>Make sure to wipe the dump file afterwards.</p>

<p><strong>Using db dump/load</strong></p>

<p>One way is to use the following command on a Linux install with db4.8-util installed: <code>db4.8_dump wallet.dat | db4.8_load wallet.dat.new</code></p>

<p>This will create a new wallet.dat.new file, with the same records as the wallet.dat file, but without any old potentially never-overwritten data.</p>

<p>db4.8-util may be hard to install these days, as most distros stopped distributing db4.8, in favor of 5.1 and later. Bitcoin Core however still uses 4.8 for compatibility reasons. You can use db5.1-util as well, but that means that you'll need a Bitcoin Core version compiled with db5.1 support afterwards to use the newly constructed wallet file.</p>

CC BY-SA 3.0
2015-05-05T18:34:13.160Z
Just for clarity, the rescan which happens after an `importwallet` doesn't have to be manually initiated, is that correct?
Christopher Gurnee
CC BY-SA 3.0
2015-05-05T19:12:09.120Z
If you are importing multiple keys it's best to add false to the end of the command to prevent the rescan, and then run it manually after you've imported all your keys. Or just import them to a web or SPV wallet and send all the funds to a fresh address which you can import into a newer bitcoin core.
George
CC BY-SA 3.0
2015-05-05T19:13:39.777Z
@ChristopherGurnee yes, it will happen automatically.
Pieter Wuille
CC BY-SA 3.0
2015-05-05T19:14:00.637Z
@George importwallet imports all keys at once already, and only rescans the necessary part intelligently.
Pieter Wuille
CC BY-SA 3.0
2015-05-06T03:05:49.557Z
@PieterWuille Thanks mate. You're right, the db4.8 is the hard part for a relative Ubuntu newb. I run the node with *txindex=1* so no dramas on that front, though I will be sure to use the *false* flag
Wizard Of Ozzie
CC BY-SA 3.0
2015-05-06T09:37:37.880Z
No need to use the false flag, as explained above. And having txindex=1 doesn't help one bit.
Pieter Wuille
CC BY-SA 3.0
2015-05-06T20:13:02.617Z
@PieterWuille sorry yes, I read it as importprivkey for some reason!
George
CC BY-SA 3.0
2015-05-07T15:46:35.380Z
@PieterWuille George yep I read it that way too initially. Hence txindex and false flag comment. UPDATE: did it! What a great surprise to have. Balances out the 16 btc mtgox redeem code I was saving!
Wizard Of Ozzie
CC BY-SA 3.0
2015-05-07T16:03:48.247Z
txindex does not make sense still. It only helps by-txid lookups of historic transactions. It is not used for import or rescan.
Pieter Wuille
CC BY-SA 3.0
2015-05-05T17:20:02.290Z
2015-05-05T17:26:26.720Z
2015-05-05T17:26:26.720Z
Pieter Wuille
<p>Whilst moving houses I came across some old HDDs which I've just found contains a wallet.dat from August 2011. The version of Bitcoin-qt must be 0.4.0 as I know the wallet.dat is password encrypted, which was introduced for <a href="http://sourceforge.net/projects/bitcoin/files/Obsolete/bitcoin-0.4.0/" rel="nofollow">version 0.4.0</a>. It is 100% <em>*not*</em> >0.4.0, so the vulnerability patched by <a href="http://sourceforge.net/projects/bitcoin/files/Obsolete/bitcoin-0.4.1/" rel="nofollow">0.4.1</a> is not in place. </p>

<p>What is the best way to go about restoring the encrypted addresses? If I were to install the 0.4.1 Bitcoin-qt update, would there be any problems with current OS dependencies? Should I use Windows, Linux? Any input greatly appreciated. (I will certainly keep a backup)</p>

<bitcoin-core><wallet.dat>
Wallet.dat (<0.4.0) format: retrieving Bitcoin, possible security concerns
Wizard Of Ozzie
# Wallet.dat (<0.4.0) format: retrieving Bitcoin, possible security concerns

(Asked by: username_0 on 2015-05-05)

Whilst moving houses I came across some old HDDs which I've just found contains a wallet.dat from August 2011. The version of Bitcoin-qt must be 0.4.0 as I know the wallet.dat is password encrypted, which was introduced for [version 0.4.0](http://sourceforge.net/projects/bitcoin/files/Obsolete/bitcoin-0.4.0/). It is 100% *\*not\** >0.4.0, so the vulnerability patched by [0.4.1](http://sourceforge.net/projects/bitcoin/files/Obsolete/bitcoin-0.4.1/) is not in place.

What is the best way to go about restoring the encrypted addresses? If I were to install the 0.4.1 Bitcoin-qt update, would there be any problems with current OS dependencies? Should I use Windows, Linux? Any input greatly appreciated. (I will certainly keep a backup)

**Tags:** bitcoin-core, wallet.dat


---

## 1 answers

### Answer by username_1 on 2015-05-05. Score: 5 | Accepted answer

**Using wallet /import**

If you load the wallet file in a modern Bitcoin Core version, you can use the `dumpwallet` command (to create an unencrypted dump of the keys), and the `importwallet` command in a fresh instance with a new empty wallet.dat of the dump. You will need to rescan afterwards, though, which may take a while.

Make sure to wipe the dump file afterwards.

**Using db dump/load**

One way is to use the following command on a Linux install with db4.8-util installed: `db4.8_dump wallet.dat | db4.8_load wallet.dat.new`

This will create a new wallet.dat.new file, with the same records as the wallet.dat file, but without any old potentially never-overwritten data.

db4.8-util may be hard to install these days, as most distros stopped distributing db4.8, in favor of 5.1 and later. Bitcoin Core however still uses 4.8 for compatibility reasons. You can use db5.1-util as well, but that means that you'll need a Bitcoin Core version compiled with db5.1 support afterwards to use the newly constructed wallet file.

> **Comments:**
> **username_2**: Just for clarity, the rescan which happens after an `importwallet` doesn't have to be manually initiated, is that correct?  
> **username_3**: If you are importing multiple keys it's best to add false to the end of the command to prevent the rescan, and then run it manually after you've imported all your keys. Or just import them to a web or SPV wallet and send all the funds to a fresh address which you can import into a newer bitcoin core.  
> **username_1**: @username_2 yes, it will happen automatically.  
> **username_1**: @username_3 importwallet imports all keys at once already, and only rescans the necessary part intelligently.  
> **username_0**: @username_1 Thanks mate. You're right, the db4.8 is the hard part for a relative Ubuntu newb. I run the node with *txindex=1* so no dramas on that front, though I will be sure to use the *false* flag  
> **username_1**: No need to use the false flag, as explained above. And having txindex=1 doesn't help one bit.  
> **username_3**: @username_1 sorry yes, I read it as importprivkey for some reason!  
> **username_0**: @username_1 username_3 yep I read it that way too initially. Hence txindex and false flag comment. UPDATE: did it! What a great surprise to have. Balances out the 16 btc mtgox redeem code I was saving!  
> **username_1**: txindex does not make sense still. It only helps by-txid lookups of historic transactions. It is not used for import or rescan.  

---

