<p>You copied the entire chainstate too, which will confuse the node and cause it to be unable to continue syncing because the chainstate says the Bitcoin Cash chain is invalid and the node things that the chain it is currently using is also invalid. You can fix this by removing the chainstate, in which case it will begin reindexing. </p>

<p>However this may not fix all of your problems because the Bitcoin chain is still on disk and it will still index and verify that. So you may need to delete some of the blk*.dat and rev*.dat files (the higher numbered ones) in order to get it to revert to a state before the fork and then sync Bitcoin Cash from that point onwards.</p>

<hr>

<p>Details are that we copy the <code>.bitcoin</code> directory, but remove the <code>.bitcoin/chainstate</code> directory.  If you run the client now, it will freeze again when it gets to the <code>blk*.dat</code> files that are beyond the fork.  By running it while also running:</p>

<p><code>watch -n 1 'sudo lsof -c bitcoin | egrep -o "bitcoin/blocks/(blk|rev).*dat" | uniq | sed -E "s/^.+$/&amp;   `date`/" | tee -a recent.blk'
</code></p>

<p>and </p>

<p><code>watch tail recent.blk</code>, </p>

<p>I was able find that the files that need to be deleted are <code>.bitcoin/blocks/{blk,rev}00953.dat</code> and above.  That is, keep 00000 to 00952.  Then when I ran the client again, it worked.  After the fork, it synced with the network.  You can save yourself running it twice by just going ahead and deleting both the chainstate/ directory and the relevant files in blocks/.  When you run the client, it will say, "Error loading the block database, do you want to rebuild now?"  Respond, "Yes", and then  it will say "Reindexing the blocks on disk", followed by "Syncing the Headers (478436)".  That last number is the number of blocks in <code>blk00000.dat</code> through <code>blk00952.dat</code>, and just preceeds the fork at 478558.</p>

CC BY-SA 3.0
2018-01-16T02:50:36.000Z
So my first step is to remove the directory "chainstate", correct?  Then, if I have to, how do I tell how many blk/rev files to remove from the end.  The whole point of this exercise was to avoid re-downloading the whole blockchain.
Diagon
CC BY-SA 3.0
2018-01-16T02:54:38.370Z
I removed "chainstate" and it's syncing headers again, all the way from the beginning.  It's going to take some time.
Diagon
CC BY-SA 3.0
2018-01-16T03:01:28.517Z
Yes, first remove the chainstate directory. For the blk*.dat and rev*.dat files, look at the sizes of the highest numbered blk*.dat files. Divide that size by 1 MB. That tells you at least how many blocks are in that file. Then delete files starting from the highest numbered until you have passed the number of blocks since the fork point. Delete the same number of rev*.dat files.
Ava Chow
CC BY-SA 3.0
2018-01-16T03:07:01.407Z
Ok, thanks.  There is a directory called "index" in the "blocks" directory.  Will I need to do anything with that?
Diagon
CC BY-SA 3.0
2018-01-16T03:34:40.390Z
No. When you delete the files, you will need to reindex, and that folder will be cleared and rewritten
Ava Chow
CC BY-SA 3.0
2018-01-16T04:03:18.120Z
As I resync after having removed the chainstate directory, I am running `watch -n 20 'sudo lsof | egrep -o "bitcoin/blocks/(blk|rev).*dat" | uniq | tee -a recent.blk'`  That way, I get a list of block and rev files that have been opened, listed in `recent.blk`, and I can see which one was open last.  When this is done, and if needs be, I'll just delete from there on.
Diagon
CC BY-SA 3.0
2018-01-17T13:03:15.173Z
In addition to the chainstate directory, I had to remove the blocks/{blk,dev}*.dat files from #00953 on (so keep up to #00952).  After reindexing, it is now syncing headers for the 3rd time, and this seems the slowest of the three.  It will take days.  And I'm just assuming that this time it will progress beyond the fork.  I really think I should have just DL'd the whole blockchain again, from the beginning.
Diagon
CC BY-SA 3.0
2018-01-16T02:47:50.570Z
2018-01-21T00:51:00.830Z
2018-01-21T00:51:00.830Z
Ava Chow
<p>I've installed Bitcoin ABC, set bitcoin.conf to point at a copy of my directory from Bitcoin Core, and let it sync with the network.  All was well until it froze at the fork (Aug 1, 2017, 6:23AM).  The client is responsive, but my progress doesn't budge and the "Estimated time left until synced" stays at "calculating..."  At first I thought I had some kind of network error, but that doesn't appear to be the case.  I have 8 active connections.  Why won't it move beyond this point, downloading the post-fork transactions?</p>

<p>Bitcoin ABC, v0.16.2.0-unk on Ubuntu 17.10 (Mate).</p>

CC BY-SA 3.0
2018-01-16T02:21:53.567Z
What do you mean by "fed it my chain from Bitcoin Core"? Did you copy Bitcoin Core's blocks folder? Or did you copy the entire data directory? Or are you connecting it only to a Bitcoin Core instance? Either way, that time is the time of the fork, so Bitcoin blocks will no longer be valid to Bitcoin ABC and it will need to sync off of the Bitcoin Cash network.
Ava Chow
CC BY-SA 3.0
2018-01-16T02:42:15.923Z
I copied the entire directory, except I gave it an empty wallet, which I then connected only to a Bitcoin ABC instance running on another machine.  My question is why it doesn't continue after the fork, syncing off of the Bitcoin Cash network.
Diagon
<bitcoin-core><bitcoin-cash><blockchain-fork>
Bitcoin ABC, When Fed Bitcoin Core Chain Syncs to Aug 1 6:23AM 2017, Then Freezes
Diagon
# Bitcoin ABC, When Fed Bitcoin Core Chain Syncs to Aug 1 6:23AM 2017, Then Freezes

(Asked by: username_0 on 2018-01-14)

I've installed Bitcoin ABC, set bitcoin.conf to point at a copy of my directory from Bitcoin Core, and let it sync with the network. All was well until it froze at the fork (Aug 1, 2017, 6:23AM). The client is responsive, but my progress doesn't budge and the "Estimated time left until synced" stays at "calculating..." At first I thought I had some kind of network error, but that doesn't appear to be the case. I have 8 active connections. Why won't it move beyond this point, downloading the post-fork transactions?

Bitcoin ABC, v0.16.2.0-unk on Ubuntu 17.10 (Mate).

**Tags:** bitcoin-core, bitcoin-cash, blockchain-fork

> **Comments:**
> **username_1**: What do you mean by "fed it my chain from Bitcoin Core"? Did you copy Bitcoin Core's blocks folder? Or did you copy the entire data directory? Or are you connecting it only to a Bitcoin Core instance? Either way, that time is the time of the fork, so Bitcoin blocks will no longer be valid to Bitcoin ABC and it will need to sync off of the Bitcoin Cash network.  
> **username_0**: I copied the entire directory, except I gave it an empty wallet, which I then connected only to a Bitcoin ABC instance running on another machine.  My question is why it doesn't continue after the fork, syncing off of the Bitcoin Cash network.  

---

## 1 answers

### Answer by username_1 on 2018-01-16. Score: 1 | Accepted answer

You copied the entire chainstate too, which will confuse the node and cause it to be unable to continue syncing because the chainstate says the Bitcoin Cash chain is invalid and the node things that the chain it is currently using is also invalid. You can fix this by removing the chainstate, in which case it will begin reindexing.

However this may not fix all of your problems because the Bitcoin chain is still on disk and it will still index and verify that. So you may need to delete some of the blk\*.dat and rev\*.dat files (the higher numbered ones) in order to get it to revert to a state before the fork and then sync Bitcoin Cash from that point onwards.

---

Details are that we copy the `.bitcoin` directory, but remove the `.bitcoin/chainstate` directory. If you run the client now, it will freeze again when it gets to the `blk*.dat` files that are beyond the fork. By running it while also running:

`watch -n 1 'sudo lsof -c bitcoin | egrep -o "bitcoin/blocks/(blk|rev).*dat" | uniq | sed -E "s/^.+$/& `date`/" | tee -a recent.blk'`

and

`watch tail recent.blk`,

I was able find that the files that need to be deleted are `.bitcoin/blocks/{blk,rev}00953.dat` and above. That is, keep 00000 to 00952. Then when I ran the client again, it worked. After the fork, it synced with the network. You can save yourself running it twice by just going ahead and deleting both the chainstate/ directory and the relevant files in blocks/. When you run the client, it will say, "Error loading the block database, do you want to rebuild now?" Respond, "Yes", and then it will say "Reindexing the blocks on disk", followed by "Syncing the Headers (478436)". That last number is the number of blocks in `blk00000.dat` through `blk00952.dat`, and just preceeds the fork at 478558.

> **Comments:**
> **username_0**: So my first step is to remove the directory "chainstate", correct?  Then, if I have to, how do I tell how many blk/rev files to remove from the end.  The whole point of this exercise was to avoid re-downloading the whole blockchain.  
> **username_0**: I removed "chainstate" and it's syncing headers again, all the way from the beginning.  It's going to take some time.  
> **username_1**: Yes, first remove the chainstate directory. For the blk*.dat and rev*.dat files, look at the sizes of the highest numbered blk*.dat files. Divide that size by 1 MB. That tells you at least how many blocks are in that file. Then delete files starting from the highest numbered until you have passed the number of blocks since the fork point. Delete the same number of rev*.dat files.  
> **username_0**: Ok, thanks.  There is a directory called "index" in the "blocks" directory.  Will I need to do anything with that?  
> **username_1**: No. When you delete the files, you will need to reindex, and that folder will be cleared and rewritten  
> **username_0**: As I resync after having removed the chainstate directory, I am running `watch -n 20 'sudo lsof | egrep -o "bitcoin/blocks/(blk|rev).*dat" | uniq | tee -a recent.blk'`  That way, I get a list of block and rev files that have been opened, listed in `recent.blk`, and I can see which one was open last.  When this is done, and if needs be, I'll just delete from there on.  
> **username_0**: In addition to the chainstate directory, I had to remove the blocks/{blk,dev}*.dat files from #00953 on (so keep up to #00952).  After reindexing, it is now syncing headers for the 3rd time, and this seems the slowest of the three.  It will take days.  And I'm just assuming that this time it will progress beyond the fork.  I really think I should have just DL'd the whole blockchain again, from the beginning.  

---

