#35940 net: allow selecting BIP152 high-bandwidth peers with `-addnode`

This pull request adds an opt-in `=bip152-hb` suffix to the `-addnode` startup option, allowing operators to manually specify outbound peers that should immediately and permanently be requested to send BIP152 high-bandwidth compact block announcements. Connections matching these configured endpoints are sent `SENDCMPCT(high_bandwidth=true)` on handshake and upon reconnect, operating outside of and in addition to the automatic three-peer compact block rotation. The option is validated at startup to ensure it is not used in conjunction with `-blocksonly`.

Problem: Node operators cannot manually designate specific peers for high-bandwidth compact block relay based on out-of-band network topology knowledge. Currently, Bitcoin Core only selects up to three high-bandwidth peers dynamically based on who delivers blocks first, meaning low-latency peering links or private multi-site nodes must wait for automatic selection and risk losing their status upon reconnection.

Evidence of importance:

• PR description: 'an operator may run nodes in multiple locations or maintain a stable, low-latency peering link and want that connection to announce compact blocks immediately and consistently, including after reconnects, instead of waiting for automatic selection.'

Scope: Refactors how -addnode options are passed into CConnman via AddedNodeParams structs, moving the v2 transport decision from CConnman::Init() to init.cpp.

Paused · Waiting on author

Open objections from Bicaru20 with no author reply for 17 days; review would repeat what has been asked.

Waiting on (from the thread read):

• author: respond to suggestions from Bicaru20 for additional functional test coverage 2026-10-15
• author: respond to test suggestions from Bicaru20 2026-10-15

Strong

substantive support, no open objection (jeanpablojp, Bicaru20)

Thread notes: Added Concept ACK from Bicaru20 and recorded their two functional test suggestions, which are currently awaiting author response. Also captured the release note file naming question from jeanpablojp that was resolved. / Added Concept ACK and two functional test suggestions from Bicaru20. Recorded jeanpablojp's release notes naming remark as an answered suggestion.

Objections, suggestions, and questions:

Support:

• jeanpablojp (contributor) (Concept ACK, 2026-08-14) [read]: The opt-in override of the BIP152 three-peer cap seems fine to me, since it's an explicit operator choice, not a default, and it's disclosed upfront. Reusing `-addnode` also made more sense to me than creating a dedicated option.
• Bicaru20 (contributor) (Concept ACK, 2026-10-15) [read]: I think it’s a good addition to let users add their own high-bandwidth peers, as it gives them more control. I was initially worried about there being no cap on the number of user-selected high-bandwidth peers. However, since this will mostly be used by advanced users, it only affects the operator's

Participants:

• jeanpablojp (contributor, support, 2 statements 2026-08-14 to 2026-08-14): Concept ACK, supports reusing -addnode and allowing operator-configured BIP152 cap override
• Bicaru20 (contributor, support, 3 statements 2026-10-15 to 2026-10-15): Concept ACK, suggested additional test cases for empty addnode and peer reconnect

109 lines under test/bench/ci.

• src/test/net_peer_connection_tests.cpp +48/-0
• test/functional/p2p_compactblocks_hb.py +39/-1
• src/init.cpp +23/-3
• src/net.cpp +25/-0
• test/functional/feature_config_args.py +21/-0
• src/net_processing.cpp +14/-5
• src/net.h +7/-7
• doc/release-notes-35940.md +12/-0

The short text the ranking pass compares across PRs.

This pull request allows node operators to designate specific outbound added nodes as BIP152 high-bandwidth compact block peers via a new =bip152-hb suffix on -addnode. Currently, Bitcoin Core automatically selects up to three high-bandwidth peers dynamically, preventing operators with dedicated low-latency peering links or multi-region nodes from guaranteeing immediate compact block announcements. Configured peers receive high-bandwidth requests at handshake and across reconnects without displacing or entering the dynamic three-peer rotation pool. Evidence of importance is limited to the author's description of operational needs for multi-datacenter node setups and dedicated peerings.

P3 · new feature

Adds an opt-in parameter allowing operators to manually select peers for persistent high-bandwidth BIP152 compact block relay. This provides a clear use case for operators running multi-site nodes or private peering links who need predictable compact block announcements, but automatic dynamic peer selection already functions and the addition is reasonably deferrable.

Membership: Labeled P2P and modifies peer connection management and compact block relay handling in src/net.cpp and src/net_processing.cpp.

Factors: security/stability 0, bug 0, performance 1, user value 2, leverage 0