diff options
| author | fanquake <fanquake@gmail.com> | 2022-06-27 14:17:01 +0100 |
|---|---|---|
| committer | fanquake <fanquake@gmail.com> | 2022-06-27 14:21:49 +0100 |
| commit | 2fe27029f5426592d0edddf40b36af54709ddb80 (patch) | |
| tree | 1d304a28dc7f3a1c0128530dc7f76ff51a29bc77 /src | |
| parent | c8261026a4baf5b189ff555f4d53d4d426ec6441 (diff) | |
| parent | e357c8953880715a943b892deed04e7777187999 (diff) | |
| download | bitcoin-2fe27029f5426592d0edddf40b36af54709ddb80.tar.xz | |
Merge bitcoin/bitcoin#25404: p2p, doc: Use MAX_BLOCKS_TO_ANNOUNCE consistently
e357c8953880715a943b892deed04e7777187999 p2p, doc: Use MAX_BLOCKS_TO_ANNOUNCE consistently (Martin Zumsande)
Pull request description:
Block announcements via headers may have up to `MAX_BLOCKS_TO_ANNOUNCE = 8` entries according to the definition of this constant.
However, there are a few spots saying they should have a size _less than_ `MAX_BLOCKS_TO_ANNOUNCE`. Fix these.
I don't think that this is critical (this only changes behavior when we get a headers announcement with exactly `MAX_BLOCKS_TO_ANNOUNCE` blocks which we can't connect), but it would be nice to handle this limit consistently.
ACKs for top commit:
dergoegge:
utACK e357c8953880715a943b892deed04e7777187999 - This PR makes the usage and docs of `MAX_BLOCKS_TO_ANNOUNCE` consistent with its description.
Tree-SHA512: f3772026ab0f402e3a551127ef6e4a98fa9e7af250715fe317c05988b5b33f2f3e098a00e03960d4d28c8bd2b7a97231f7f99f22f1c152c000b2e27b658cf8f2
Diffstat (limited to 'src')
| -rw-r--r-- | src/net_processing.cpp | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/src/net_processing.cpp b/src/net_processing.cpp index bc7d42ac20..a556180721 100644 --- a/src/net_processing.cpp +++ b/src/net_processing.cpp @@ -2212,7 +2212,7 @@ void PeerManagerImpl::ProcessHeadersMessage(CNode& pfrom, Peer& peer, LOCK(cs_main); CNodeState *nodestate = State(pfrom.GetId()); - // If this looks like it could be a block announcement (nCount < + // If this looks like it could be a block announcement (nCount <= // MAX_BLOCKS_TO_ANNOUNCE), use special logic for handling headers that // don't connect: // - Send a getheaders message in response to try to connect the chain. @@ -2220,7 +2220,7 @@ void PeerManagerImpl::ProcessHeadersMessage(CNode& pfrom, Peer& peer, // don't connect before giving DoS points // - Once a headers message is received that is valid and does connect, // nUnconnectingHeaders gets reset back to 0. - if (!m_chainman.m_blockman.LookupBlockIndex(headers[0].hashPrevBlock) && nCount < MAX_BLOCKS_TO_ANNOUNCE) { + if (!m_chainman.m_blockman.LookupBlockIndex(headers[0].hashPrevBlock) && nCount <= MAX_BLOCKS_TO_ANNOUNCE) { nodestate->nUnconnectingHeaders++; m_connman.PushMessage(&pfrom, msgMaker.Make(NetMsgType::GETHEADERS, m_chainman.ActiveChain().GetLocator(m_chainman.m_best_header), uint256())); LogPrint(BCLog::NET, "received header %s: missing prev block %s, sending getheaders (%d) to end (peer=%d, nUnconnectingHeaders=%d)\n", @@ -4777,7 +4777,7 @@ bool PeerManagerImpl::SendMessages(CNode* pto) // Try sending block announcements via headers // { - // If we have less than MAX_BLOCKS_TO_ANNOUNCE in our + // If we have no more than MAX_BLOCKS_TO_ANNOUNCE in our // list of block hashes we're relaying, and our peer wants // headers announcements, then find the first header // not yet known to our peer but would connect, and send. |