Description
I have clique private proof-of-authority chain.
- Geth minimum version:
v1.8.16-stable
I have updated all signer nodes' (currently I have 3 signer nodes) geth version to minimum Version: 1.8.16-stable. Also I have updated the other node that gives the error to v1.8.16.
The way I run my geth also tried without --syncmode fast flag.
geth --syncmode fast --cache=1024 --shh --datadir $DATADIR/private --rpcaddr 127.0.0.1 --rpc --rpcport 8545 --rpccorsdomain="*" --networkid 12345 --rpcapi admin,eth,net,web3,debug,personal,shh
Error I am having on multiple nodes that are connected into the network.
########## BAD BLOCK #########
Chain config: {ChainID: 23422 Homestead: 1 DAO: <nil> DAOSupport: false EIP150: 2 EIP155: 3 EIP158: 3 Byzantium: 4 Constantinople: <nil> Engine: clique}
Number: 1260001
Hash: 0x659e96f35e1fa1c39fc3b8370a336f78787e482aef44e56bbe6dd9e10bb06bdc
Error: recently signed
##############################
WARN [10-05|15:49:57.694] Synchronisation failed, dropping peer peer=ae57fcb24c19102e err="retrieved hash chain is invalid"
INFO [10-05|15:49:57.694] message loop peer=ae57fcb24c19102e err=EOF
ERROR[10-05|15:50:07.707]
########## BAD BLOCK #########
Chain config: {ChainID: 23422 Homestead: 1 DAO: <nil> DAOSupport: false EIP150: 2 EIP155: 3 EIP158: 3 Byzantium: 4 Constantinople: <nil> Engine: clique}
Number: 1260001
Hash: 0x659e96f35e1fa1c39fc3b8370a336f78787e482aef44e56bbe6dd9e10bb06bdc
-
I have reverted back the blockchain into some previous block number,
debug.setHead("0x124F80")(1200000 th block) but it did not help. -
Please note that I have to remove my chaindata
geth removedband sync from the start, which also didn't help.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
Participants
Activity
holiman commentedon Oct 5, 2018
This is a known issue introduced in 1.8.14, iirc. Fixed in #17620
holiman commentedon Oct 5, 2018
You originally reported this on
Version: 1.8.15-unstable. So are there still nodes runningVersion: 1.8.15-unstable? And are those still present? If so, they may be still advertising a chain which is invalid, and is being rejected by your node.avatar-lavventura commentedon Oct 5, 2018
@holiman: I have updated all signer nodes' (currently I have 3 signer nodes) geth version to minimum
Version: 1.8.16-stable. Also I have updated the other node that gives the error tov1.8.16.I have rsync the chain from genesis block, but unfortunately, I am still having the same error.
Possible Solution:
debug.setHead()? This could be a short-term solution where the same error could be occurred again.karalabe commentedon Oct 8, 2018
This was fixed on master. I.e. stable release will arrive today.karalabe commentedon Oct 8, 2018
Oh wait, I thought the invalid hash chain error. Then this is not what I thought, sorry for the noise.
karalabe commentedon Oct 8, 2018
@avatar-lavventura Yeah, you might need to rewind the chain back to before the faulty snapshot block / epoch transition. The signers won't realize some past block became invalid.
avatar-lavventura commentedon Oct 8, 2018
@karalabe: I rewinded all the signers and it has been fixed.
karalabe commentedon Oct 9, 2018
There was a bug in one Geth release (v1.8.14/v1.8.15) that violated the Clique consensus spec, causing some signers to create blocks when they weren't allowed to (epoch transition). All previous and subsequent version of Geth (apart from the faulty one) correctly rejected those blocks, hence why you couldn't sync a new node to your already mined chain.
A node however does not re-validate blocks when you update it, so even though you updated your signers, they were oblivious to the fact that a faulty block was already in their chain. When you rewound the chain, the signers had to re-mine the faulty segment, correcting the issue.
This should most definitely not happen again, as long as you don't use the faulty version of Geth. Any version equal or above to v1.8.16 should work just fine.
kennethhoytwoodruff commentedon Apr 16, 2019
I am running Geth/v1.8.26-stable-cdae1c59/linux-arm64/go1.11.8.
I have made several attempts over the past few days to sync the ropsten network. I always get pretty far along and things are going smoothly...
eth.syncing
{
currentBlock: 5414169,
highestBlock: 5418913,
knownStates: 107811598,
pulledStates: 107811598,
startingBlock: 5414168
}
But THEN..... I get the dreaded: "BAD BLOCK" followed by the "Synchronisation failed, dropping peer peer=35a1db7f4a92d6d6 err="retrieved hash chain is invalid" message - and everything comes to a halt. Nothing precipitates this failure. It just happens.
Then I make another attempt - which always fails after days of synching.
I am getting really frustrated and am thinking about using Parity instead. Any suggestions?
folex commentedon May 4, 2019
I'm facing similar issue on Rinkeby network. A lot of errors (see below) about
BAD BLOCKstarted to appear atMay 04 05:33 UTC:This all happened on Geth v1.8.23, running in a docker container
ethereum/client-go:stable. I then pulled a new container with Geth/v1.8.27-stable-4bcc0a37/linux-amd64/go1.11.9 inside.I restarted the container, and it started to sync:
Syncing was pretty slow (comparing to usual sync speed), and following errors started to appear in logs (pasting first appearance):
By now, log is full of such errors:
But it's still moving forward, not stalling, but very-very slow (like 1 block in a minute or slower).
Network: Rinkeby
Version: Geth/v1.8.27-stable-4bcc0a37/linux-amd64/go1.11.9
Run args:
--rinkeby --rpc --rpccorsdomain "*" --rpcaddr '<HIDDEN IP>' --rpcport 8545 --ws --wsaddr '<HIDDEN IP>' --wsport <HIDDEN PORT> --verbosity 3 --datadir /root/.ethereum --v5disc --rpcvhosts=* --nat extip:<HIDDEN IP> --lightserv 90 --lightpeers 100UPDATE: Now it has stalled on block
0x41f0d8for an hour so farUPDATE 2: I've launched another rinkeby full node, and it synced just fine
ProDog commentedon May 11, 2019
@folex It's ok after I upgrade my go-ethereum to the latest