<p>if you using reindex-chainstate is more faster .
also i have collection script to monitor block status 
<a href="https://github.com/sicute/blockchain/blob/master/bsv/bsvblock.sh" rel="nofollow noreferrer">block monitor example script </a></p>

<p>you can ruuning with crontab and see how many block have been sync and compare with mainnet block excplorer.</p>

CC BY-SA 4.0
2020-02-22T01:01:50.030Z
2020-02-22T01:01:50.030Z
sonjaya sonjaya
<p><code>-reindex</code>:</p>

<ul>
<li>wipes the chainstate (the UTXO set)</li>
<li>wipes the block index (the database with information about which block is where on disk)</li>
<li>rebuilds the block index (by going over all blk*.dat files, and finding things in it that look like blocks)</li>
<li>rebuilds the chainstate (redoing all validation for blocks) based on the blocks now in the index</li>
</ul>

<p><code>-reindex-chainstate</code>:</p>

<ul>
<li>wipes the chainstate</li>
<li>rebuilds the chainstate using the blocks in the index you had before</li>
</ul>

<p>The latter should be strictly faster, as it does not need to rebuild the block index first. Perhaps the progress bar during reindex confuses you: that progress is only for the rebuilding of the index. The recreation of the chainstate happens after that rebuild is completed.</p>

<p>You should use <code>-reindex</code> only when you were running in pruning mode, or if you suspect the blocks on disk are actually corrupted. Otherwise, when you only suspect corruption of the chainstate (which is far more likely), use <code>-reindex-chainstate</code>.</p>

CC BY-SA 3.0
2017-10-19T06:07:19.790Z
Thank you for your answer, I am actually running the node on a headless server, so I do not see a progress bar. Is there a definitive way to know when the sync is complete? I am currently doing it by looking at the log and seeing when the time stamp of the blocks catches up to the present.
amanusk
CC BY-SA 4.0
2021-02-28T07:43:46.540Z
For progress on a headless machine (no gui), I watched the bitcoind log.  There were many `UpdateTip` messages that showed the block height. For example: `height=201202`.  Indeed the progress goes faster when the node already has the blk*.dat files than having to re-download the blocks
Donn Lee
CC BY-SA 4.0
2021-09-28T18:26:12.817Z
is there any other command that are in between these two? I'm having issues on a server where I keep getting corrupt 1 or 2 files. Is it not possible to only fix these specific .blk or .ldb files e.g. `Fatal LevelDB error: IO error: /root/.bitcoin/chainstate/000184.ldb: Bad message`
pseudozach
CC BY-SA 4.0
2021-09-28T18:27:30.717Z
Both `-reindex` and `-reindex-chainstate` throw away all chainstate/*.ldb files and rebuilds them. If you're seeing this error after a `-reindex`, most likely you have a hardware problem.
Pieter Wuille
CC BY-SA 4.0
2024-02-12T09:28:30.450Z
Note on a pruned node, -reindex nukes all your blockchain data. I had 10GB on a prune=550 node and it blew it all away. It then proceeded to download everything from 2009 onward. This is insane when the point of a pruned node is to avoid all the intense, long lasting work. I had a blockchain data backup and github blockchain downloads are also a good backup but there's some thing really wrong with how pruned nodes and wallets work.
Shovas
CC BY-SA 3.0
2017-10-14T19:50:16.813Z
2017-10-14T19:50:16.813Z
Pieter Wuille
<p>What is the difference between the options <code>-reindex</code> and <code>-reindex-chainstate</code>?</p>

<p>Is one of the options faster?</p>

<p>When should each option be used?  </p>

<bitcoin-core><bitcoind><reindex>
When should I use -reindex-chainstate and when -reindex
amanusk
# When should I use -reindex-chainstate and when -reindex

(Asked by: username_0 on 2017-10-14)

What is the difference between the options `-reindex` and `-reindex-chainstate`?

Is one of the options faster?

When should each option be used?

**Tags:** bitcoin-core, bitcoind, reindex


---

## 2 answers

### Answer by username_2 on 2017-10-14. Score: 64 | Accepted answer

`-reindex`:

* wipes the chainstate (the UTXO set)
* wipes the block index (the database with information about which block is where on disk)
* rebuilds the block index (by going over all blk\*.dat files, and finding things in it that look like blocks)
* rebuilds the chainstate (redoing all validation for blocks) based on the blocks now in the index

`-reindex-chainstate`:

* wipes the chainstate
* rebuilds the chainstate using the blocks in the index you had before

The latter should be strictly faster, as it does not need to rebuild the block index first. Perhaps the progress bar during reindex confuses you: that progress is only for the rebuilding of the index. The recreation of the chainstate happens after that rebuild is completed.

You should use `-reindex` only when you were running in pruning mode, or if you suspect the blocks on disk are actually corrupted. Otherwise, when you only suspect corruption of the chainstate (which is far more likely), use `-reindex-chainstate`.

> **Comments:**
> **username_0**: Thank you for your answer, I am actually running the node on a headless server, so I do not see a progress bar. Is there a definitive way to know when the sync is complete? I am currently doing it by looking at the log and seeing when the time stamp of the blocks catches up to the present.  
> **username_3**: For progress on a headless machine (no gui), I watched the bitcoind log.  There were many `UpdateTip` messages that showed the block height. For example: `height=201202`.  Indeed the progress goes faster when the node already has the blk*.dat files than having to re-download the blocks  
> **username_4**: is there any other command that are in between these two? I'm having issues on a server where I keep getting corrupt 1 or 2 files. Is it not possible to only fix these specific .blk or .ldb files e.g. `Fatal LevelDB error: IO error: /root/.bitcoin/chainstate/000184.ldb: Bad message`  
> **username_2**: Both `-reindex` and `-reindex-chainstate` throw away all chainstate/*.ldb files and rebuilds them. If you're seeing this error after a `-reindex`, most likely you have a hardware problem.  
> **username_5**: Note on a pruned node, -reindex nukes all your blockchain data. I had 10GB on a prune=550 node and it blew it all away. It then proceeded to download everything from 2009 onward. This is insane when the point of a pruned node is to avoid all the intense, long lasting work. I had a blockchain data backup and github blockchain downloads are also a good backup but there's some thing really wrong with how pruned nodes and wallets work.  

---

### Answer by username_1 on 2020-02-22. Score: 0

if you using reindex-chainstate is more faster .
also i have collection script to monitor block status
[block monitor example script](https://github.com/sicute/blockchain/blob/master/bsv/bsvblock.sh)

you can ruuning with crontab and see how many block have been sync and compare with mainnet block excplorer.


---

