A+ A A-

What the fork?

You find the chain has forked, and you are on the wrong one.  So what do we do now to get back on track?  Here's a few ways we can sort this out.

First off, don't panic.  These things happen sometimes, but it's real easy to get it sorted out.  Sometimes it can be done quickly, others requires a bit more time and effort to sort it out.  The CLI tools do have commands to assist us.  Quite a lot of people, when they find they have forked, start a reindex.  In some cases this can help, but if you are on the wrong chain, we can still be on the wrong one even after a reindex.  So what then?

I generally start with the quicker method, before starting a reindex, or even a combination of all of them.  What you will need is the block explorer for the coin in question, of course hoping this also hasn't forked.  But assuming that is the case, this is what we need to do.  So, let's say our chain forked at block 300,000 and since this moment it's been continuing down the wrong route and finally come to a stop because everyone realised and are now no longer on this fork, and we are one of the few remaining.  Or sometimes, the fork can continue if others haven't realised yet.  So, we fire up the block explorer, and start making CLI calls to check and find the point we forked.  So we use a command like below:

alqo-cli getblockhash 300000

of course, this block matches the Alqo block explorer since it's the correct one.  However, let's assume it's not, so we back track, for example 1000 blocks and check block 299000, it matches, so let's move forward say half of this, so 299500 and check this hash.  This matches.  So we continue doing this until we find the blocks that don't match.  Let's assuming after I kept going back and forth that block 299576 doesn't match.

alqo-cli getblockhash 299576

on purpose I have changed the last two characters to xx.  Now these would be something else entirely, the "xx" is just to highlight.  So we know that 299575 is OK, but 299576 is the wrong one, and we need to get back on track.  We have a CLI command called invalidateblock that we can use.  So, for example:

alqo-cli invalidateblock 5d46f5017cc1b05e0363fb7c2eefd373969f6bc9f633e18e11b80a76d057cfxx

of course this won't work if you copy this because the blockhash doesn't exist.  But if it did, and was the wrong hash, the chain would now rewind from block 300,000 in this example to 299575 where we had the last correct block that matched the block explorer.  Once it's finished rewinding (you can check this in debug.log), you can then check/run CLI commands to see if it's still sitting on 299575, or started to download from the correct chain.  If it's downloading, check/verify block hashes with the explorer.  If all OK, then we fixed the problem.  If not, then we might need to help it.  Sometimes, we can just restart the daemon, so that it runs it's usual checks, and then will start to download.  Some, not all wallets will have a listbanned and clearbanned commands, which we might also need to use, since we were on the wrong chain, we might need to unban the correct ones to download.  So then we can do:

alqo-cli listbanned
alqo-cli clearbanned

and then check to see if it's downloading.  If not, then again, we can restart the daemon, to see if it will download or not.  If not, then now we should reindex.  So then after stopping alqod, we would then do something like:

alqod -daemon -reindex

to get it reindexing.  Now, when it gets to 299575, it should then start to download the correct chain.  And then we're back on track and ready to carry on as normal!  These procedures apply the same for masternodes as for normal wallets, either from the console, or equivalent commands within the QT wallet.

If all this fails then what?  You might need to remove everything under the directory where the chain is (except wallet.dat - don't delete this) and download the chain again.  Perhaps utilise the peers.dat by not deleting this, or get a list of other wallets from the block explorer and make yourself an addnode list and put this in the conf file and run the daemon.  It should then use those peers to connect quick and start downloading the chain.  Or, you might be lucky in that a bootstrap or chain snapshot is available to get you back on track quicker.

We at NodeCheck, make chain snapshots every week, so generally at worst if things go wrong, then we just need to sync the last 7 days if such a fork were to happen.  Which means we'd be back on track within 10 - 30 minutes, depending on how bad the fork was.