#30951 net: option to disallow v1 connection on ipv4 and ipv6 peers
https://github.com/bitcoin/bitcoin/pull/30951 · · +104/-4 in 9 files, 6 commits · labels: P2P, Needs rebase
Goal
- Let node operators disallow unencrypted v1 clearnet P2P connections
- Prevents passive network observers from inspecting plaintext messages without needing Tor or I2P
This pull request introduces a new configuration option `-v2onlyclearnet` that disallows unencrypted v1 P2P connections on IPv4 and IPv6 networks. When enabled, the node will only establish outbound clearnet connections if BIP 324 v2 encryption can be used, dropping v1 fallback and v1 reconnections. In its current revision, the option also enforces `-listen=0` to prevent accepting unencrypted clearnet inbounds.
Problem: Unencrypted v1 P2P traffic over clearnet allows passive network observers, such as internet service providers and corporate firewalls, to inspect Bitcoin message contents and detect transaction relays. Node operators seeking to avoid transmitting plaintext data across clearnet currently have to disable clearnet entirely or rely on overlay networks like Tor and I2P.
Category: P2P (#25 of 65)
P3 · new feature
- P3 because it offers a strict guarantee against passive wiretapping for operators who need it
- Deferrable because opportunistic v2 is already default and it does not protect against active adversaries
Clear use case and real value for node operators who need a strict guarantee that outbound clearnet traffic is encrypted against passive wiretappers. It is reasonably deferrable as v2 is already the opportunistic default, and this opt-in flag does not defend against active MITM adversaries or hide node operation.
Membership: Modifies P2P connection handling in src/net.cpp and src/net.h to restrict clearnet transport protocol negotiation to BIP 324 v2.
Factors: security/stability 1, bug 0, performance 0, user value 2, leverage 1
Reviewability: Stale: Needs rebase
- Needs rebase due to merge conflicts
- Awaiting author choice between forcing listen=0 and supporting v2 inbounds
The branch has merge conflicts with master and requires a rebase. Additionally, reviewers are waiting on the author to decide between Option A (forcing listen=0) and Option B (allowing v2 inbounds).
Author status: Active, but currently addressing feedback after rebasing and missing the v32.0 feature freeze; postponed to v33.0.
Open concerns:
- Approach disagreement over Option A (requiring listen=0 and dropping all inbounds) versus Option B (allowing inbound v2 connections and preserving listening capacity on the network)
- Concerns from gmaxwell and mzumsande that tying a privacy option to listen=0 damages network listening capacity without protecting legacy v1 nodes
- Persistent concept objection from 1440000bytes stating that the feature creates false privacy expectations and partition risks
Resolved concerns:
- vasild's initial Concept NACK was withdrawn after help text and release notes were updated to clearly state that v2 does not obscure node presence or protect against active MITM adversaries
- Handling of unresolved DNS names when proxying was addressed so unverified destination hosts are not accidentally contacted via v1
- A dependency on DNS seeds lacking v2 service flags was resolved upstream in PR #35766
Agreement: Disputed
- Broad concept support for an opt-in v2-only clearnet setting (mzumsande, sipa, dergoegge, laanwj, fjahr)
- Strong objection to forcing listen=0 because it harms network listening capacity (gmaxwell, mzumsande)
- Concept objection: creates false privacy expectations and partition risks (1440000bytes)
- Postponed due to lack of consensus on coupling with listen=0 (sedited)
Concept supported, but disputed approach on whether to force -listen=0 (gmaxwell, mzumsande oppose; ajtowns, author currently implement it).
Most reviewers support adding an opt-in v2-only clearnet configuration, but there is an active disagreement on implementation approach. Reviewers including gmaxwell and mzumsande strongly object to requiring listen=0 because it unnecessarily strips listening sockets from the network, causing the PR to be postponed to v33.0.
- mzumsande, sipa, dergoegge, laanwj, sedited, fjahr, and others Concept ACKed adding an option to enforce v2 on clearnet.
- gmaxwell strongly objected to forcing listen=0: 'I cannot express how strongly I disagree with forcing listen=0. It is an outright anti-feature to unnecessarily tie a security/privacy setting to providing resources to others'.
- 1440000bytes NACKed, claiming the change gives a false impression of hiding node operation and harms the network.
- sedited confirmed postponement: 'looks to me that there is no agreement among reviewers about coupling it to listen=0... postponing this.'
Review verdicts (DrahtBot): 0 -1
- Approach ACK: ajtowns
- Concept ACK: mzumsande, dergoegge, fjahr, sipa, kristapsk, laanwj, sedited, pinigapic-lang, davidgumberg, danielabrozzoni, ViniciusCestarii
- Concept NACK: 1440000bytes
Files
35 lines under test/bench/ci.
- src/net.h +29/-0
- test/functional/p2p_v2_encrypted.py +25/-0
- src/net.cpp +13/-2
- src/init.cpp +11/-1
- doc/release-notes-30951.md +11/-0
- test/functional/feature_config_args.py +10/-0
- src/common/netif.cpp +1/-1
- src/netbase.cpp +2/-0
- src/netbase.h +2/-0
Card
PR #30951 adds an opt-in -v2onlyclearnet configuration flag that disallows unencrypted v1 P2P connections to IPv4 and IPv6 peers. This allows privacy-conscious operators to protect outbound clearnet message contents against passive eavesdropping by ISPs or firewalls. While there is broad concept approval for the feature, the PR was deferred to milestone 33.0 due to an unresolved approach dispute over whether to force -listen=0 or permit v2-only inbounds. The branch is currently stale and needs a rebase.