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?

Chris Moore
  • 14,745
  • 6
  • 65
  • 87
  • (because I don't want to redownload the whole blockchain over this 3G connection) – Chris Moore Jul 10 '12 at 08: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 06: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 09: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

1 Answers1

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

Pieter Wuille
  • 98,249
  • 9
  • 183
  • 287
  • 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 02:07
  • my blk0001.dat corrupts all the time. – Felipe Dec 19 '12 at 04:02