Bitcoin-abc: node can not synchronize

[bixf]

when use getblockcount to get height of the chain,it stop at 556766. at first,my program is 0.17.2. then i upgraded to 0.18.4 and 0.18.5.nothing changed.so is there something i need to configure to make things right?

[CarilKing]

me too

[c0deright]

556766 was the last block before the hardfork (new consensus rules since 556767. 0.17.2 didn't know these new consensus rules. See https://github.com/Bitcoin-ABC/bitcoin-abc/tree/v0.18.0 for the mention of new consensus rules that activated on November 15, 2018).

Possible Solution

0.17.2 marked block 556767 (0000000000000000004626ff6e3b936941d341c5932ece4357eeccac44e6d56c) as invalid because that was the 1st block being mined under the new consensus rules (0.17.2 didn't know about).

Now your database contains the information that block 0000000000000000004626ff6e3b936941d341c5932ece4357eeccac44e6d56c is invalid (it was invalid under 0.17.2 but is a valid block in 0.18.x).

So all you should have to do is the following:

bitcoin-cli reconsiderblock 0000000000000000004626ff6e3b936941d341c5932ece4357eeccac44e6d56c

This tells your bitcoin (cash) client to reconsider that block it thinks is still invalid.

RPC reconsiderblock

reconsiderblock "blockhash"

Removes invalidity status of a block and its descendants, reconsider them for activation.
This can be used to undo the effects of invalidateblock.

Arguments:

1. "blockhash" (string, required) the hash of the block to reconsider

Workaround for other people setting up a new node

Upgrade your BCH daemon to at least 0.18.x before it tries to sync block 556767.

[c0deright]

@bixf @CarilKing

Please let us know whether my outlined approach was successfull or not. Others might find that information useful.

[downpouring]

yes, it does. like a charm
block height: 582680

bitcoin-cli reconsiderblock 000000000000000001b4b8e36aec7d4f9671a47872cb9a74dc16ca398c7dcc18

appreciates