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

w0xlt commented at 5:57 AM on August 10, 2026: contributor

Bitcoin Core automatically selects up to three BIP152 high-bandwidth peers after they deliver useful blocks. This works for ordinary connections, but it cannot use topology information known by the operator.

For example, 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.

This PR adds an opt-in suffix:

-addnode=<host>[:port]=bip152-hb

A matching outbound peer receives the existing SENDCMPCT(1) request after the handshake. The policy is reapplied on reconnect and requires no new P2P protocol messages.

Configured peers are additional to the three automatically selected peers and are not included in automatic rotation. This intentionally allows explicit configuration to exceed BIP152’s current three-peer limit and may increase redundant bandwidth. If accepted, BIP152 can be updated separately.

The option is incompatible with -blocksonly. Untagged addnodes, inbound connections, and the addnode RPC retain their existing behavior; RPC support can be considered separately.

net, init: pass -addnode values to CConnman as AddedNodeParams

Build the AddedNodeParams records in init.cpp instead of passing raw
strings to CConnman, and move the added-node v2 transport decision out of
CConnman::Init() accordingly. This lets startup code attach per-added-node
settings in a follow-up commit.

No behavior change.

b1a6f73333

net: match outbound peers to BIP152 HB added-node policy

Match durable outbound peers against persistent added-node records without
carrying policy through connection creation. Snapshot tagged endpoints
under the added-node mutex, then compare exact destinations and numeric
services without name lookups.

This covers normal added-node connections, name-proxy destinations,
numeric aliases, and BIP324 reconnections while keeping DNS out of
connection initialization.

cd501f9b6b

net, init: configure BIP152 high bandwidth for added nodes

Recognize the exact =bip152-hb suffix on persistent -addnode entries and
classify matching durable outbound peers during peer initialization.

Use the existing SENDCMPCT sent at VERACK to request high-bandwidth
announcements, and keep configured peers outside the automatic
three-peer rotation list.

f6b7fb689c

DrahtBot added the label P2P on Aug 10, 2026

DrahtBot commented at 5:57 AM on August 10, 2026: contributor

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

External sites

Code coverage & benchmarks: https://corecheck.dev/bitcoin/bitcoin/pulls/35940
Ralph review <img src=https://review.fish.foo/assets/bitcoin/bitcoin/35940.png alt="Ralph review status"> https://git.fish.foo/bitcoin/bitcoin/pulls/35940#author-ralph

Reviews

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

Type	Reviewers
Concept ACK	jeanpablojp, Bicaru20

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:

#36257 <img src="https://drahtbot.space/ack_count/bitcoin/bitcoin/36257.svg"> (qa: assert_equals -> assert_true/assert_false by hodlinator)
#36014 <img src="https://drahtbot.space/ack_count/bitcoin/bitcoin/36014.svg"> (init: ignore repeated -addnode startup values by w0xlt)
#35561 <img src="https://drahtbot.space/ack_count/bitcoin/bitcoin/35561.svg"> (net: move some CNodeState fields to Peer by Crypt-iQ)
#30951 <img src="https://drahtbot.space/ack_count/bitcoin/bitcoin/30951.svg"> (net: option to disallow v1 connection on ipv4 and ipv6 peers by stratospher)

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.

jeanpablojp commented at 11:32 PM on August 14, 2026: contributor

Concept ACK

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.

doc: add release note for BIP152 high-bandwidth added nodes 3072e06744

in doc/release-notes-35940.md:1 in 8ebd31e84c outdated

   0 | @@ -0,0 +1,12 @@
   1 | +P2P and network changes

jeanpablojp commented at 11:32 PM on August 14, 2026:

shouldn't this be renamed to release-notes-35940.md before merge?

w0xlt commented at 10:34 PM on September 16, 2026:

Done. Thanks.

w0xlt force-pushed on Sep 16, 2026

in test/functional/feature_config_args.py:302 in 3072e06744

 297 | +
 298 | +        node.assert_start_raises_init_error(
 299 | +            extra_args=["-blocksonly", "-addnode=127.0.0.1:18444=bip152-hb"],
 300 | +            expected_msg="Error: Invalid -addnode value '127.0.0.1:18444=bip152-hb': the bip152-hb suffix is incompatible with -blocksonly",
 301 | +        )
 302 | +

Bicaru20 commented at 1:40 PM on October 15, 2026:

Following the same pattern as in the test_empty_addnode in line 268 of the same file, I think we could also check the case where an -addnodeis empty but carries the suffixbip152-hb (-addnode==bip152-hb`).

        with node.assert_debug_log(expected_msgs=["Ignoring empty -addnode value"]):
            self.start_node(0, extra_args=["-blocksonly", "-addnode==bip152-hb"])
        util.assert_equal(node.getaddednodeinfo(), [])

in test/functional/p2p_compactblocks_hb.py:131 in 3072e06744

 126 | +            assert_equal(status, [True, nodeid >= 3, nodeid >= 4, nodeid >= 5])
 127 | +
 128 | +        # Receiving another block from the configured peer must not insert it
 129 | +        # into the automatic list or displace one of those three peers.
 130 | +        assert_equal(self.relay_block_through(2), [True, True, True, True])
 131 | +

Bicaru20 commented at 1:42 PM on October 15, 2026:

We could add the test case where a configured peer disconnects and reconnects again on its own is granted the high-bandwidth mode again.

        self.restart_node(2)
        self.wait_until(configured_peer_connected)
        assert_equal(self.relay_block_through(3), [True, True, True, True])

Bicaru20 commented at 1:55 PM on October 15, 2026: contributor

Concept ACK

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 own node, and the release notes already warn about the extra bandwidth, I think it's okay to leave it as is.