5

I have a very old wallet.dat that I've put into my .bitcoin folder. When trying to run bitcoind, the service stops giving the following error

2019-06-11T18:14:02Z Using wallet directory /home/nom/.bitcoin
2019-06-11T18:14:02Z init message: Verifying wallet(s)...
2019-06-11T18:14:02Z Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2019-06-11T18:14:02Z Using wallet wallet.dat
2019-06-11T18:14:02Z BerkeleyEnvironment::Open: LogDir=/home/nom/.bitcoin/database ErrorFile=/home/nom/.bitcoin/db.log
2019-06-11T18:14:02Z Renamed wallet.dat to wallet.dat.1560276842.bak
2019-06-11T18:14:02Z BerkeleyEnvironment::Salvage: Database salvage found errors, all data may not be recoverable.
2019-06-11T18:14:02Z BerkeleyEnvironment::Salvage: WARNING: Unexpected end of file while reading salvage output.
2019-06-11T18:14:02Z Salvage(aggressive) found no records in wallet.dat.1560276842.bak.
2019-06-11T18:14:02Z Error: wallet.dat corrupt, salvage failed
Error: wallet.dat corrupt, salvage failed
2019-06-11T18:14:02Z Shutdown: In progress...

Edit. Here is the content of the DB log

file unknown has LSN 1/151495, past end of log at 1/28 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment Page 0: metadata page corrupted Page 0: could not check metadata page wallet.dat: DB_VERIFY_BAD: Database verification failed file unknown has LSN 1/151495, past end of log at 1/1080 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment wallet.dat.1560341204.bak: DB_VERIFY_BAD: Database verification failed file unknown has LSN 1/151495, past end of log at 1/2500 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment wallet.dat.1560341352.bak: DB_VERIFY_BAD: Database verification failed

Edit. Using db_dump I am able to see the content of the wallet file ( addresses, keys etc)

Is there any way I could debug this, perhaps recovering just part of the keys or any useful data from the DB itself? Any useful hints how to approach such recovery?

2
  • Using db_dump -p <wallet file>, do you see anything lines that contain ckey or key? Does the output have HEADER=END near the start of the output and DATA=END at the end?
    – Ava Chow
    Commented Jun 13, 2019 at 23:28
  • Yes, there are plenty of lines with \0key entries and indeed, both HEADER/DATA entries appear. Also if it helps db_verify says the DB is fine. The wallet was created with a fairly old client (2010?)
    – Jernej
    Commented Jun 14, 2019 at 6:17

1 Answer 1

2

It sounds like your wallet.dat file is still intact, but some of the environment data has gotten corrupted (possibly due to moving wallet files).

Try doing

db_load -r lsn wallet.dat

This will reset the LSNs in the wallet.dat file which should cause the errors in the db.log to go away. Once you do that, delete the database/ folder and start Bitcoin Core.

8
  • This seems to make the wallet load just fine, though I wonder if all keys were erased? Is this error msg expected? 22019-06-14T16:40:30Z [default wallet] Keys: 0 plaintext, 0 encrypted, 0 w/ metadata, 0 total. Unknown wallet records: 0 ?
    – Jernej
    Commented Jun 14, 2019 at 16:41
  • That doesn't sound good. It seems like all of the keys were erased, and that's not supposed to happen. If you do db_dump on the file again, do you see what you saw earlier? Do you still see lines beginning with key?
    – Ava Chow
    Commented Jun 14, 2019 at 18:43
  • Yes I can still see that. As a matter of fact diff seems to be saying that the two dumps are equivalent.
    – Jernej
    Commented Jun 14, 2019 at 18:59
  • Don’t use -r lsn you can lose data.
    – EtherX Dev
    Commented Feb 21, 2022 at 1:42
  • did that, it worked for me, pywallet sees my addresses now and bitcoin core doesn't crash on import (still scanning, though)
    – Didi Kohen
    Commented Feb 22, 2023 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.