AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 34 Bitcoin

Merge bitcoin/bitcoin#36080: p2p: Suspend ping timeout while downloading blocks from a peer

Public commit record

What the developer wrote

Authored by merge-script

100/100 · Strong
Merge bitcoin/bitcoin#36080: p2p: Suspend ping timeout while downloading blocks from a peer

d83647e7c48a11dc54ad697342a4b7e3bce9061b p2p: Don't apply ping timeout while downloading blocks (Martin Zumsande)
2b43c62d8ef53edfadf8f097731f48a01b9570cd p2p: move ping timeout check into SendMessages (Martin Zumsande)
8b5bbfe1fca1f4100f858ebfd187dcf74d9d3c82 test: add functional test for pings during IBD (Martin Zumsande)

Pull request description:

While serving blocks, there is a system in place that prioritizes a peer's block requests before answering other p2p messages:
See
https://github.com/bitcoin/bitcoin/blob/11090c8bb359f894ef7d97b65aff52fe8191aec1/src/net_processing.cpp#L5436

As a result it can happen that if we do IBD with a low download bandwidth (that is distributed over 10 peers) a peer will not get around to answering our ping before the timeout of 20 minutes, in which case we would disconnect them, although they have done nothing wrong and are not even slow themselves (we are).
This situation has been described in #35761.

This PR fixes the issue by not enforcing the ping timeout from a peer while downloading blocks from them.
In order to do that, the ping timeout check is moved out of `MaybeSendPing()` (which was a slightly awkward place anyway, given the name of the function) and suspended until there are no longer blocks in flight with that peer (with a grace period, so that we don't disconnect immediately after the last block was received before the peer got a chance to send us the `pong`).

Note that during block download, there are still other timeouts:
- A dynamic timeout (`BLOCK_DOWNLOAD_TIMEOUT_BASE` / `BLOCK_DOWNLOAD_TIMEOUT_PER_PEER`) which will result in a timeout of `600s × (1 + 0.5×9) = 55 minutes` per block when downloading from 10 peers in parallel
- the stalling logic which hits if the peer is much slower in comparison to other peers
- the socket inactivity check disconnects a peer that hasn't sent us anything at all in the last 20 minutes.

So the ping timeout didn't add much value anyway in that situation.

Fixes #35761

ACKs for top commit:
maflcko:
review ACK d83647e7c48a11dc54ad697342a4b7e3bce9061b 🌎
fjahr:
reACK d83647e7c48a11dc54ad697342a4b7e3bce9061b
danielabrozzoni:
ACK d83647e7c48a11dc54ad697342a4b7e3bce9061b
sedited:
ACK d83647e7c48a11dc54ad697342a4b7e3bce9061b

Tree-SHA512: b6986349432117e70b34c7dd812e88cb22e986794f6644b021fee1a282f904d04a2a524415794ec3a22f2f592550a8e89f9416a2a00922184341b280fbc315b4
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change fixes a bug where Bitcoin Core could wrongly disconnect a peer during Initial Block Download (IBD). The problem happened because the node demanded a ping reply within 20 minutes even while the peer was busy sending blocks. With slow bandwidth, the peer could be too busy serving blocks to reply to the ping in time, so the node would drop a perfectly good peer. The fix pauses the ping timeout while blocks are being downloaded from a peer, and adds a one-minute grace period after the last block before the timeout applies again. It is a reliability/availability fix, not a remote exploit.

Recommended action

Treat as a normal bug-fix merge. No emergency action required. Operators running IBD over slow links will benefit from fewer spurious peer disconnections. Reviewers should verify that the grace period and block-in-flight guard correctly prevent premature disconnections without weakening the inactivity/stall protections.

Security signals we found

01

Denial-of-service self-inflicted: low-bandwidth IBD nodes could lose honest peers

02

Ping timeout logic moved to a more appropriate location with additional guard conditions

03

New functional test covers the exact timeout/grace-period behavior

Risk score

Why this scored 34/100

Our methodology →
Potential impact 8/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 7/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.