P2P: ranking notes

Category notes

The band spread is intentionally wide: one memory-DoS amplification fix at P1, a dozen security/liveness/performance items at P2, and a long P3 tail of narrower bug fixes, opt-in features, observability and refactors. Three bands were changed on comparison grounds only (#35724 as a stated prerequisite for a P2, #35642 and #35578 for matching P2 typicals, #36279 down for parity with the other mutation tests); draft, stale and NACK status were ignored throughout.

Review order and overlapping PRs

  • #36277 is explicitly an alternative approach to #34707 for private-broadcast completion/status; decide between them and review #36277 first.
  • Chain: #35558 is rebased on #35724 (compact-block reconstruction logging). Merge order matters; #35724 must land first, which is why it was raised into P2.
  • #34533 (wallet resubmit via private broadcast) and #34457 (wallet private broadcast support) cover overlapping wallet-side ground and #34457 is waiting on coordination with #34533; one scope decision should settle both.
  • #35600 (in-flight destination reservation) and #36014 (init-time -addnode dedup) both target duplicate manual connections; #35600 is the broader runtime fix and should be reviewed first, then #36014 judged as a subset.
  • #34565, #34824, #35502, #35522, #35561, #35040 and #30988 all rework net_processing/net structure and will conflict heavily; a sequencing decision among them is worth more than reviewing any single one in isolation.
  • #36152, #36229, #36279 are all mutation-driven test additions with no bug behind them and now share P4; #36262 (CVE-2024-52914 regression) and #35292/#33954 (new functional coverage) are the substantive test work and stay P3.
  • #36267 backports #36256 and #36260, both already merged in master; it duplicates merged work by design and its band reflects release-branch delivery only.
  • #35054 (P2) and #35591 (P2) both need a concept-level decision rather than line-by-line review; the blocking question, not the code, is what reviewers should engage.

Band and position changes

  • #36142: Only confirmed-exploitable security fix on the list (Tor control injection hijacking inbound onion traffic), so it leads the P2 band.
  • #35642: P3 alone, P2 after comparison. Raised to P2: removes a recurring per-release maintainer burden and stops headers-sync DoS margins degrading over time, which matches P2 typicals.
  • #35578: P3 alone, P2 after comparison. Raised to P2: reviewer telemetry shows network-wide addrman pollution and repeated doomed connections, a durable address-management fix, not a local edge case.
  • #35591: Problem importance keeps it P2, but the full implementation is explicitly not for merge and will be carved up, so it sits behind ready P2 work.
  • #35003: Top of P3: silent inability to advance the chain on disk I/O failure is the most consequential remaining P3, and it needs an approach decision.
  • #34824: Ranked above other refactors because it retires a known message-handling hazard (recursive mutexes, #19303) rather than only reorganizing code.
  • #35750: Addrman correctness fix with a concrete degradation path for multi-network nodes; belongs with the other relay/address bug fixes, not near the tail.
  • #36080: Real disconnection bug during IBD with a linked issue, so placed with peer-management bug fixes rather than below feature work.
  • #35920: BIP144 conformance plus disconnect-logic correctness ranks with protocol fixes, above configuration and observability PRs.
  • #35874: Closes a concrete inbound capacity-accounting bypass; DoS-adjacent fixes grouped ahead of features.
  • #36170: Permission-inheritance hardening but limited to custom bind setups, so slightly below the broader bug fixes.
  • #35696: Valuable I2P crypto upgrade with upstream backing, but no immediate risk from delay, so below correctness fixes.
  • #32065: Privacy hardening limited to transient-session I2P users, placed with the other opt-in privacy/connectivity work.
  • #30951: Opt-in flag against passive observation only; ranked with other operator-facing options rather than near the bug fixes.
  • #33663: Genuine ban-list leakage fix but the approach is still contested among four alternatives, and the effect is minor; grouped with lesser addrman work.
  • #35888: Defense-in-depth against internal caller bugs only, so ranked with hardening rather than with externally triggerable issues.
  • #36177: Startup failure for users following official docs is a real user-facing fix, so above configuration conveniences and observability.
  • #36267: Delivers already-merged Tor-control backoff to the release branch; useful but adds no new fix, so mid-P3.
  • #36014: Placed next to #35600 since both address duplicate manual connections; benefit is limited to misconfigured setups.
  • #35940: Opt-in operator convenience for dedicated peering links, grouped with the other configuration features.
  • #35113: On-demand block fetch retry is a niche convenience with open RPC design objections, so it sits with feature work.
  • #34707: Leads the private-broadcast feature cluster but is superseded in part by #36277, which should be reviewed first.
  • #34322: Narrow window of benefit and may be replaced by a persistent broadcast pool, so below the private-broadcast correctness work.
  • #34533: Wallet-side plumbing over existing private broadcast transport with unresolved package/CPFP objections; belongs with the feature cluster, not near the bug fixes.
  • #34457: Overlaps #34533 and depends on coordinating with it, so reviewed after that decision rather than mid-list.
  • #29418: Observability feature for operators; above pure tracing/test work but below anything fixing behavior.
  • #35368: Pure telemetry addition with no behavior change, so grouped with observability rather than mid-list.
  • #27052: Mostly test coverage plus a reporting field; grouped with the test cluster instead of with behavior fixes.
  • #33954: Test-framework capability with real long-term value, but no behavior change, so it heads the test cluster rather than sitting mid-list.
  • #35292: Adds regression coverage for a functional Tor-control path, so ranked with the other substantive test additions.
  • #35624: Covers an open issue's connection-limit invariant; kept in P3 with the other functional tests.
  • #34565: Refactor with no stated bug or hazard retired and mild architectural skepticism; grouped with the other net_processing decompositions.
  • #35502: Move-only extraction placed next to its sibling #35522 so the two comparable refactors share a neighbourhood.
  • #35315: Type-safety cleanup with no behavioral payoff; belongs with the refactor cluster rather than above feature work.
  • #30988: Kept P3 on the modularity problem, but the originally cited consumers declined, leaving the weakest payoff of the refactors.
  • #36249: Most user-visible of the marginal items (operators can verify the active asmap hash via RPC), so it leads P4.
  • #36279: P3 alone, P4 after comparison. Lowered to P4 for consistency with #36152 and #36229: a single mutation-killing unit test over already-correct behavior, no bug fixed.

About

This pass by claude-opus-5 on 2026-09-17 saw every PR in the category at once and checked the bands given to each PR alone against each other, ordered the PRs, and noted chains and overlaps. Back to the category.