<p>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 <code>./bitcoind -loadblock=blk0001.dat.bak</code></p>

CC BY-SA 3.0
2012-12-19T04:02:31.400Z
my blk0001.dat corrupts all the time.
Felipe
CC BY-SA 3.0
2012-07-10T19:20:45.827Z
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
CC BY-SA 3.0
2012-07-11T02:07:54.520Z
I added to my question as the -loadblock=... is running.
Chris Moore
CC BY-SA 3.0
2012-07-10T10:20:52.883Z
2012-07-10T10:20:52.883Z
Pieter Wuille
<p>My copy of <code>blkindex.dat</code> became corrupted, but I still have the whole <code>blk0001.dat</code> file.</p>

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

<p>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 <code>bitcoind -loadblock=blk0001.dat.bak</code> 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?</p>

<p>While running, the command just said:</p>

<pre><code>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
</code></pre>

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

CC BY-SA 3.0
2012-07-10T08:35:53.643Z
(because I don't want to redownload the whole blockchain over this 3G connection)
Chris Moore
CC BY-SA 3.0
2012-07-11T06:47:14.203Z
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
CC BY-SA 3.0
2012-07-11T09:55:59.097Z
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
CC BY-SA 3.0
2012-07-11T22:34:33.680Z
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
CC BY-SA 3.0
2012-07-11T22:39:03.050Z
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
<blockchain><database>
Can I regenerate blkindex.dat from blk0001.dat?
Chris Moore
# Can I regenerate blkindex.dat from blk0001.dat?

(Asked by: username_0 on 2012-07-10)

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?

**Tags:** blockchain, database

> **Comments:**
> **username_0**: (because I don't want to redownload the whole blockchain over this 3G connection)  
> **username_1**: 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.  
> **username_0**: 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.  
> **username_2**: 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.  
> **username_2**: 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.  

---

## 1 answers

### Answer by username_2 on 2012-07-10. Score: 7 | Accepted answer

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`

> **Comments:**
> **username_0**: 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')  
> **username_0**: I added to my question as the -loadblock=... is running.  
> **username_3**: my blk0001.dat corrupts all the time.  

---

