<p>A reindex will not redownload the block. However, after safely shutting down Bitcoin Core, you can delete the block file containing that block. When you start it again, you will need to reindex, but once it gets to the blocks that you deleted, it will redownload them.</p>

CC BY-SA 4.0
2024-03-19T23:30:08.890Z
how to reindex properly? how do i know which block to remove if files are named like blk00908.dat? I removed block (copy to other place), but BCore began to download from scratch. i stopped that, added block back, and then it started to reindex with some loss of blocks.
Nikolai Zaitsev
CC BY-SA 4.0
2024-03-20T01:34:48.830Z
@NikolaiZaitsev You can start a reindex by starting Bitcoin Core with the `-reindex` option. The reindex will continue even after you restart it without that option. Also, reindexing will look like it is re-syncing from scratch - it is not.
Ava Chow
CC BY-SA 4.0
2024-03-20T08:35:05.647Z
Ok. I reach ~35%, when it crashes. Deleted last blkNNN.dat and restarted. BCore started to reindex, telling "Syncing Headers" and reached ~64%. This stage was relatively fast. However from that point it started to show me "Progress" which is about x4 times faster than the download speed. This is what you mean? Yesterday, when it crashed at 33%, I did the same, but then proper reindexing reached only 15% after which it started to download again. Hope this time it does everything as you say.
Nikolai Zaitsev
CC BY-SA 4.0
2020-02-16T07:01:35.687Z
2020-02-16T07:01:35.687Z
Ava Chow
<p>I seem to have discovered corrupt blocks on one of my nodes. The node is on all the time to keep up to sync and the rest of my nodes connect to it to retrieve block data when they need to sync. The node that's on all the time seems to be running fine, but when syncing my other nodes using data served from it, they report these five repeating errors after a certain block height:</p>

<pre><code>2020-02-16T05:08:34Z ERROR: AcceptBlock: bad-witness-merkle-match, ContextualCheckBlock : witness merkle commitment mismatch (code 16)
2020-02-16T05:08:34Z ERROR: ProcessNewBlock: AcceptBlock FAILED (bad-witness-merkle-match, ContextualCheckBlock : witness merkle commitment mismatch (code 16))
2020-02-16T05:08:34Z ERROR: ProcessNewBlock: AcceptBlock FAILED (bad-txnmrklroot, hashMerkleRoot mismatch (code 16))
2020-02-16T05:08:34Z ERROR: ProcessNewBlock: AcceptBlock FAILED (bad-txnmrklroot, hashMerkleRoot mismatch (code 16))
2020-02-16T05:08:34Z ERROR: ProcessNewBlock: AcceptBlock FAILED (bad-txnmrklroot, hashMerkleRoot mismatch (code 16))
</code></pre>

<p>I suppose this means the data being served from the head node is corrupt. My question: Is there a way to redownload and reindex from a specific block height instead of reindexing the whole thing? Would reindex even fix this problem? It seems like the block data is what's wrong, but the node doesn't know it.</p>

<block><synchronization><error><reindex><witness-data>
Re-index/Re-download from specific height?
Shadouts
# Re-index/Re-download from specific height?

(Asked by: username_0 on 2020-02-16)

I seem to have discovered corrupt blocks on one of my nodes. The node is on all the time to keep up to sync and the rest of my nodes connect to it to retrieve block data when they need to sync. The node that's on all the time seems to be running fine, but when syncing my other nodes using data served from it, they report these five repeating errors after a certain block height:

```
2020-02-16T05:08:34Z ERROR: AcceptBlock: bad-witness-merkle-match, ContextualCheckBlock : witness merkle commitment mismatch (code 16)
2020-02-16T05:08:34Z ERROR: ProcessNewBlock: AcceptBlock FAILED (bad-witness-merkle-match, ContextualCheckBlock : witness merkle commitment mismatch (code 16))
2020-02-16T05:08:34Z ERROR: ProcessNewBlock: AcceptBlock FAILED (bad-txnmrklroot, hashMerkleRoot mismatch (code 16))
2020-02-16T05:08:34Z ERROR: ProcessNewBlock: AcceptBlock FAILED (bad-txnmrklroot, hashMerkleRoot mismatch (code 16))
2020-02-16T05:08:34Z ERROR: ProcessNewBlock: AcceptBlock FAILED (bad-txnmrklroot, hashMerkleRoot mismatch (code 16))

```

I suppose this means the data being served from the head node is corrupt. My question: Is there a way to redownload and reindex from a specific block height instead of reindexing the whole thing? Would reindex even fix this problem? It seems like the block data is what's wrong, but the node doesn't know it.

**Tags:** block, synchronization, error, reindex, witness-data


---

## 1 answers

### Answer by username_1 on 2020-02-16. Score: 3

A reindex will not redownload the block. However, after safely shutting down Bitcoin Core, you can delete the block file containing that block. When you start it again, you will need to reindex, but once it gets to the blocks that you deleted, it will redownload them.

> **Comments:**
> **username_2**: how to reindex properly? how do i know which block to remove if files are named like blk00908.dat? I removed block (copy to other place), but BCore began to download from scratch. i stopped that, added block back, and then it started to reindex with some loss of blocks.  
> **username_1**: @username_2 You can start a reindex by starting Bitcoin Core with the `-reindex` option. The reindex will continue even after you restart it without that option. Also, reindexing will look like it is re-syncing from scratch - it is not.  
> **username_2**: Ok. I reach ~35%, when it crashes. Deleted last blkNNN.dat and restarted. BCore started to reindex, telling "Syncing Headers" and reached ~64%. This stage was relatively fast. However from that point it started to show me "Progress" which is about x4 times faster than the download speed. This is what you mean? Yesterday, when it crashed at 33%, I did the same, but then proper reindexing reached only 15% after which it started to download again. Hope this time it does everything as you say.  

---

