V2 Only Option

[iotamega]

Please describe the feature you'd like to see added.

I'd like to see the ability to specify that only V2 protocol connections are allowed.

Is your feature related to a problem, if so please describe it.

No response

Describe the solution you'd like

Perhaps a setting like listenonly=v2

Describe any alternatives you've considered

No response

Please leave any additional context

This would be extremely helpful for those who depend on V2 for confirming a connection is a "bonafide" node.

[vasild]

To me it seems that this could partition the network. In the addresses database of my node there are 2778 addresses that have advertised v2 out of 72821 total.

This would be extremely helpful for those who depend on V2 for confirming a connection is a "bonafide" node.

Trying to better understand your usecase. Do you want to check a connection to a particular node (e.g. one that you control or "trust")? Note that if that node supports v2, then bitcoind will already connect to it using v2 currently. Note also that even if v2 is used, this alone does not mean that MITM did not happen. You have to manually verify the session ids for that.

For ensuring you really connect to the intended node (avoid MITM) using Tor or I2P may be easier or better alternative. In those networks the address represents the peer's public key and naturally when you establish a connection you know you are talking to the one who possesses the private key which corresponds to the address / public key.

[petertodd]

To me it seems that this could partition the network. In the addresses database of my node there are 2778 addresses that have advertised v2 out of 72821 total.

It would only partition the network if almost all v2 nodes had v2-only enabled. As long as this option defaults to off, I don't see any real risk of that happening.

Note also that even if v2 is used, this alone does not mean that MITM did not happen. You have to manually verify the session ids for that.

The fact that people can check session ids is a reasonable deterrent to MITM attacks, as many attackers would not want their attack to be detected. I think it's fine to have a default-off option to enforce this to get a bit of extra privacy.

[mzumsande]

It would only partition the network if almost all v2 nodes had v2-only enabled. As long as this option defaults to off, I don't see any real risk of that happening.

We have various other options that could partition the network (-onlynet) or have other bad consequences (-nolisten, -blocksonly, -prune) if everyone used them, plus we could add a warning in the doc that only users who actually need it should use it.

Perhaps a setting like listenonly=v2

listen usually refers to inbound connections, this should be an option that applies to both outbound and inbound connections (maybe a third option to -v2transport).

[vasild]

Ok, forget about the partitioning aspect (for now). Seems 3 different things are mixed here:

1. Opening v2-only connection to a particular node (e.g. by addnode RPC). I got the impression that the OP is missing the fact that if this particular node supports v2 then a v2 connection will be opened even now.
2. Opening v2-only connections for all outbound connections to clearnet peers (for Tor, I2P and CJDNS v1 is as fine because they do encryption anyway).
3. Accepting v2-only incoming connections over clearnet.

[mzumsande]

I think that all three types should be affected by a v2-only option for it to be consistent:

• Don't attempt to make v1 outbound connections
• Don't accept v1 inbound connections
• The v1 downgrade mechanism should be disabled for both manual and automatic connections

[sipa]

I think a per-IP v2only option makes more sense at first, e.g. as an argument to addnode/connect/seednode/..., a suffix to the IP address, or perhaps through a whitelisting permission. If you know a particular peer of your supports V2, it makes sense to enforce it.

A blanket v2only for the entire node I think is pretty dangerous right now, not for partition risk, but because it'd be trivial for an attacker to spin up enough v2 nodes right now so that they'd eclipse v2only nodes. I think an option like this only makes sense when v2 nodes are widespread.

[iotamega]

To me it seems that this could partition the network. In the addresses database of my node there are 2778 addresses that have advertised v2 out of 72821 total.

Thank you for taking the time to respond and consider my feature request.

I understand your concern about potential network partitioning, but I believe that similar risks exist with other features in Bitcoin as well. While I acknowledge that relying solely on V2 protocol connections may limit the available nodes, I believe it's crucial for those who rely on V2 for verifying the authenticity of connections.

For ensuring you really connect to the intended node (avoid MITM) using Tor or I2P may be easier or better alternative. In those networks the address represents the peer's public key and naturally when you establish a connection you know you are talking to the one who possesses the private key which corresponds to the address / public key.

Regarding your suggestion about using Tor or I2P connections, I appreciate the alternative, but it's important to note that some corporate networks restrict or outright disallow connections over these networks. Additionally, in certain regions, Tor and I2P connections may be filtered out, making it essential to have the option to connect over regular IPV4 and IPV6. In such cases, being able to identify V2 connections can be instrumental.

Furthermore, while it's true that V2 protocol usage alone does not guarantee protection against MITM attacks, it does provide an additional layer of security, especially for those who require confirmation of a "bonafide" node.

Therefore, I still believe that having the ability to specify V2 protocol connections would be beneficial, particularly in scenarios where other options are restricted or unavailable.

[mzumsande]

A blanket v2only for the entire node I think is pretty dangerous right now, not for partition risk, but because it'd be trivial for an attacker to spin up enough v2 nodes right now so that they'd eclipse v2only nodes. I think an option like this only makes sense when v2 nodes are widespread.

Not sure if that would be a problem. v2 will be enabled by default in Bitcoin Core version v27, the earliest possible release for a v2-only option would be v28 anyway. Unless users change their upgrade behavior drastically, this means that 30-50% of all nodes will support v2 by then (current percentage for v26 is 39.6% according to https://bitnodes.io/nodes/).

[iotamega]

It would only partition the network if almost all v2 nodes had v2-only enabled. As long as this option defaults to off, I don't see any real risk of that happening.

Regarding the risk of network partitioning, I completely agree that it would only become a concern if the V2-only option were enabled by default across a significant portion of V2 nodes. Given the nature of the Bitcoin network and the conservative approach typically taken with introducing new features, I imagine any implementation of this option would default to off, minimizing the risk of network partitioning.

In regions where internet traffic is closely monitored or filtered, having the ability to enforce V2-only connections could indeed mitigate potential issues arising from such restrictions. By providing node operators with additional controls, we empower them to navigate these challenges more effectively.

I believe that while the introduction of a V2-only option should be approached cautiously and with consideration for potential network impacts, it holds significant promise for enhancing privacy and security, particularly in regions where internet freedoms are limited.

[iotamega]

We have various other options that could partition the network (-onlynet) or have other bad consequences (-nolisten, -blocksonly, -prune) if everyone used them, plus we could add a warning in the doc that only users who actually need it should use it.

I like the idea of updating the docs to reflect what it is, the use cases for it, and why you shouldn't just do it without thinking about the overall impact.

listen usually refers to inbound connections, this should be an option that applies to both outbound and inbound connections (maybe a third option to -v2transport).

Great points, I do imagine this applying to inbound and outbound so this makes sense. My bad on giving it a "listen" indication as I just sort of had this idea after reviewing some logs from some less friendly countries and came here and tapped out the feature request without giving it as much thought as I should have.

I'd also say it would be even better if you had granular control if it applied to one or the other but understand the simplicity of just making it apply across the board.

[vasild]

A few things to add and a few questions to understand the aspects this better:

Any v2only option should apply only to IPv4 and IPv6 peers, but not to Tor, I2P, CJDNS because the latter already have (stronger) MITM prevention and encryption.

Per-address v2only option

Surely one would set such an option for an address of a peer already known to support v2. For such a peer, v2 connection would already be established currently. So what is the point of having such an option? To make sure MITM does not interfere with the v2 handshake in order to force v1? In this case, knowing the peer supports v2, is the inability to establish v2 equivalent to having v2 with mismatching session ids, showing that MITM is happening?

Global v2only as described in #29618 (comment)

Considering a scenario where a node has clearnet-v1 and clearnet-v2 connections. Do clearnet-v1 connections hurt in any way? Is their presence harmful so that we would want to remove them with a v2only option, other than taking up slots? When picking up automatic outbound peers, we take care to have at least one peer from each of the reachable networks. Should we then insist on having at least one clearnet-v2 connection? In other words, treat ipv4-v1 and ipv4-v2 as separate networks for the purpose of choosing outbound peers?

[iotamega]

1. Opening v2-only connection to a particular node (e.g. by addnode RPC). I got the impression that the OP is missing the fact that if this particular node supports v2 then a v2 connection will be opened even now.

Yes, I'm aware of this and have started using the appropriate flag for such connections. However, it's worth noting that until I explicitly set the flag, my nodes weren't utilizing V2 connections by default. I understand that this behavior may change to be on by default in version 27 if I am reading everything correctly.

2. Opening v2-only connections for all outbound connections to clearnet peers (for Tor, I2P and CJDNS v1 is as fine because they do encryption anyway).

Additionally, it would be preferable if the connection couldn't be established when using addnode in certain situations. For instance, if you're in an environment where the default fallback could potentially expose you to security risks, having this control would be invaluable. I imagine this setting not using the fallback and simply not connecting to the node if possible.

3. Accepting v2-only incoming connections over clearnet.

A global option for accepting V2-only incoming connections over clearnet would indeed be ideal. This makes sense, especially considering that encryption is already provided in environments like Tor, I2P, and CJDNS. Having this option available would offer greater flexibility and security for node operators.

Thank you for bringing up these points, and I appreciate the opportunity to further discuss and refine these ideas.

[iotamega]

I think that all three types should be affected by a v2-only option for it to be consistent:

• Don't attempt to make v1 outbound connections
• Don't accept v1 inbound connections
• The v1 downgrade mechanism should be disabled for both manual and automatic connections

I think this best sums up the sort of functionality I am imagining.

[vasild]

it's worth noting that until I explicitly set the flag, my nodes weren't utilizing V2 connections by default. I understand that this behavior may change to be on by default in version 27 if I am reading everything correctly.

Yes, that is correct. In 27 the global -v2transport defaults to true and the optional v2 argument to the addnode RPC, if not provided, defaults to -v2transport.

For instance, if you're in an environment where the default fallback could potentially expose you to security risks

Be careful, it is better not to assume that v2 hides the fact that it is bitcoin traffic going through. That is - that "you" are running a bitcoin node. Why is that?

• For automatic outbound connections - your node picks addresses to connect to from a publicly available list of listening bitcoin nodes. So, as soon as your router/ISP/corp/gov/spy sees a TCP connection to an address:port from that list, they know that this is bitcoin traffic, even if they cannot see the traffic itself.
• For manual connections by e.g. addnode RPC to another node that is listening but has not announced their address:port publicly to the bitcoin network. The adversary can see the TCP connection from you to that address:port and can try to connect to address:port themselves and figure out that it is a listening bitcoin node.

Or are you talking about the contents of the traffic itself? There is usually nothing sensitive going through in the p2p traffic. Maybe only if you broadcast your own transactions, is this the "security risks" you mentioned?

[iotamega]

I think a per-IP v2only option makes more sense at first, e.g. as an argument to addnode/connect/seednode/..., a suffix to the IP address, or perhaps through a whitelisting permission. If you know a particular peer of your supports V2, it makes sense to enforce it.

A blanket v2only for the entire node I think is pretty dangerous right now, not for partition risk, but because it'd be trivial for an attacker to spin up enough v2 nodes right now so that they'd eclipse v2only nodes. I think an option like this only makes sense when v2 nodes are widespread.

I believe that as the adoption of V2 nodes increases, the effectiveness of such an attack would diminish over time.

Given the current development process and timeline, it's unlikely that this feature would be included in version 28, and even version 29 might be a stretch. Nevertheless, I'm optimistic that as the ecosystem evolves and matures, the concerns surrounding the potential risks of a blanket V2-only option will be addressed.

I still believe that implementing a V2-only option would be a significant boon for users in less friendly environments where using the V1 protocol could pose serious risks to privacy and security.

[iotamega]

Any v2only option should apply only to IPv4 and IPv6 peers, but not to Tor, I2P, CJDNS because the latter already have (stronger) MITM prevention and encryption.

Agreed on this point regarding Tor, I2P, and CJDNS.

Per-address v2only option

Surely one would set such an option for an address of a peer already known to support v2. For such a peer, v2 connection would already be established currently. So what is the point of having such an option? To make sure MITM does not interfere with the v2 handshake in order to force v1? In this case, knowing the peer supports v2, is the inability to establish v2 equivalent to having v2 with mismatching session ids, showing that MITM is happening?

These type of attacks are most assuredly happening by nation-state actors currently. Having the ability to disable a V1 connection entirely is most assuredly the only way to put a stop to it in some locations.

Considering a scenario where a node has clearnet-v1 and clearnet-v2 connections. Do clearnet-v1 connections hurt in any way? Is their presence harmful so that we would want to remove them with a v2only option, other than taking up slots? When picking up automatic outbound peers, we take care to have at least one peer from each of the reachable networks. Should we then insist on having at least one clearnet-v2 connection? In other words, treat ipv4-v1 and ipv4-v2 as separate networks for the purpose of choosing outbound peers?

Great questions, I know that insisting on the v2 connection against the networks would be a considerable lift development wise, I think that is a great way to go but I think just having the ability to disable V1 connections entirely is a great start at the moment without the additional heavy lift.