9

Whilst syncing a new full node using the geth comand "geth --syncmode full", every other line after a few hundred blocks I see the following:

WARN [12-02|02:30:46] Skipping deep transaction reorg          depth=2048

This has continued all the way to ~1.6M blocks synced.

Terminal screenshot: screenshot of terminal displaying warning messsages

Is this a problem? Is it a security issue? Does it represent a 'bad' peer, a sybil attack, or something far more benign?

FYI, I'm using the latest geth version (Geth/v1.7.2-stable-1db4ecdc/linux-amd64/go1.9) on Ubuntu 17.10.

  • Perhaps you are synchronizing closer to a fork in the blockchain and some of the peers are in the wrong chain, it should fix itself given some time. You can try restarting geth so it will try to connect with a new sets of peers. – Ismael Dec 5 '17 at 1:56
1

Manually add some well-reputed peers/bootnodes. The following guide runs through how to do this using geth, either via IPC or a config file: https://github.com/ethereum/go-ethereum/wiki/Connecting-to-the-network

1

A reorg is done only if a block being imported on a side fork leads to a higher total difficulty on that particular fork than the canonical fork. The blocks nonetheless still need to be valid.

As written in the Ethereum blog, Chain reorganisations happen when a node on the Ethereum network realises that what it thought was the canonical chain turned out not to be. When this happens, the transactions in the latter part of its chain (i.e. the most recent transactions) are reverted and rather the transactions in the newer replacement are executed.

With Ethereum having a short target block time of 15s, this actually happens naturally rather often. Because it takes time for the blocks to percolate through the network, it’s easy for different parts of the network to have a different final block (or two, or perhaps even three) in normal operation since the miners often come up with them at roughly the same time. This is what we might call ephemeral forking.

When a re-organisation happens, or put another way, when the network reaches a more global consensus that it had earlier and a fork is resolved, the nodes that had the now out-dated chain “reorganise” their chain, throwing away the recent and no-longer canonical blocks. Transactions are reverted and others executed to get in line with the other path of the fork.

When chain reorg occurs in Ethereum, the common way is first find common block, insert the block with the more total difficuty, and keep the transaction within the old chain but not within the new chain back to txpool. You can read more about Chain Reorganisation issues here as well.

protected by eth Dec 5 '17 at 6:35

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.