5
1
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?
(because I don't want to redownload the whole blockchain over this 3G connection) – Chris Moore – 2012-07-10T08:35:53.643
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 – 2012-07-11T06:47:14.203
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 – 2012-07-11T09:55:59.097
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 – 2012-07-11T22:34:33.680
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 – 2012-07-11T22:39:03.050