5

My copy of blkindex.dat became corrupted, but I still have the whole blk0001.dat file.

Is it possible to reconstruct the blkindex.dat file from the blk0001.dat file or do I have to delete both files and redownload the whole blockchain from scratch?

Edit: Pieter's answer is working for me. It's taking many hours to run, but at least it isn't using any bandwidth. I'm wondering, as a related question, whether this bitcoind -loadblock=blk0001.dat.bak technique is a way of being able to get a trusted copy of the blockchain from an untrusted source. If I download a blk0001.dat from a random website, then import it using this -loadblock command, does that ensure it's correct, and ask the network for anything the download was missing?

While running, the command just said:

SetBestChain: new best=00000000000004411998  height=174305  work=284206530118085534778
SetBestChain: new best=00000000000009a01d64  height=174306  work=284213516218692473063
InvalidChainFound: invalid block=000000000000038181de  height=174307  work=284220502319299411348
InvalidChainFound:  current best=00000000000009a01d64  height=174306  work=284213516218692473063
SetBestChain: new best=00000000000007e352ec  height=174307  work=284220502319299411348
SetBestChain: new best=00000000000006b4b91c  height=174308  work=284227488419906349633

Is that normal, representing an orphaned block? Or possibly the result of the same disk error that caused the blkindex.dat to become corrupted initially?

Improve this question
5
  • (because I don't want to redownload the whole blockchain over this 3G connection) – Chris Moore Jul 10 '12 at 8:35
  • Seems unlikely that it's caused by the disk error. I see no way to recover from a corrupted block that's part of the main chain, since all later blocks depend on it. – CodesInChaos Jul 11 '12 at 6:47
  • It looks like I had two different blocks at height 174307 though - see how the hashes are different? All later blocks only depend on one of them. Incidentally, the -loadblock command hung after about 6 hours, with around 8000 blocks still to import. I quit it and ended up going back to the partially completed download I had been running before, which only had about 2000 blocks missing. – Chris Moore Jul 11 '12 at 9:55
  • Orphan (in the meaning of "without parent") blocks are never stored on disk, just cached in RAM until their parents are fetched. This seems to be a stale block (one not (anymore) in the main chain) that got corrupted; it is certainly not normal to have stale blocks that cause invalid chains. – Pieter Wuille Jul 11 '12 at 22:34
  • I just remembered; the number 174307 looks familiar to me. I believe this was a BP16-invalid block that got created shortly after the switch, before many nodes updated. Getting an invalid chain error during re-import is expected behavior in that case. – Pieter Wuille Jul 11 '12 at 22:39
7

This is possible in git HEAD, and will be in 0.7.0. You can move the existing blk0001.dat elsewhere, delete blkindex.dat, and then start the client using ./bitcoind -loadblock=blk0001.dat.bak

Improve this answer
3
  • That's working nicely, thanks. One thing I noticed is that while it's importing from the .bak file the splash screen says "Loading wallet..." which is a little misleading. (I use 'bitcoin-qt -server' rather than 'bitcoind') – Chris Moore Jul 10 '12 at 19:20
  • I added to my question as the -loadblock=... is running. – Chris Moore Jul 11 '12 at 2:07
  • my blk0001.dat corrupts all the time. – Felipe Dec 19 '12 at 4:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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