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

stratospher commented at 12:23 PM on September 23, 2024: contributor

resolves #29618.

This PR adds a config flag option -v2onlyclearnet which disallows outbound v1 connections on ipv4 and ipv6 networks since they're unencrypted. outbound v1 connections are still possible from tor/i2p/cjdns peers since they're encrypted networks.

v1 outbound connections to peers are not attempted
v1 reconnections are not attempted (if peer is falsely advertised as v2 peer and we attempt a v2 connection but it fails, we do not attempt a v1 reconnection when -v2onlyclearnet is switched on)

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 - personal node and the nodes in peer.observer. (You can use this branch to check the % of v2 addresses in a node's addrman.)

DrahtBot commented at 12:23 PM on September 23, 2024: contributor

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

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/30951.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept NACK	1440000bytes, vasild
Concept ACK	mzumsande, dergoegge, fjahr, sipa, kristapsk, laanwj, sedited, pinigapic-lang
Approach ACK	ajtowns

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

Conflicts

No conflicts as of last run.

LLM Linter (✨ experimental)

Possible typos and grammar issues:

Note: Encryption protects message contents but does not obscure that you are running a Bitcoin node. -> Note: Encryption protects message contents but does not obscure the fact that you are running a Bitcoin node. [“obscure that …” is ungrammatical/awkward and requires guessing the intended phrasing.]

Possible places where named args for integral literals may be used (e.g. func(x, /*named_arg=*/0) in C++, and func(x, named_arg=0) in Python):

node0.addnode("15.61.23.23:1234", "onetry", True) in test/functional/p2p_v2_encrypted.py
node0.addnode("8.8.8.8:1234", "onetry", False) in test/functional/p2p_v2_encrypted.py
node0.addnode(addr, "onetry", False) in test/functional/p2p_v2_encrypted.py

DrahtBot added the label P2P on Sep 23, 2024

DrahtBot added the label CI failed on Sep 23, 2024

stratospher force-pushed on Sep 24, 2024

DrahtBot removed the label CI failed on Sep 24, 2024

stratospher force-pushed on Sep 25, 2024

vasild commented at 4:40 PM on September 26, 2024: contributor

In #29618 and here, I don't see the motivation to forbid v1 connections. In other words, what is the purpose of this?

In addition to the concerns expressed in #29618, there is one more - if V2-only is widespread, it may be hard to eclipse V2-only node, but then it becomes easy to eclipse a V1 node which has a problem of finding peers to connect to, so an attacker starts a lot of nodes that do accept V1 connections.

I see possible downsides and 0 benefit of a v2only option.

mzumsande commented at 3:54 PM on September 27, 2024: contributor

Concept ACK

In #29618 and here, I don't see the motivation to forbid v1 connections.

Well, to gain the benefits of BIP324. For example if you are concerned about someone inspecting the traffic to your node it really doesn't matter how many BIP324 peers you have if you have just one unencrypted connection. You could also run tor-only in this case, but that has its own disadvantages and -onlynet=onion shares the exact same downside that if everyone did it, the network would split. If some, but not all nodes who are running only on privacy networks would be willing to also have clearnet peers with this option, that would be a good thing in my opinion.

if V2-only is widespread

that would be a problem, but -onlynet, -blocksonly etc. have that exact same problem. I see this as an option you would only choose if you actually need it because you are concerned about unencrypted traffic.

jonatack commented at 9:35 PM on September 27, 2024: member

You could also run tor-only in this case, but that has its own disadvantages and -onlynet=onion shares the exact same downside that if everyone did it, the network would split.

Our docs address this to an extent here and here. As those docs point out, -onlynet only affects outbound connections (not inbound and manual ones), and we suggest that it be used with multiple networks. My blog goes further into it here and here.

If some, but not all nodes who are running only on privacy networks would be willing to also have clearnet peers with this option, that would be a good thing in my opinion.

Agree. My node, for instance, runs over tor/i2p/cjdns and makes manual connections to trusted clearnet peers.

if V2-only is widespread, it may be hard to eclipse V2-only node, but then it becomes easy to eclipse a V1 node which has a problem of finding peers to connect to, so an attacker starts a lot of nodes that do accept V1 connections.

Agree. With this change, clearnet node operators may need to accept v2, whether they wish to or not. We generally try to avoid forcing users to do things. I suppose my concept ack on this would depend on that tradeoff.

vasild commented at 4:28 AM on September 28, 2024: contributor

For example if you are concerned about someone inspecting the traffic to your node it really doesn't matter how many BIP324 peers you have if you have just one unencrypted connection.

True. Lets dive a bit deeper - what are the reasons to be concerned about somebody inspecting the traffic to my node?

in src/init.cpp:553 in ab5f8759ab outdated

 549 | @@ -550,6 +550,7 @@ void SetupServerArgs(ArgsManager& argsman, bool can_listen_ipc)
 550 |      argsman.AddArg("-i2pacceptincoming", strprintf("Whether to accept inbound I2P connections (default: %i). Ignored if -i2psam is not set. Listening for inbound I2P connections is done through the SAM proxy, not by binding to a local address and port.", DEFAULT_I2P_ACCEPT_INCOMING), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
 551 |      argsman.AddArg("-onlynet=<net>", "Make automatic outbound connections only to network <net> (" + Join(GetNetworkNames(), ", ") + "). Inbound and manual connections are not affected by this option. It can be specified multiple times to allow multiple networks.", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
 552 |      argsman.AddArg("-v2transport", strprintf("Support v2 transport (default: %u)", DEFAULT_V2_TRANSPORT), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
 553 | +    argsman.AddArg("-v2onlyclearnet", strprintf("Disallow v1 connections on IPV4/IPV6 (default: %u). Enabling this is not recommended unless absolutely necessary, as it may risk network partitions if all users enable it.", false), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);

jonatack commented at 1:21 PM on September 28, 2024:

Enabling this is not recommended unless absolutely necessary, as it may risk network partitions

This is unfortunately only one brigading campaign by one or more prominent bitcoiners on social media away from being potentially adopted by many nodes.

With -onlynet, the network partition risk is in practice opt-in, i.e. chosen by a minority subset for themselves. Whereas here, 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. This seems at odds with maintaining backward compatibility for that minority.

in src/net.h:1583 in ab5f8759ab outdated

1576 | @@ -1572,6 +1577,13 @@ class CConnman
1577 |       */
1578 |      bool whitelist_relay;
1579 |  
1580 | +    /**
1581 | +     * option for disabling v1 connections on IPV4 and IPV6.
1582 | +     * connections on IPV4/IPV6 need to be v2 connections.
1583 | +     * connections on Tor/I2P/CJDNS maybe v1 or v2 connections.

jonatack commented at 1:22 PM on September 28, 2024:

"may be" or "can be"

     * connections on Tor/I2P/CJDNS can be v1 or v2 connections.

mzumsande commented at 7:54 PM on September 28, 2024: contributor

True. Lets dive a bit deeper - what are the reasons to be concerned about somebody inspecting the traffic to my node?

Some thoughts off the top my head:

You don't want others (e.g. network admins, internet providers, etc.) to know that you are running a bitcoin node at all. Maybe it's not allowed in your network / country etc., maybe for other reasons such as personal security.
Transaction privacy

In both of these cases, if you accept inbounds they could just connect to you as an alternative (but they would need to have a suspicion, whereas detection of bitcoin-related network data could be automated). So another alternative would be to only disallow v1 connections for outbound peers. In that case, if you don't want any v1 connections at all you'd have to run with -nolisten.

DrahtBot added the label CI failed on Sep 29, 2024

DrahtBot removed the label CI failed on Sep 29, 2024

vasild commented at 4:51 PM on September 29, 2024: contributor

what are the reasons to be concerned about somebody inspecting the traffic to my node?

You don't want others (e.g. network admins, internet providers, etc.) to know that you are running a bitcoin node at all. Maybe it's not allowed in your network / country etc., maybe for other reasons such as personal security.

This is what is worrying me - V2-only will not hide the fact that I am running a bitcoin node, but may give the false impression that it does. This is dangerous. My node will connect to publicly known bitcoin nodes and the mere fact that I have a TCP connection to an addr:port, where it is known that a bitcoin node is running, is already revealing enough. No need to inspect the traffic itself.

Another possible misunderstanding is that V2-only makes the traffic impossible to spy. I can imagine a blatant MITM, which is detectable because the session keys would differ, should somebody bother to check them. Once I detect this, whom am I going to complain to? My oppressive gov/ISP/whatever, same one that is doing the spying? Or the ISP can outright redirect my connections to addr:port to their spy node at spyaddr:port (I think I am talking to addr, but addr does not even have a connection from me). The point is that the traffic is spyable. Then, what is it so much that I want to keep away from spies? The data being transferred is all public, except if we are talking about me broadcasting my own transactions, there you go:

Transaction privacy

V2-only may give the false impression that it breaks the link between transaction origin and IP address / geolocation. Even with unspyable p2p encryption, I may have a connection to a spy bitcoin node which then sees my traffic. Like you said "it really doesn't matter how many BIP324 peers you have if you have just one unencrypted connection" I think this is the same as "it does not matter even if all your connections are encrypted, if you have just one (encrypted) connection to a spy node".

stratospher commented at 6:20 PM on September 29, 2024: contributor

@vasild V2 only doesn't protect against active attacks like the ones you've mentioned which require resources from the other party to run a node to spy the traffic.

V2 only protects against a cheaper attack vectors possible because of passive inspection of network traffic flowing through different medium. They don't need the other party to run a node to spy.

True. Lets dive a bit deeper - what are the reasons to be concerned about somebody inspecting the traffic to my node?

Some thoughts off the top my head:

You don't want others (e.g. network admins, internet providers, etc.) to know that you are running a bitcoin node at all. Maybe it's not allowed in your network / country etc., maybe for other reasons such as personal security.

Transaction privacy

Yes, for the same reason as wanting to encrypt network traffic in the first place and this just offers a stronger guarantee when running a node with v2 support that unencrypted clearnet bitcoin traffic is not being collected and sold by other parties. Deep packet inspection, keyword filtering are cheaper for ISPs/firewalls to pull off and v2 only would protect against this.

vasild commented at 11:53 AM on October 2, 2024: contributor

A V2-only option will:

not hide the fact that one runs bitcoin node (that is true regardless of encryption) and
not stop even moderately motivated actor from spying for transaction origin (either by opening a P2P connection to the target or bricking V2 encryption or outright redirecting connections to their node)

but it will give the false impression that it does those two things. Further, it will make it more difficult for old nodes to find peers to connect to.

Concept NACK because of that.

dergoegge commented at 12:45 PM on October 2, 2024: member

Concept ACK

This option seems useful for users that want to:

prevent passive spying on their connections
increase the cost of tampering with the data exchanged on their connections
increase the cost of detecting that they run a bitcoin node

Currently 59.71% of network supports v2

Have you checked how diverse these ~60% of v2 supporting nodes are? An extreme example: if they are all on running on AWS then I don't think we should add the option at this time.

vasild commented at 2:19 PM on October 2, 2024: contributor

increase the cost of detecting that they run a bitcoin node

How? Given that the spy does not need to inspect the traffic at all:

My node will connect to publicly known bitcoin nodes and the mere fact that I have a TCP connection to an addr:port, where it is known that a bitcoin node is running, is already revealing enough.

sipa commented at 2:27 PM on October 2, 2024: member

@vasild That assumes the attacker has sufficient monitoring infrastructure in place to maintain an accurate list of Bitcoin P2P ip:ports. That's obviously not impossible, but it is a significantly larger effort than stateless packet inspection looking for the string "\xf9\xbe\xb4\xd9version\x00\x00\x00\x00\x00".

And yes, very little in BIP324 protects against an attacker deliberately targetting specific individuals - its goal is increasing costs for large-scale monitoring. From that perspective I agree there is a risk for a false sense of security when introducing options like these, but I think it's a stretch to say that that makes it pointless. I can very well imagine this makes it possible to run a node at all for some users.

However, as I pointed out in the linked issue, I am somewhat concerned about a potential future where it becomes harder for other/older software to connect to the network if large swaths move to be v2-only. Because of that, I wonder if it isn't better to make this only apply to outbound connections, and advise people who want more private operation to not listen for inbound connections.

jonatack commented at 2:59 PM on October 2, 2024: member

However, as I pointed out in the linked issue, I am somewhat concerned about a potential future where it becomes harder for other/older software to connect to the network if large swaths move to be v2-only. Because of that, I wonder if it isn't better to make this only apply to outbound connections, and advise people who want more private operation to not listen for inbound connections.

Yes. I may be potentially concept/approach ack here if this proposal adopts the suggestion above / in #29618 (comment) or #29618 (comment). (Along with perhaps additional user documentation for node runners, maybe in the relevant config option helps and/or in /doc.)

1440000bytes commented at 9:15 PM on October 3, 2024: none

I think it's too early to add this option but it will remain unused by most and off by default. I don't see anything wrong with some users testing it.

This doesn't hide the fact that a user is running a bitcoin node (most IPv4 nodes use default port). It just ensures all peers are using v2 for P2P.

DrahtBot added the label Needs rebase on Oct 9, 2024

brunoerg commented at 8:22 PM on October 10, 2024: contributor

A mutation testing report for this PR is available at: https://brunoerg.xyz/mutation-core-front

laanwj commented at 10:15 AM on October 24, 2024: member

Well, to gain the benefits of BIP324. For example if you are concerned about someone inspecting the traffic to your node it really doesn't matter how many BIP324 peers you have if you have just one unencrypted connection.

Right. Would it maybe make sense to have an option to restrict transaction broadcast and relay to v2-only, for IPv4 and IPv6 connections? Instead of not connect at all? Eg consider v1 connections blocks-only (except those over Tor/I2P). This alleviates the risk of network partition of consensus. While still providing a bit of added privacy for where it matters.

stratospher force-pushed on Oct 28, 2024

stratospher commented at 5:50 AM on October 28, 2024: contributor

I've rebased and changed the approach in the PR to have v2 only outbound connections. So there's null partition risk because of the option now.

Right. Would it maybe make sense to have an option to restrict transaction broadcast and relay to v2-only, for IPv4 and IPv6 connections? Instead of not connect at all? Eg consider v1 connections blocks-only (except those over Tor/I2P). This alleviates the risk of network partition of consensus. While still providing a bit of added privacy for where it matters.

I don't think just sending transactions over encrypted connections gives that much extra privacy.

Passive attackers can still:

cheaply tell you're running a bitcoin node looking at the network magic bytes.
there's transaction lengths which can be used to distinguish 1 transaction from another.

Having all network traffic as encrypted would give better privacy when dealing with 1.

DrahtBot removed the label Needs rebase on Oct 28, 2024

laanwj commented at 11:26 AM on October 30, 2024: member

I don't think just sending transactions over encrypted connections gives that much extra privacy.

i'm not advicating to send just transactions, v2 connections would have blocks+transactions, all of it. Not sending transactions over v1 makes sure that transactions aren't sent over the network in plaintext.

In the long term, if the idea is to phase out P2P v1, i think demotiing it to a blocksonly-protocol makes sense. It holds the network together against eclipse attacks and accidental partitioning, but doesn't reveal anything privacy sensitive.

Sure, passive attackers can still see packet sizes in the v2 connections, but that doesn't actually change if you refuse to accept and/or make v1 connections at all?

cheaply tell you're running a bitcoin node looking at the network magic bytes.

i still don't believe there is any hiding like that. There's so many tells for passive attackers: using the DNS seeds, connecting to certain nodes, using port 8333 (in and/or out), using P2P address gossip. Sure, if you manage to avoid all of those, it's less apparent, but that's so much work and easy to screw up with a small mistake.

vasild commented at 2:30 PM on November 6, 2024: contributor

Before I could see the purpose of the full v2only option: 1. to hide the fact that a bitcoin node is running and 2. hide its own transactions. However I think it would achieve neither of those, but I could see how it looked like it would. Now it is changed:

I've rebased and changed the approach in the PR to have v2 only outbound connections

Does it still have the same motivation: 1. and 2.? I think the idea in #29618 is that v1 connections are somehow harmful and we must not have any of them. Now with this PR we would allow v1 inbound connections? @iotamega, do you think this would resolve #29618? Once the node has e.g. 30 connections and some of them are v1 and some v2, I think it is irrelevant which are inbound and which are outbound.

Consider outbound v1 connections to clearnet but via the Tor proxy (via the Tor network and Tor exit nodes), if -proxy= is given. Assuming there is some reason to avoid v1 outbound (which I don't see), should those be avoided as well?

1440000bytes changes_requested

1440000bytes commented at 6:02 PM on November 6, 2024: none

NACK

This pull request and related efforts are bad for bitcoin in lot of ways not just partition risk.

We need to fix other things before trying to achieve this. Disappointed that some devs keep repeating it will hide that you are running a node.

in src/init.cpp:935 in b434583fbb outdated

 931 | @@ -930,6 +932,11 @@ bool AppInitParameterInteraction(const ArgsManager& args)
 932 |      // Signal NODE_P2P_V2 if BIP324 v2 transport is enabled.
 933 |      if (args.GetBoolArg("-v2transport", DEFAULT_V2_TRANSPORT)) {
 934 |          g_local_services = ServiceFlags(g_local_services | NODE_P2P_V2);
 935 | +        if (args.GetBoolArg("-v2onlyclearnet", false)) {

luke-jr commented at 9:23 PM on January 16, 2025:

Rather avoid the temporary global and just check this when setting connOptions

stratospher commented at 5:33 AM on January 24, 2025:

good point! done.

in src/init.cpp:939 in b434583fbb outdated

 931 | @@ -930,6 +932,11 @@ bool AppInitParameterInteraction(const ArgsManager& args)
 932 |      // Signal NODE_P2P_V2 if BIP324 v2 transport is enabled.
 933 |      if (args.GetBoolArg("-v2transport", DEFAULT_V2_TRANSPORT)) {
 934 |          g_local_services = ServiceFlags(g_local_services | NODE_P2P_V2);
 935 | +        if (args.GetBoolArg("-v2onlyclearnet", false)) {
 936 | +            disable_v1conn_clearnet = true;
 937 | +        }
 938 | +    } else if (args.GetBoolArg("-v2onlyclearnet", false)) {
 939 | +            return InitError(_("Cannot set -v2onlyclearnet to true when v2transport is disabled."));

luke-jr commented at 9:23 PM on January 16, 2025:

nit: indentation

in src/net.h:1258 in b434583fbb outdated

1254 | @@ -1253,6 +1255,9 @@ class CConnman
1255 |  
1256 |      bool MultipleManualOrFullOutboundConns(Network net) const EXCLUSIVE_LOCKS_REQUIRED(m_nodes_mutex);
1257 |  
1258 | +    /* Disables outbound v1 connections on IPV4/IPV6 network. */

luke-jr commented at 9:41 PM on January 16, 2025:

The method doesn't change anything, it just returns a value...

stratospher commented at 5:34 AM on January 24, 2025:

makes sense. changed the comment to "Returns true if outbound v1 connections need to be disabled on IPV4/IPV6 network."

luke-jr changes_requested

luke-jr commented at 10:22 PM on January 16, 2025: member

No opinion on concept. Just code review.

stratospher force-pushed on Jan 24, 2025

in src/init.cpp:1849 in 4d4f80940c outdated

1845 | @@ -1843,6 +1846,7 @@ bool AppInitMain(NodeContext& node, interfaces::BlockAndHeaderTipInfo* tip_info)
1846 |      connOptions.m_peer_connect_timeout = peer_connect_timeout;
1847 |      connOptions.whitelist_forcerelay = args.GetBoolArg("-whitelistforcerelay", DEFAULT_WHITELISTFORCERELAY);
1848 |      connOptions.whitelist_relay = args.GetBoolArg("-whitelistrelay", DEFAULT_WHITELISTRELAY);
1849 | +    connOptions.disable_v1conn_clearnet = args.GetBoolArg("-v2transport", DEFAULT_V2_TRANSPORT) && args.GetBoolArg("-v2onlyclearnet", false);

luke-jr commented at 9:03 PM on January 25, 2025:

    connOptions.disable_v1conn_clearnet = args.GetBoolArg("-v2onlyclearnet", false);

The InitError above means this should be safe

luke-jr changes_requested

stratospher force-pushed on Jan 27, 2025

luke-jr referenced this in commit be4cd7551d on Feb 22, 2025

luke-jr referenced this in commit f69ca7fd32 on Feb 22, 2025

luke-jr referenced this in commit 6492aed3fb on Feb 22, 2025

luke-jr referenced this in commit dcb5daf5cf on Feb 22, 2025

DrahtBot added the label Needs rebase on Mar 24, 2025

stratospher force-pushed on Mar 28, 2025

DrahtBot removed the label Needs rebase on Mar 28, 2025

luke-jr referenced this in commit cbfbefd8f3 on Jun 6, 2025

luke-jr referenced this in commit 7c06acab77 on Jun 6, 2025

luke-jr referenced this in commit f4fc3f03f4 on Jun 6, 2025

luke-jr referenced this in commit 5891703ba0 on Jun 6, 2025

DrahtBot added the label CI failed on Jul 3, 2025

DrahtBot removed the label CI failed on Jul 3, 2025

achow101 requested review from sipa on Oct 22, 2025

achow101 requested review from fjahr on Oct 22, 2025

achow101 requested review from danielabrozzoni on Oct 22, 2025

in src/net.cpp:1941 in 27e9000883

1937 | @@ -1935,7 +1938,7 @@ void CConnman::DisconnectNodes()
1938 |                  // Add to reconnection list if appropriate. We don't reconnect right here, because
1939 |                  // the creation of a connection is a blocking operation (up to several seconds),
1940 |                  // and we don't want to hold up the socket handler thread for that long.
1941 | -                if (network_active && pnode->m_transport->ShouldReconnectV1()) {
1942 | +                if (network_active && pnode->m_transport->ShouldReconnectV1() && !DisableV1OnClearnet(pnode->addr.GetNetClass())) {

ajtowns commented at 10:22 AM on October 23, 2025:

nit: Should check DisableV10nClearnet() first -- ShouldReconnectV1 takes locks in order to return true.

stratospher commented at 3:36 PM on November 19, 2025:

oh good point. done.

in src/init.cpp:551 in 27e9000883

 547 | @@ -548,6 +548,7 @@ void SetupServerArgs(ArgsManager& argsman, bool can_listen_ipc)
 548 |      argsman.AddArg("-i2pacceptincoming", strprintf("Whether to accept inbound I2P connections (default: %i). Ignored if -i2psam is not set. Listening for inbound I2P connections is done through the SAM proxy, not by binding to a local address and port.", DEFAULT_I2P_ACCEPT_INCOMING), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
 549 |      argsman.AddArg("-onlynet=<net>", "Make automatic outbound connections only to network <net> (" + Join(GetNetworkNames(), ", ") + "). Inbound and manual connections are not affected by this option. It can be specified multiple times to allow multiple networks.", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
 550 |      argsman.AddArg("-v2transport", strprintf("Support v2 transport (default: %u)", DEFAULT_V2_TRANSPORT), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
 551 | +    argsman.AddArg("-v2onlyclearnet", strprintf("Disallow outbound v1 connections on IPV4/IPV6 (default: %u). Enable this option only if you really need it. Use -listen=0 to disable inbound connections since they can be unencrypted.", false), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);

ajtowns commented at 10:26 AM on October 23, 2025:

Shouldn't there be a constant with the default setting?

When do you "really need" this option? Might be better to give a more specific recommendation here?

If you usually want to set -listen=0 with it, should we add an arg-interaction rather than just help text?

if (args.GetBoolArg("-v2onlyclearnet", false)) {
    if (args.SoftSetBoolArg("-listen", false)) {
        LogInfo("parameter interaction: -v2onlyclearnet set -> setting -listen=0\n");
    }
}

stratospher commented at 3:36 PM on November 19, 2025:

done. I've made it an error instead so that the user doesn't accidentally switch off listening mode.

in src/net.cpp:466 in 27e9000883

 462 | @@ -463,6 +463,9 @@ CNode* CConnman::ConnectNode(CAddress addrConnect, const char *pszDest, bool fCo
 463 |      std::unique_ptr<i2p::sam::Session> i2p_transient_session;
 464 |  
 465 |      for (auto& target_addr: connect_to) {
 466 | +        if (DisableV1OnClearnet(target_addr.GetNetClass()) && !use_v2transport) {

ajtowns commented at 10:27 AM on October 23, 2025:

Is there any reason to not have DisableV10nClearnet do the GetNetClass internally?

fjahr commented at 9:36 PM on October 24, 2025:

Could the naming be kept consistent between the function names and the init arg? One is "disable v1" and the other is "only v2" and I don't see a good reason for that.

stratospher commented at 3:38 PM on November 19, 2025:

Is there any reason to not have DisableV10nClearnet do the GetNetClass internally?

done. the initial version in the PR with both outbound+ inbound v2 only required another function to detect inbound onion and we had to pass network. but we can remove it for outbound v2 only.

in src/net.cpp:2506 in 27e9000883

2500 | @@ -2498,6 +2501,11 @@ bool CConnman::MultipleManualOrFullOutboundConns(Network net) const
2501 |      return m_network_conn_counts[net] > 1;
2502 |  }
2503 |  
2504 | +bool CConnman::DisableV1OnClearnet(Network net) const
2505 | +{
2506 | +    return disable_v1conn_clearnet && (net == NET_IPV4 || net == NET_IPV6);

ajtowns commented at 2:11 PM on October 23, 2025:

Maybe add an IsClearnet(Network net) { return net == NET_IPV4 || net == IPV6; } helper? There's a few other only-clearnet conditions in the code.

ajtowns commented at 2:28 PM on October 23, 2025: contributor

Concept review:

I think this has two potential benefits:

avoids cleartext relay of transactions, particularly your own. #29415 is better at solving that problem, but a small step is also a good thing. this is only useful if you also disable inboud clearnet connections however.
avoids easy detection that you're running a bitcoin node by stateless packet connection. if you're a listening node, then you still advertise your ip over the bitcoin network, so it's not hard to find you, in that case. traffic analysis or similar also likely gives this away, but that is significantly more work.

Both these suggest to me that this option is only really meaningful for non-listening nodes. Perhaps either automatically setting nolisten, or adding a "only listen on non-clearnet networks" option and automatically setting that would be good.

Only allowing v2 clearnet inbounds might make sense, but it seems concerning for eclipsing old nodes that don't support v2. Downgrading clearnet v1 inbounds to blocksonly mode might be an acceptable compromise there. Probably old nodes would still want some way to broadcast their transactions to the network, however, which might be hard to support in that model.

Particularly if this option is only used by nodes that aren't listening on clearnet anyway, I think this is a reasonable option to have.

Approach ACK 45bd8914658a675d00aa9c83373d6903a8a9ece8

in src/net.h:1604 in 27e9000883

1595 | @@ -1591,6 +1596,13 @@ class CConnman
1596 |       */
1597 |      bool whitelist_relay;
1598 |  
1599 | +    /**
1600 | +     * option for disabling outbound v1 connections on IPV4 and IPV6.
1601 | +     * outbound connections on IPV4/IPV6 need to be v2 connections.
1602 | +     * outbound connections on Tor/I2P/CJDNS can be v1 or v2 connections.
1603 | +     */
1604 | +    bool disable_v1conn_clearnet;

fjahr commented at 9:37 PM on October 24, 2025:

nit: m_ prefix?

mzumsande commented at 3:09 PM on October 27, 2025: contributor

A year later, adoption is now almost at ~70% according to https://21.ninja/reachable-nodes/node-service-share/ - could update the OP with that info.

fjahr commented at 9:37 PM on October 29, 2025: contributor

Concept ACK

I agree with @ajtowns that coupling this with nolisten makes sense and also means that this should not be too dangerous. Rather than turning that on by default and potentially risking the user don't fully understand the implications of this, the option could also error if nolisten isn't set.

sipa commented at 8:10 PM on November 3, 2025: member

Concept ACK. I think deployment of v2-capable nodes is sufficient that it's reasonable to offer an outbound-v2-only option.

kristapsk commented at 11:53 AM on November 4, 2025: contributor

Concept ACK

laanwj commented at 2:13 PM on November 4, 2025: member

A year later, adoption is now almost at ~70% according to https://21.ninja/reachable-nodes/node-service-share/ - could update the OP with that info.

Concept ACK. i was critical of this in the past, but i'm more convinced that it makes some sense now, and believe it outweighs the implementation/maintenance cost of such a feature.

in src/net.h:1081 in 1d445c9249 outdated

1077 | @@ -1078,6 +1078,7 @@ class CConnman
1078 |          bool m_i2p_accept_incoming;
1079 |          bool whitelist_forcerelay = DEFAULT_WHITELISTFORCERELAY;
1080 |          bool whitelist_relay = DEFAULT_WHITELISTRELAY;
1081 | +        bool disable_v1conn_clearnet = false;

laanwj commented at 2:54 PM on November 4, 2025:

do we want a DEFAULT_DISABLE_V1CONN_CLEARNET? (would be symmetric to the other options)

in src/net.cpp:2501 in 1d445c9249 outdated

2497 | @@ -2498,6 +2498,11 @@ bool CConnman::MultipleManualOrFullOutboundConns(Network net) const
2498 |      return m_network_conn_counts[net] > 1;
2499 |  }
2500 |  
2501 | +bool CConnman::DisableV1OnClearnet(Network net) const

laanwj commented at 3:02 PM on November 4, 2025:

Would prefer to generalize this function name to DisableV1OnNetwork. That it happens to be about clearnet is an implementation, not an interface detail (as the network is passed in).

Edit: could add Outbound, though. This is not obvious.

stratospher commented at 3:39 PM on November 19, 2025:

makes sense. changed it to RequiresV2ForOutbound. hopefully it's better.

vasild commented at 3:07 PM on November 6, 2025: contributor

I re-assessed this carefully.

It seems ok to me to have v2only with the following properties:

Can only be enabled if not listening, like suggested above. Otherwise we have to either:
- accept v1 incoming which defeats the purpose of this because then we will have cleartext connections or
- deny v1 incoming (only allow v2 incoming) which is a problem if this is widely adopted because then old nodes that do not support v2 will have a hard time finding peers to connect to and will be subject to eclipse from an attacker who runs many v1-accepting nodes.

avoids easy detection that you're running a bitcoin node by stateless packet connection.

The node is still making outbound connections to addresses on the internet to port 8333!

So it would be good to make it very obvious to the user that this option will not hide the fact that they are running a Bitcoin node.
Also, it would be good to make it very obvious that this option only marginally if at all improves own transactions' privacy. Why? It improves it in the following case: if a node has only cleartext v1 connections, then their ISP can monitor all traffic that goes in and out of the node. So the ISP can know when the node sends their own transactions because it never received those transactions from others before sending them. Thus the node must be the originator. However, if there is at least one encrypted connection, then the ISP cannot know whether the transaction originated from the node or whether the node is just relaying a transaction it received over the encrypted connection. So this option helps to avoid the case of having only cleartext v1 connections with a passive spy that is only inspecting traffic. Then the option might be -avoid-having-all-connections-as-v1 If the spy ISP is willing to redirect outgoing connections to their spyish nodes, then v2only does not help.

mzumsande commented at 6:51 PM on November 6, 2025: contributor

deny v1 incoming (only allow v2 incoming) which is a problem if this is widely adopted because then old nodes that do not support v2 will have a hard time finding peers to connect to and will be subject to eclipse from an attacker who runs many v1-accepting nodes.

I still don't find the reason for tying it to -listen=0 instead of also disallowing v1 inbounds compelling. Yes, if everyone disabled v1 incoming peers that could lead to v1 nodes being eclipsed. But with the suggested approach, if too many nodes just disabled incoming connections entirely to be able to use the option, that wouldn't be any better, because now every node would have trouble finding peers / risk being eclipsed.

If the downsides are documented well in the helptext, I don't see a difference to many other existing optional settings that would be bad if everyone used them. (-listen, -blocksonly, -onlynet etc.). But just comparing the two options in a vacuum, allowing only v2 inbounds seems better than allowing no inbounds at all.

vasild commented at 5:27 PM on November 11, 2025: contributor

From the issue that prompted this:

I asked for this because of a friend in a country where they are having issues, very real issues and they did not want to doxx themselves

I still think that this is misguided and can get people into "very real issues" if such an option gives the impression that it:

Hides the fact that you run a bitcoin node. It does not at all because you will still connect to others at port 8333, and that is the easiest way to detect bitcoin traffic, no need for spy nodes or inspecting the traffic contents.
Hides you as originator of your own transactions from your ISP. A little bit it does, but not much as commented in details above. I think that all-v2-connections is the same as at-least-one-v2-connection for concealing the transaction origin.

Anyway, if it is made clear that a v2only option does not achieve 1. or 2., then I guess it is fine. V2 adoption has increased and there are enough knowledgeable people commenting here, so with this post I would like to withdraw my "Concept NACK" and leave it in your capable hands.

Concept 0

stratospher force-pushed on Nov 19, 2025

stratospher commented at 3:27 AM on November 20, 2025: contributor

Thank you all for the very helpful feedback on this! and sorry for getting late with the update.

I've pushed an update addressing all the review comments except @mzumsande's conceptual concern about whether v2onlyclearnet should accept v2 inbounds as well so that the network doesn't face a shortage of listening capacity in the worst case scenario where a huge fraction of network turns it on.

Quick summary of the update:

More description in help text to highlight that -v2onlyclearnet doesn't hide the fact that you're running a bitcoin node. (thanks @vasild!)
-v2onlyclearnet, -listen arg interaction which errors if we use -v2onlyclearnet on a listening node (thanks @ajtowns!)
naming consistency in functions/variables to use "v2 only" language instead of mixing it with potentially confusing "disable v1" language also. Ex: s/DisableV10nClearnet/RequiresV2ForOutbound (thanks @fjahr!)
introduced DEFAULT_DISABLE_V1CONN_CLEARNET=false (thanks @laanwj!)

regarding #30951#pullrequestreview-3429992454:

I still don't find the reason for tying it to -listen=0 instead of also disallowing v1 inbounds compelling. Yes, if everyone disabled v1 incoming peers that could lead to v1 nodes being eclipsed. But with the suggested approach, if too many nodes just disabled incoming connections entirely to be able to use the option, that wouldn't be any better, because now every node would have trouble finding peers / risk being eclipsed.

I assumed people who didn't want network traffic to be spyed on are already people who didn't accept (possibly spy) connections from others (people running private nodes) and didn't think of the impact on the listening slots in the network. This doesn't necessarily need to be the case though. -v2onlyclearnet being used with listen=0 would also need -listenonion=0, so we'd also be turning off tor/i2p inbounds.

However this feels like lots of users setting listen=0 problem, and we're showing someone a reason for setting listen=0 + making that future slightly more probable. Will need to think more about this and curious about other people's thoughts on #30951#pullrequestreview-3429992454 as well.

DrahtBot added the label Needs rebase on Dec 12, 2025

stratospher force-pushed on Dec 12, 2025

DrahtBot removed the label Needs rebase on Dec 12, 2025

sedited commented at 2:48 PM on March 11, 2026: contributor

Concept ACK

Afaict the project has communicated clearly that v2 encryption aims to protect against passive adversaries. It seems desirable to make good on that. Adding this to the 32 milestone.

sedited added this to the milestone 32.0 on Mar 11, 2026

pinigapic-lang commented at 3:54 PM on March 11, 2026: none

Concept ACK

DrahtBot added the label Needs rebase on Mar 26, 2026

stratospher force-pushed on Apr 8, 2026

DrahtBot added the label CI failed on Apr 8, 2026

DrahtBot removed the label Needs rebase on Apr 8, 2026

net: add helper to identify clearnet networks

only-clearnet condition is used in a few other places as well.

d9ca48309e

net: add option in CConman to allow only v2 clearnet connections

a boolean option `m_v2only_clearnet` is introduced in CConman
which will (in a later commit) store if the user wishes to
establish only outbound v2 connections on IPV4 and IPV6 networks
since they are unencrypted.

this option is accessible outside CConman using
`RequiresV2ForOutbound()` function with the IP address we're trying
to connect to passed as an argument.

711bf492d1

init: add -v2onlyclearnet config option

if this option is set by the user, v1 connections on unencrypted
networks like IPV4/IPV6 will be disallowed. Only users with real
need are recommended to turn this on because it could risk network
partitioning in the unlikely scenario that everyone turns it on.

81604eae78

net: disable v1 connections, reconnections on clearnet

if `-v2onlyclearnet` is turned on,
- v1 addresses from addrman aren't selected and manual connections
aren't attempted for outbound connections if it's from IPV4/IPV6
networks.
- v1 downgrade mechainm is not attempted if v2 connection wasn't
successful

8498b7c0e7

test: Check that v1 connections to clearnet peers don't work

when `-v2onlyclearnet` is turned on:
- v1 connections to clearnet peers don't work
- v2 connections to clearnet peers work
- v1 conneections to tor/i2p/cjdns peer works

a proxy is used because otherwise NET_UNROUTABLE is the default
network in the tests.

1e61206583

stratospher force-pushed on Apr 9, 2026

DrahtBot removed the label CI failed on Apr 9, 2026

sedited requested review from fjahr on Apr 19, 2026

in src/netbase.cpp:144 in d9ca48309e outdated

 140 | @@ -141,6 +141,8 @@ std::vector<std::string> GetNetworkNames(bool append_unroutable)
 141 |      return names;
 142 |  }
 143 |  
 144 | +bool isClearnet(const enum Network net) { return net == NET_IPV4 || net == NET_IPV6; }

fjahr commented at 7:21 PM on April 19, 2026:

nit: IsClearnet() is more our usual style.

in src/net.h:1406 in 711bf492d1 outdated

1401 | @@ -1398,6 +1402,9 @@ class CConnman
1402 |  
1403 |      bool MultipleManualOrFullOutboundConns(Network net) const EXCLUSIVE_LOCKS_REQUIRED(m_nodes_mutex);
1404 |  
1405 | +    /** Returns true if outbound IPv4/IPv6 connections must be v2 only. */
1406 | +    bool RequiresV2ForOutbound(const CNetAddr &addr) const;

fjahr commented at 7:23 PM on April 19, 2026:

Seems like this could be private?

in src/init.cpp:1032 in 81604eae78 outdated

1026 | @@ -1024,6 +1027,12 @@ bool AppInitParameterInteraction(const ArgsManager& args)
1027 |          return InitError(Untranslated("Cannot set -listen=0 together with -listenonion=1"));
1028 |      }
1029 |  
1030 | +    if (args.GetBoolArg("-v2onlyclearnet", DEFAULT_V2_ONLY_CLEARNET)) {
1031 | +        if (args.GetBoolArg("-listen", DEFAULT_LISTEN)) {
1032 | +            return InitError(_("Cannot set -v2onlyclearnet=1 with listen=0. Current listen=1 provides valuable network capacity. Use -v2onlyclearnet only if you truly need encrypted-only outbound traffic."));

fjahr commented at 7:38 PM on April 19, 2026:

This error message is a bit confusing, first "Cannot set -v2onlyclearnet=1 with listen=0" seems to be wrong, it should say "listen=1" there (or s/with/without/). And then maybe switch the order of the current second and third sentence, I think that would read a bit better. For my taste the second sentence is a bit much because I don't think it's going to change anyone's mind but I would be fine to keep it. But we could also ask people to read the help text of the option carefully where we are more detailed.

in src/init.cpp:572 in 81604eae78 outdated

 568 | @@ -569,6 +569,7 @@ void SetupServerArgs(ArgsManager& argsman, bool can_listen_ipc)
 569 |      argsman.AddArg("-i2pacceptincoming", strprintf("Whether to accept inbound I2P connections (default: %i). Ignored if -i2psam is not set. Listening for inbound I2P connections is done through the SAM proxy, not by binding to a local address and port.", DEFAULT_I2P_ACCEPT_INCOMING), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
 570 |      argsman.AddArg("-onlynet=<net>", "Make automatic outbound connections only to network <net> (" + Join(GetNetworkNames(), ", ") + "). Inbound and manual connections are not affected by this option. It can be specified multiple times to allow multiple networks.", ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
 571 |      argsman.AddArg("-v2transport", strprintf("Support v2 transport (default: %u)", DEFAULT_V2_TRANSPORT), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
 572 | +    argsman.AddArg("-v2onlyclearnet", strprintf("Ensure all outbound IPv4/IPv6 peers use encrypted network traffic (default: %u). Using this option requires -listen=0 and takes valuable listening capacity away from the network. Enable this option only if passive network observers like ISPs, firewalls, etc. pose a threat and unencrypted network traffic must be avoided. Note: Encryption protects message contents but does not obscure that you are running a Bitcoin node. Peers can still connect to you, observers can identify Bitcoin activity from connection attempts on the default port (8333) or from analysing Bitcoin network traffic patterns.", DEFAULT_V2_ONLY_CLEARNET), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);

fjahr commented at 7:46 PM on April 19, 2026:

Not a strong opinion but as it is worded now, probably everyone who runs a bitcoin node will say, yes, these network observers are a problem for my privacy. It might be better to say something like: "if you are at risk of your traffic getting blocked or service shut down". That would be a bit more strongly steer people away from this if they don't know what they are doing/don't really need it. But it's just an idea, feel free to ignore.

vasild commented at 8:53 AM on April 20, 2026:

It might be better to say something like: "if you are at risk of your traffic getting blocked or service shut down"

If you are at such a risk, then -v2onlyclearnet=1 will not help. Mentioning "passive" is good because -v2onlyclearnet=1 protects only against "passive" observers and not against "active" ones who can MITM themselves and spy on the encrypted traffic. Then the user has no way to ensure that a possible adversary will stay "passive" and will not switch to "active" at any moment.

in src/net.cpp:448 in 8498b7c0e7 outdated

 443 | @@ -444,6 +444,9 @@ CNode* CConnman::ConnectNode(CAddress addrConnect,
 444 |      std::unique_ptr<i2p::sam::Session> i2p_transient_session;
 445 |  
 446 |      for (auto& target_addr : connect_to) {
 447 | +        if (RequiresV2ForOutbound(target_addr) && !use_v2transport) {
 448 | +            continue;

fjahr commented at 7:54 PM on April 19, 2026:

Seems like this filtering could already be done in the resolved loop above so that the addr doesn't even end up here?

fjahr commented at 7:54 PM on April 19, 2026:

nit: In the commit message here: s/mechainm/mechanism/

in test/functional/p2p_v2_encrypted.py:134 in 1e61206583

 130 | @@ -129,6 +131,27 @@ def run_test(self):
 131 |          assert_equal(node0.getpeerinfo()[-1]["transport_protocol_type"], "v1")
 132 |          check_node_connections(node=node0, num_in=1, num_out=0)
 133 |  
 134 | +        conf = Socks5Configuration()

fjahr commented at 8:02 PM on April 19, 2026:

nit: In commit message s/conneections/connections/

fjahr commented at 8:36 PM on April 19, 2026: contributor

However this feels like lots of users setting listen=0 problem, and we're showing someone a reason for setting listen=0 + making that future slightly more probable. Will need to think more about this and curious about other people's thoughts on #30951#pullrequestreview-3429992454 as well.

Re-reading the code and @mzumsande's argument, I think I am now slightly leaning towards not tying it to listen=0 but rather only disallowing v1 connections. But I would still be fine with the current approach as well, especially if we can find a bit better wording.