Exclude peers if we don't have a complete set of their block summaries.
This tightens up the decision making by adding two requirements:
1. The peer must return the same number of summaries to the ones requested.
2. The peer must return a summary that matches its latest reported signature.
This ensures we are always making sync decisions based on accurate data, and removes peers that are currently mid re-org. This is probably more validation than is actually necessary, but it's best to be really thorough here so it is as optimized as possible.
LOGGER.trace(String.format("Requesting %d block summar%s from peer %s after common block %.8s. Peer height: %d",summariesRequired,(summariesRequired!=1?"ies":"y"),peer,Base58.encode(commonBlockSummary.getSignature()),peerHeight));
LOGGER.trace(String.format("Peer %s returned %d block summar%s",peer,blockSummaries.size(),(blockSummaries.size()!=1?"ies":"y")));
if(blockSummaries.size()<summariesRequired)
// This could mean that the peer has re-orged. But we still have the same common block, so it's safe to proceed with this set of signatures instead.
LOGGER.debug(String.format("Peer %s returned %d block summar%s instead of expected %d",peer,blockSummaries.size(),(blockSummaries.size()!=1?"ies":"y"),summariesRequired));
// This could mean that the peer has re-orged. Exclude this peer until they return the summaries we expect.
LOGGER.debug(String.format("Peer %s returned %d block summar%s instead of expected %d - excluding them from this round",peer,blockSummaries.size(),(blockSummaries.size()!=1?"ies":"y"),summariesRequired));
// We don't have a block summary for the peer's reported chain tip, so should exclude it
LOGGER.debug(String.format("Peer %s didn't return a block summary with signature %.8s - excluding them from this round",peer,Base58.encode(peerLastBlockSignature)));
else
// All looks good, so store the retrieved block summaries in the peer's cache