#30951 net: option to disallow v1 connection on ipv4 and ipv6 peers

ReviewabilityReviewsAgreementSize
#30951 stratospher net: option to disallow v1 connection on ipv4 and ipv6 peersReady0Strong99 + 99 tests
  • Allow node operators to enforce encrypted BIP324 transport on clearnet peers
  • Prevent passive ISP snooping and cleartext leaks without disabling clearnet entirely
  • Ready for review
  • Strong support for letting nodes avoid plaintext clearnet leaks (mzumsande, dergoegge, sipa, laanwj)
  • Addressed objection over partition risks for legacy nodes by tuning peer selection (jonatack)
  • Withdrew concept objection after documentation clarified privacy expectations (vasild)
  • Addressed objection to disabling listening by dropping inbound v1 peers instead (gmaxwell)
  • 99 lines added or modified outside tests
  • 99 lines added or modified in tests
  • 11 lines removed in total
  • 10 files, 8 commits
P2P#26 of 71
P2 · new feature
  • P2 because it lets operators protect clearnet peer traffic from passive observers and packet inspection
  • Avoids unencrypted v1 fallback connections while preserving clearnet connectivity
  • Ranking pass: Opt-in operator hardening ranks below the correctness, DoS and privacy fixes in the same band.
Ranking notes
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

Adds a `-v2onlyclearnet` configuration option that disallows unencrypted v1 P2P connections on IPv4 and IPv6 networks. It skips outbound v1 connection attempts to clearnet peers, suppresses v1 downgrade reconnections after failed v2 handshakes, and disconnects inbound clearnet peers that connect with v1 transport. Encrypted overlay networks (Tor, I2P, CJDNS) and non-routable local addresses remain permitted to use v1.

Problem: Bitcoin Core automatically initiates or falls back to unencrypted v1 transport for clearnet peers and accepts inbound v1 connections by default. Users wishing to protect message contents from passive on-path observers such as ISPs cannot enforce transport encryption across IPv4 and IPv6 without disabling clearnet entirely.

Evidence of importance:

  • PR description: 'Currently 70% of reachable nodes in network supporting v2 (according to https://21.ninja/reachable-nodes/node-service-share/ and https://bitnodes.io/nodes). Also found 81% of addresses supporting v2 in the addrman of nodes I checked'
  • Resolves issue #29618 ('V2 Only Option')

Scope: Touches net connection selection and inbound message processing in net_processing to drop v1 clearnet peers.

Risk of a mistake: medium (p2p). Faulty peer transport filtering could cause unexpected peer disconnections or isolate nodes that enable the option.

Changed since the previous assessment: Instead of requiring `-listen=0` to prevent unencrypted inbound traffic, listening is now supported and inbound v1 clearnet connections are disconnected during message processing. Destinations delegated to name proxies are also addressed by assuming worst-case clearnet and requiring v2.

Reviewability

Ready

Nothing known that would invalidate a review now.

Waiting on (from the thread read):

  • reviewer: further code review of Option B update 2026-09-19

Agreement

Strong

substantive support, no open objection (mzumsande, dergoegge, ajtowns, fjahr, sipa, laanwj, sedited, danielabrozzoni, ViniciusCestarii)

Thread notes: Added Concept ACK from l0rinc without substantive rationale.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
jonatack (member)objection, approachWidespread adoption risks network partitioning and peer exhaustion for legacy nodes running older versions.fixed · fix pushed · author restricted the option to outbound connections to eliminate partition riskchangedyes2024-09-28: 'the network partitioning and the lack of peers risks could be imposed on a future minority of users that are running earlier versions of Bitcoin Core.'
Status from: 2024-10-28: stratospher: 'I've rebased and changed the approach in the PR to have v2 only outbound connections. So there's null partition risk'
vasild (member)objection, approachA v2-only option gives the false impression that it hides node operation and protects transaction origin.accepted · withdrawn by reviewer after documentation clarificationschangedyes2024-10-02: 'A V2-only option will: not hide the fact that one runs bitcoin node... but it will give the false impression that it does those two things.'
Status from: 2025-11-11: vasild: 'with this post I would like to withdraw my "Concept NACK" and leave it in your capable hands. Concept 0'
vasild (member)objection, approachDisallowing v1 makes it more difficult for older v1 nodes to find peers to connect to.accepted · withdrawn by reviewer along with Concept NACKchangedyes2024-10-02: 'Further, it will make it more difficult for old nodes to find peers to connect to.'
Status from: 2025-11-11: vasild: 'with this post I would like to withdraw my "Concept NACK" and leave it in your capable hands. Concept 0'
andrewtoth (member)question, approachHow does v2 without inbounds make traffic analysis more difficult than v2 with inbounds?answered · author agreed that traffic analysis is equivalent and clarified the intentansweredyes2026-05-10: 'Can you elaborate on how v2 without inbounds makes traffic analysis more difficult than v2 with inbounds?'
Status from: 2026-05-27: stratospher: 'you're right that they're all the same from a traffic analyser PoV. I should reword/remove that sentence.'
w0xlt (contributor)objection, safetyUnresolved destination hostnames delegated to a proxy might be clearnet addresses and mistakenly connected via unencrypted v1 transport.fixed · fix pushed · addressed in pushchangedyes2026-05-11: 'When pszDest is unresolved because DNS is delegated to a name proxy, it might be better to treat it as possibly IPv4/IPv6 and block v1 under -v2onlyclearnet.'
Status from: 2026-05-27: stratospher: 'pushed an update addressing @w0xlt's comments.'
gmaxwell (contributor)objection, correctnessDNS seeds and static address databases do not set the v2 flag, preventing a cold-start node with v2only from finding any peers.fixed · fix pushed · resolved upstream in #35766 and rebased into this PRchangedyes2026-07-21: 'Addresses learned via dnsseed right now as well as the static addr databases don't have the v2 flag. And so a node that has v2 as a requirement for its peer selection won't find any peers at all from '
Status from: 2026-09-19: stratospher: 'Update: I've switched to Option B.'
gmaxwell (contributor)objection, approachForcing listen=0 is an anti-feature that deprives the network of listening and v2 connection capacity.fixed · fix pushed · author switched to Option B, dropping the listen=0 requirementchangedyes2026-07-21: 'I cannot express how strongly I disagree with forcing listen=0. It is is an outright anti-feature to unnecessarily tie a security/privacy setting to providing resources to others'
Status from: 2026-09-19: stratospher: 'I've switched to Option B. -v2onlyclearnet no longer requires -listen=0.'
gmaxwell (contributor)suggestion, approachOnly allow inbound v1 connections that have fRelay=false to address partitioning concerns.answered · author explained fRelay=false does not prevent the peer from sending transactionsansweredyes2026-07-21: 'An incremental option to address partitioning concerns is to only allow inbound v1 connections that are fRelay=false.'
Status from: 2026-09-19: stratospher: 'fRelay=false only promises that we won't relay transactions to that peer - it doesn't stop the peer from sending transac'

Support:

  • mzumsande (member) (Concept ACK, 2024-09-27) [read]: Allows node runners who want BIP324 encryption benefits to have clearnet peers without leaking plaintext over occasional v1 fallback connections.
  • dergoegge (member) (Concept ACK, 2024-10-02) [read]: Prevents passive spying, increases tampering costs, and increases the difficulty of detecting node operation via stateless packet inspection.
  • ajtowns (member) (Approach ACK, 2025-10-23) [read]: Helps avoid cleartext transaction relay and prevents easy detection by stateless packet inspection, especially when paired with disabled inbound clearnet.
  • fjahr (member) (Concept ACK, 2025-10-29) [read]: Agrees with coupling to nolisten to prevent partition dangers and ensure safe operation.
  • sipa (member) (Concept ACK, 2025-11-03) [read]: V2 deployment is high enough that providing an outbound-v2-only option is reasonable.
  • kristapsk (contributor) (Concept ACK, 2025-11-04): Agrees with adding the option. [not substantive]
  • laanwj (member) (Concept ACK, 2025-11-04) [read]: Convinced that the benefits outweigh the implementation and maintenance costs.
  • sedited (member) (Concept ACK, 2026-03-11) [read]: The project has communicated that v2 protects against passive observers and this option fulfills that goal.
  • danielabrozzoni (member) (Concept ACK, 2026-06-29) [read]: Supports the option and leans toward disallowing incoming connections to minimize worst-case eclipse risks on legacy nodes.
  • ViniciusCestarii (contributor) (Concept ACK, 2026-09-10) [read]: Supports the feature, preferring Option B so node operators can continue offering inbound capacity.
  • l0rinc (member) (Concept ACK, 2026-10-16): Concept ACK without further rationale. [not substantive]

Participants:

  • vasild (member, objection, 9 statements 2024-09-26 to 2026-04-20): Initially Concept NACKed over false privacy assumptions and harm to v1 nodes; later withdrew to Concept 0 once documentation was updated
  • jonatack (member, objection, 4 statements 2024-09-27 to 2024-10-02): Objected to network partition risk for older nodes; suggested restricting the option to outbound connections
  • mzumsande (member, support, 7 statements 2024-09-27 to 2026-08-18): Concept ACK; argued against coupling with listen=0
  • dergoegge (member, support, 1 statements 2024-10-02 to 2024-10-02): Concept ACK
  • sipa (member, support, 2 statements 2024-10-02 to 2025-11-03): Concept ACK for an outbound-v2-only option
  • brunoerg (member, neutral, 1 statements 2024-10-10 to 2024-10-10): Provided a link to mutation testing results
  • laanwj (member, support, 5 statements 2024-10-24 to 2025-11-04): Concept ACK after initially questioning the design
  • luke-jr (contributor, neutral, 6 statements 2025-01-16 to 2025-01-25): Code review on initialization and naming without taking a position on the concept
  • ajtowns (member, support, 5 statements 2025-10-23 to 2025-10-23): Approach ACK; suggested pairing the flag with listen=0
  • fjahr (member, support, 11 statements 2025-10-24 to 2026-04-19): Concept ACK; code reviews and discussion on listen=0 tradeoffs
  • kristapsk (contributor, support, 1 statements 2025-11-04 to 2025-11-04): Concept ACK
  • pinigapic-lang (none, neutral, 1 statements 2026-03-11 to 2026-03-11): Concept ACK without rationale from an account without project history
  • sedited (member, support, 3 statements 2026-03-11 to 2026-08-18): Concept ACK; postponed the PR for v33 due to lack of consensus on coupling with listen=0
  • andrewtoth (member, question, 1 statements 2026-05-10 to 2026-05-10): Asked clarifying questions about traffic analysis and favored requiring listen=0
  • davidgumberg (member, support, 1 statements 2026-05-11 to 2026-05-11): Concept +0 leaning toward Concept ACK; preferred not coupling to listen=0
  • w0xlt (contributor, neutral, 6 statements 2026-05-11 to 2026-05-11): Code review on proxy destinations, initialization, and logging
  • naiyoma (member, support, 2 statements 2026-05-31 to 2026-05-31): Supported the change, leaning toward Option A (forcing listen=0)
  • danielabrozzoni (member, support, 3 statements 2026-06-26 to 2026-06-29): Concept ACK; favored Option A
  • gmaxwell (contributor, objection, 2 statements 2026-07-21 to 2026-07-21): Objected strongly to forcing listen=0 and noted DNS seed v2 flag dependency
  • fanquake (member, neutral, 1 statements 2026-08-18 to 2026-08-18): Process comment noting the need for rebase before feature freeze
  • ViniciusCestarii (contributor, support, 1 statements 2026-09-10 to 2026-09-10): Concept ACK; preferred Option B (allowing inbound v2 connections)
  • l0rinc (member, support, 1 statements 2026-10-16 to 2026-10-16): Concept ACK without rationale

Files

99 lines under test/bench/ci.

  • src/test/net_peer_connection_tests.cpp +67/-0
  • src/net.cpp +32/-9
  • src/net.h +38/-0
  • test/functional/p2p_v2_encrypted.py +25/-0
  • doc/release-notes-30951.md +14/-0
  • src/net_processing.cpp +7/-0
  • test/functional/feature_config_args.py +7/-0
  • src/init.cpp +5/-1
  • src/common/netif.cpp +1/-1
  • src/netbase.h +2/-0

Card

The short text the ranking pass compares across PRs.

Adds the `-v2onlyclearnet` configuration flag to forbid unencrypted v1 P2P traffic over IPv4 and IPv6. Today, nodes fall back to or accept unencrypted v1 clearnet connections, exposing message contents to passive observers such as ISPs unless clearnet is turned off entirely. The option disables outbound v1 clearnet attempts, suppresses v1 fallback on handshake failure, and disconnects inbound v1 clearnet peers during the version handshake, while leaving Tor, I2P, CJDNS, and local connections unaffected. Network measurements cited by the author show roughly 70% of reachable nodes and over 80% of sampled addrman addresses support BIP324 v2 transport.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-17T01:16, confidence high, input hash 2874b3e30c6581cf
thread read through 2026-10-16 (93 statements), head 2f443a4eed
labels: P2P

Categories

P2P

P2 · new feature (ranking pass: Opt-in operator hardening ranks below the correctness, DoS and privacy fixes in the same band.)

Adds the `-v2onlyclearnet` option enabling users to enforce encrypted BIP324 transport and prevent cleartext traffic leaks over clearnet. As reviewers noted, this prevents passive spying and stateless packet inspection by ISPs without forcing node runners off clearnet entirely.

Membership: Labeled P2P and modifies peer connection selection and transport enforcement in src/net.cpp and src/net_processing.cpp.

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