p2p: avoid orphanage abort at high peer counts #35919

pull l0rinc wants to merge 2 commits into bitcoin:master from l0rinc:l0rinc/p2p-handle-zero-orphanage-latency-share changing 2 files +25 −11

l0rinc commented at 8:40 PM on August 6, 2026: contributor

Problem: The orphanage divides a global limit between peers holding orphan transactions. With enough peers, integer division gives each peer an allowance of zero. Adding another orphan then triggers an assertion and aborts the node. The default connection limit is 200, so this requires an unusually high connection count.

Fix: Use a minimum per-peer allowance of one and keep peers at that minimum eligible when choosing what to remove. This lets the orphanage return to the global limit. Add coverage for three peers sharing a limit of two.
DrahtBot added the label P2P on Aug 6, 2026
DrahtBot commented at 8:40 PM on August 6, 2026: contributor


The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35919.



Reviews

See the guideline and AI policy for information on the review process.

Type Reviewers

Stale ACK jeanpablojp

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.



Conflicts

Reviewers, this pull request conflicts with the following ones:
- #35511 (RFC: consensus: Make CAmount a class by hodlinator)
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
DrahtBot closed this on Aug 7, 2026
DrahtBot reopened this on Aug 7, 2026
jeanpablojp commented at 9:50 AM on August 10, 2026: none

ACK 1ac1f10e7b0e06e8d01a35cabf5bef49ea43c69a

Reproduced the abort on master 128456b62d with three peers against a global limit of 2. The two halves of the fix depend on each other: with only the clamp and the old > filter, every peer sits at exactly its floored share, the heap comes out empty and the loop pops from it, which segfaults here. So >= is not cleanup. Full unit suite and p2p_orphan_handling.py pass on the merge.

nit: the comment on MaxPeerLatencyScore() (txorphanage.cpp:210) still says the number of peers times that value adds up to MaxGlobalLatencyScore(), and that keeping every peer below 1 keeps the global limit. LimitOrphans() now enforces a floor of 1 instead, so that stops matching what runs once there are more peers than slots.

nit: the new test passes whichever peer gets trimmed. BOOST_CHECK(!orphanage->HaveTxFromPeer(txns.at(2)->GetWitnessHash(), 2)) pins it, and passes as written.

nit: #include <util/check.h> in orphanage_tests.cpp is added by de6342cd45 and nothing uses it after 1ac1f10e7b. test_bitcoin builds with the line removed.

Type	Reviewers
Stale ACK	jeanpablojp

test: characterize orphanage zero-share behavior

When more peers than global latency slots announce orphans, the per-peer latency share becomes zero and `LimitOrphans()` aborts while calculating a peer DoS score after inserting the orphan.

Use the existing check through `Assert()` so the test can catch the current failure and inspect the resulting state, leaving the following fix to change only orphanage behavior and the marked expectations.

Co-authored-by: JP <jeanpablo.jp@hotmail.com>

fb3e7d549c

p2p: handle zero orphanage latency share

When more peers hold orphan announcements than global latency slots, the per-peer latency share becomes zero and `LimitOrphans()` aborts while calculating candidates for trimming.

Floor the internal latency share at one and include score-one peers in the trim heap, allowing the orphanage to return to its global limits.

5f4429c20c

l0rinc force-pushed on Aug 11, 2026
l0rinc commented at 2:27 AM on August 11, 2026: contributor

Thanks @jeanpablojp, rebased and took all three suggestions (code comment, include and new test) - added you as co-author for the first commit.

Contributors

Labels

p2p: avoid orphanage abort at high peer counts #35919

Code Coverage & Benchmarks

Reviews

Conflicts