Rescue a Wallet: a Forgotten Passphrase, an Old wallet.dat, a Missing Balance

1Before you start: copies, and where wallets live

Divi Core keeps wallet.dat in its data folder. The defaults, from DataDirectory.cpp in the Divi Core source:

Testnet wallets sit one level down, in a testnet3 folder. Other wallet apps may keep their own folder; look in the app's settings for a "data directory" entry before searching the disk.

Divi Core keeps its own backups. Every time it starts it copies the wallet into a backups folder inside the data folder, named like wallet.dat.2026-10-22-11-24. The newest 20 copies are kept and older ones are deleted. A second folder, monthlyBackups, gets one copy a month. A copy is only made when the wallet passes an integrity check at start, so a damaged wallet never overwrites the good copies. Look there first in every rescue below.

2An old wallet.dat

You found a wallet.dat on an old laptop or a USB stick. Open it in Divi Core 3.0.0 without disturbing your current wallet:

# 1. stop the node
./divi-cli stop

# 2. copy the old file into the
#    data folder, under a new name
cp /media/usb/wallet.dat ~/.divi/old-2020.dat

# 3. start the node on that file
./divid -wallet=old-2020.dat -daemon

# 4. look
./divi-cli getwalletinfo
./divi-cli getbalance

What we saw with a wallet made in Divi Core 1.0.8 and opened in 3.0.0: it opened with no conversion step, still encrypted ("encryption_status":"locked"). Both versions use the same Berkeley DB 4.8 file format. The node then scanned the chain on its own, and the log in the data folder's debug.log said:

Some keys lack metadata. Wallet may require a rescan
Scanning... from height 360718 to 360847
addToWallet 384e999a3a new
addToWallet 59e09927cc new
Scanning...done

Both payments appeared and the balance read 17. The scan starts at the wallet's first key, minus two hours, so it does not read years of blocks the wallet cannot be in. The "lack metadata" line is the 1.0.8 file talking. Old wallets did not store a birth time for every key, and 3.0.0 notes it and carries on.

When you are done, stop the node and start it again without -wallet= to go back to your own wallet.

When the balance still looks short: a full rescan

-rescan at start reads the chain again, but in our test it started at the same height, because it also skips blocks older than the first key. If the wallet's key dates are wrong, for example after keys were imported from somewhere else, start once with -force_rescan. That reads from block 0. It is in the source (wallet.cpp) but not in divid -help. On our testnet node the log said Scanning... from height 0 to 360893, and the whole scan took 18 seconds. Testnet blocks are nearly empty; a mainnet scan on a laptop takes much longer. The normal scans above, on a tiny fresh wallet, took under a second.

./divid -wallet=old-2020.dat -force_rescan -daemon

3A forgotten passphrase

Nobody can reset a wallet passphrase. There is no server that knows it. What you can do is try the passwords you might have used, and if none fits, rebuild the wallet from its recovery phrase.

Try your own guesses

Write every candidate you can think of into a file, one per line: old passwords, with and without a capital, with the year, with a ! on the end. Then let the wallet test them. A wrong guess answers:

error: {"code":-14,"message":"Error: The wallet passphrase entered was incorrect."}

# only you can read the file
umask 077
nano ~/guesses.txt

# test each line; stops at the
# first one that unlocks
n=0
while IFS= read -r p; do
  n=$((n+1))
  if ./divi-cli walletpassphrase "$p" 1 >/dev/null 2>&1; then
    echo "Found it: line $n of guesses.txt"; break
  fi
done < ~/guesses.txt

# then wipe the file
shred -u ~/guesses.txt

We ran this exact loop with two wrong guesses and the right one third. It printed Found it: line 3 of guesses.txt. A longer run of 50 guesses took 6.2 seconds, about 8 guesses a second on our test machine. A list of a few thousand is an evening; a blind search of every possible password is not something this approach can do.

The 1 unlocks for one second only, so a hit does not leave the wallet open. Once you know the passphrase, open the wallet and choose a new one you will remember, then write it down where your recovery phrase is kept:

# the leading space keeps the line
# out of your shell history
 ./divi-cli walletpassphrasechange "the-old-one" "a-new-one"

We changed the test wallet's passphrase this way: the old one was refused afterwards and the new one unlocked it.

When no guess works

If you have the recovery phrase, the passphrase does not matter. The phrase rebuilds the wallet in a new, empty data folder, and you set a new passphrase there. Restoring from the phrase walks through it step by step. Failing that, look for a copy of the wallet made before it was encrypted, as described in the first step.

4A damaged wallet file

Disks fail and USB sticks get pulled out mid-write. We wrote 64 KiB of random bytes into the middle of a copy of the test wallet. Divi Core 3.0.0 refused to start on it and stopped with one line in debug.log:

Error: Wallet integrity check failed.

Try these in order.

1. The backups folder. Copy the newest wallet.dat.<date> from it into the data folder under a new name and open it with -wallet= as in step 2. Coins received after that copy was made still show up, because the scan finds them.
2. The recovery phrase. It rebuilds every key, which no file repair can promise. See restoring from the phrase.
3. A manual salvage, only when neither exists. It is below.

Manual salvage, on a copy

This uses the Berkeley DB tools on Linux (sudo apt install db5.3-util on Ubuntu or Debian). Copy the damaged file to that machine. The -r dump reads every page it can and skips the broken ones; the rest of the commands rebuild a clean file from what it found.

cp wallet.dat broken.dat
db5.3_verify broken.dat
# reports the bad page, e.g.
# Page 75: bad page number 2512285094

db5.3_dump -r broken.dat > salvage.dump

# keep the records, put them
# under one header
awk '/^HEADER=END/{s=1;next} /^DATA=END/{s=0} s&&/^ /' salvage.dump > body.txt
{ printf 'VERSION=3\nformat=bytevalue\ndatabase=main\ntype=btree\nHEADER=END\n'
  cat body.txt; echo DATA=END; } > rebuilt.dump

db5.3_load -f rebuilt.dump rebuilt.dat
db5.3_verify rebuilt.dat
# Verification of rebuilt.dat
# succeeded.

Copy rebuilt.dat into the data folder and open it with -wallet=rebuilt.dat. We ran this on two damaged copies, damaged in the same place:

So a salvage can return a file that looks fine to the database tools and still will not open as a wallet. That is why the phrase, and the backups folder, come first.

5A missing balance

The wallet opens, but the number is wrong or zero. Go down this list; each check was run on the test wallet.

6Moving an old wallet into IronDivi

IronDivi does not read wallet.dat. We put one in an IronDivi data folder; IronDivi ignored it and made a brand new wallet next to it, logging new wallet created; retrieve the seed with the dumphdinfo RPC. Nothing warns you that your file was skipped.

Move the keys instead. Open the old wallet in Divi Core as in step 2, unlock it, and export each address's key. Then import it into IronDivi and rescan:

# Divi Core, old wallet unlocked
./divi-cli dumpprivkey <address>

# IronDivi
irondivi-cli importprivkey <key>
irondivi-cli rescanblockchain

After the import the address showed "ismine":true but the balance did not move. IronDivi 0.2.6 does not scan on import, whatever the third argument says (wallet.rs: "rescan not implemented"). The rescanblockchain with no arguments is what finds the coins. On our testnet node a full scan of about 361,000 blocks took 3 minutes the first time and 23 seconds the second. Mainnet is longer.

Divi Core 1.0.8 had dumpwallet to export every key at once. Divi Core 3.0.0 no longer has it, so export the addresses that hold coins one by one. listunspent in the old wallet lists them. If the old wallet has a recovery phrase, restoring that phrase in IronDivi is simpler still: see restoring from the phrase.

If something goes wrong