When picking fast sync pivot block, use the peer with the best total difficulty #899
Conversation
…difficulty, not the highest chain.
| @@ -33,6 +33,9 @@ | |||
| public static final Comparator<EthPeer> CHAIN_HEIGHT = | |||
| Comparator.comparing(((final EthPeer p) -> p.chainState().getEstimatedHeight())); | |||
|
|
|||
| private static final Comparator<EthPeer> HIGHEST_TOTAL_DIFFICULTY_PEER = | |||
| TOTAL_DIFFICULTY.thenComparing(CHAIN_HEIGHT); | |||
There was a problem hiding this comment.
Apart from total difficulty (which is the only thing the yellow paper defines) do we know what other clients do to distinguish heavier chains? Chain height is a quick win but Ghost also originally defined ommers as adding to the difficulty (but that's not in the yellow paper). Section 10 implies chain height but it doesn't make it into the formal definition equations.
There was a problem hiding this comment.
The only thing that matters is total difficulty - if two chains have the same difficulty then clients will generally stick with whichever one they had first (ie equal difficulty does not trigger a re-org) although I have a vague memory of Geth including randomness in there for some reason.
Since Byzantium the difficulty of a block is increased if it contains any ommers.
…difficulty, not the highest chain. (PegaSysEng#899)
PR description
When picking the fast sync pivot block, ensure the peer we consider best is evaluated on total difficulty, instead of chain height. Otherwise on MainNet we tend to pick an ETC node and pivot block because it has a greater height even though it has lower total difficulty.