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

stratospher · 2024-09-23T12:23:48Z

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 35 - 39% of reachable nodes in network supporting v2 (according to https://21.ninja/reachable-nodes/node-service-share/ and https://bitnodes.io/nodes). Also found 41-45 % 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 · 2024-09-23T12:23:51Z

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	vasild, 1440000bytes
Concept ACK	mzumsande, dergoegge

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#32065 (i2p: make a time gap between creating transient sessions and using them by vasild)

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.

vasild · 2024-09-26T16:40:02Z

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 · 2024-09-27T15:54:16Z

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 · 2024-09-27T21:35:08Z

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 · 2024-09-28T04:28:46Z

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?

jonatack · 2024-09-28T13:21:39Z

src/init.cpp

@@ -550,6 +550,7 @@ void SetupServerArgs(ArgsManager& argsman, bool can_listen_ipc)
    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);
    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);
    argsman.AddArg("-v2transport", strprintf("Support v2 transport (default: %u)", DEFAULT_V2_TRANSPORT), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);
+    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);


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.

src/net.h

mzumsande · 2024-09-28T19:54:09Z

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.

vasild · 2024-09-29T16:51:55Z

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 · 2024-09-29T18:20:22Z

@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 · 2024-10-02T11:53:28Z

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 · 2024-10-02T12:45:17Z

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 · 2024-10-02T14:19:22Z

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 · 2024-10-02T14:27:42Z

@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 · 2024-10-02T14:59:19Z

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.)

brunoerg · 2024-10-10T20:22:13Z

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

laanwj · 2024-10-30T11:26:01Z

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 · 2024-11-06T14:30:24Z

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

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.

luke-jr

No opinion on concept. Just code review.

src/init.cpp

src/net.h

src/init.cpp

a boolean option `disable_v1conn_clearnet` is introduced in CConman which will (in a later commit) store if the user wishes to disable outbound v1 connections on IPV4 and IPV6 networks since they are unencrypted. this option is accessible outside CConman using `DisableV1OnClearnet()` function with the network we're trying to connect to passed as an argument. Github-Pull: bitcoin#30951 Rebased-From: 88ca9ac

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. Github-Pull: bitcoin#30951 Rebased-From: 9d23891

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 Github-Pull: bitcoin#30951 Rebased-From: 25eb4d0

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. Github-Pull: bitcoin#30951 Rebased-From: 5e3fa67

a boolean option `disable_v1conn_clearnet` is introduced in CConman which will (in a later commit) store if the user wishes to disable outbound v1 connections on IPV4 and IPV6 networks since they are unencrypted. this option is accessible outside CConman using `DisableV1OnClearnet()` function with the network we're trying to connect to passed as an argument.

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.

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

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.

a boolean option `disable_v1conn_clearnet` is introduced in CConman which will (in a later commit) store if the user wishes to disable outbound v1 connections on IPV4 and IPV6 networks since they are unencrypted. this option is accessible outside CConman using `DisableV1OnClearnet()` function with the network we're trying to connect to passed as an argument. Github-Pull: bitcoin#30951 Rebased-From: 1d445c9

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. Github-Pull: bitcoin#30951 Rebased-From: d166ed7

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 Github-Pull: bitcoin#30951 Rebased-From: 19d1bc2

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. Github-Pull: bitcoin#30951 Rebased-From: 27e9000

DrahtBot added the P2P label Sep 23, 2024

stratospher mentioned this pull request Sep 23, 2024

V2 Only Option #29618

Open

DrahtBot added the CI failed label Sep 23, 2024

DrahtBot mentioned this pull request Sep 24, 2024

scripted-diff: Modernize nLocalServices naming #30885

Merged

stratospher force-pushed the v2-only-option branch from cd4f811 to 0cfc9fc Compare September 24, 2024 07:10

DrahtBot removed the CI failed label Sep 24, 2024

stratospher force-pushed the v2-only-option branch 2 times, most recently from 7c9e5a1 to ab5f875 Compare September 25, 2024 08:00

DrahtBot mentioned this pull request Sep 27, 2024

Split CConnman #30988

Draft

jonatack reviewed Sep 28, 2024

View reviewed changes

src/net.h Outdated Show resolved Hide resolved

DrahtBot added CI failed and removed CI failed labels Sep 29, 2024

DrahtBot mentioned this pull request Oct 1, 2024

rpc: provide per message stats for global traffic via new RPC 'getnetmsgstats' #29418

Open

This comment was marked as abuse.

Sign in to view

DrahtBot added the Needs rebase label Oct 9, 2024

DrahtBot removed the Needs rebase label Oct 28, 2024

1440000bytes suggested changes Nov 6, 2024

View reviewed changes

DrahtBot mentioned this pull request Nov 13, 2024

scripted-diff: Type-safe settings retrieval #31260

Open

luke-jr suggested changes Jan 16, 2025

View reviewed changes

src/init.cpp Outdated Show resolved Hide resolved

src/init.cpp Outdated Show resolved Hide resolved

src/net.h Outdated Show resolved Hide resolved

stratospher force-pushed the v2-only-option branch from b434583 to 4d4f809 Compare January 24, 2025 05:32

luke-jr suggested changes Jan 25, 2025

View reviewed changes

src/init.cpp Outdated Show resolved Hide resolved

stratospher force-pushed the v2-only-option branch from 4d4f809 to 5e3fa67 Compare January 27, 2025 04:59

This was referenced Mar 7, 2025

net: replace manual reference counting of CNode with shared_ptr #32015

Open

Replace libevent with our own HTTP and socket-handling implementation #32061

Open

This was referenced Mar 15, 2025

net: Block v2->v1 transport downgrade if !fNetworkActive #32073

Merged

i2p: make a time gap between creating transient sessions and using them #32065

Open

DrahtBot added the Needs rebase label Mar 24, 2025

stratospher added 4 commits March 28, 2025 10:51

stratospher force-pushed the v2-only-option branch from 5e3fa67 to 27e9000 Compare March 28, 2025 05:40

DrahtBot removed the Needs rebase label Mar 28, 2025

DrahtBot added CI failed and removed CI failed labels Jul 3, 2025

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

Are you sure you want to change the base?

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

Uh oh!

Conversation

stratospher commented Sep 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DrahtBot commented Sep 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage & Benchmarks

Reviews

Conflicts

Uh oh!

vasild commented Sep 26, 2024

Uh oh!

mzumsande commented Sep 27, 2024

Uh oh!

jonatack commented Sep 27, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vasild commented Sep 28, 2024

Uh oh!

jonatack Sep 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mzumsande commented Sep 28, 2024

Uh oh!

vasild commented Sep 29, 2024

Uh oh!

stratospher commented Sep 29, 2024

Uh oh!

vasild commented Oct 2, 2024

Uh oh!

dergoegge commented Oct 2, 2024

Uh oh!

vasild commented Oct 2, 2024

Uh oh!

sipa commented Oct 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jonatack commented Oct 2, 2024

Uh oh!

This comment was marked as abuse.

brunoerg commented Oct 10, 2024

Uh oh!

laanwj commented Oct 30, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vasild commented Nov 6, 2024

Uh oh!

1440000bytes left a comment

Choose a reason for hiding this comment

Uh oh!

luke-jr left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stratospher commented Sep 23, 2024 •

edited

Loading

DrahtBot commented Sep 23, 2024 •

edited

Loading

jonatack commented Sep 27, 2024 •

edited

Loading

jonatack Sep 28, 2024 •

edited

Loading

sipa commented Oct 2, 2024 •

edited

Loading

laanwj commented Oct 30, 2024 •

edited

Loading