From 53b86d0de5440ffb94f6742e26dd1fd9e11952f2 Mon Sep 17 00:00:00 2001 From: Daniel Kraft Date: Wed, 14 Oct 2015 20:42:49 +0200 Subject: [PATCH] doc: add comment explaining initial header request Add a comment that explains why the initial "getheader" requests are made starting from the block preceding the currently best one. Thanks to sdaftuar for the explanation! --- src/main.cpp | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/main.cpp b/src/main.cpp index baad7fc050be6..e931d40c9462c 100644 --- a/src/main.cpp +++ b/src/main.cpp @@ -4955,7 +4955,16 @@ bool SendMessages(CNode* pto, bool fSendTrickle) if ((nSyncStarted == 0 && fFetch) || pindexBestHeader->GetBlockTime() > GetAdjustedTime() - 24 * 60 * 60) { state.fSyncStarted = true; nSyncStarted++; - CBlockIndex *pindexStart = pindexBestHeader->pprev ? pindexBestHeader->pprev : pindexBestHeader; + const CBlockIndex *pindexStart = pindexBestHeader; + /* If possible, start at the block preceding the currently + best known header. This ensures that we always get a + non-empty list of headers back as long as the peer + is up-to-date. With a non-empty response, we can initialise + the peer's known best block. This wouldn't be possible + if we requested starting at pindexBestHeader and + got back an empty response. */ + if (pindexStart->pprev) + pindexStart = pindexStart->pprev; LogPrint("net", "initial getheaders (%d) to peer=%d (startheight:%d)\n", pindexStart->nHeight, pto->id, pto->nStartingHeight); pto->PushMessage("getheaders", chainActive.GetLocator(pindexStart), uint256()); }