I’d like to see the ability to specify that only V2 protocol connections are allowed.
No response
Perhaps a setting like listenonly=v2
No response
This would be extremely helpful for those who depend on V2 for confirming a connection is a “bonafide” node.
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.
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.
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).
Ok, forget about the partitioning aspect (for now). Seems 3 different things are mixed here:
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.
I think that all three types should be affected by a v2-only option for it to be consistent:
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.
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.
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/).
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.
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.
listenusually 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.
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.
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?
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?
- Opening v2-only connection to a particular node (e.g. by
addnodeRPC). 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.
- 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.
- 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.
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.
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?
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?
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.
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.
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.
A somewhat minor nuance, but seems worth mentioning: Unless I’m missing something, Tor entry and exit nodes would see v1 traffic in the clear. If it’s decided to proceed with the option, it should be clear to users that it’s only clearnet, Tor/I2P would still allow v1, and e.g. using Tor isn’t a cure for P2P protection (it really never was, just provides a layer of protection for some attack vectors).
I’m torn on the implementation of this option. On one hand, providing users with the optionality to enforce v2 transport seems reasonable. On the other hand, even with a large portion of the network supporting v2 transport, if this option ever becomes default ON (IMO it shouldn’t) it could effectively force old nodes to upgrade or risk being isolated/partitioned.
Any v2only option should apply only to IPv4 and IPv6 peers, but not to Tor …
Tor entry and exit nodes would see v1 traffic in the clear @tdb3, there are no exit nodes involved when accessing
*.onionpeers. This is what I mean by “Tor peers”, not IPv4 peers accessed via the Tor network, involving exit nodes and part of the route is through clearnet.
The Tor entry node is usually on localhost.
This is what I mean by “Tor peers”, not IPv4 peers accessed via the Tor network, involving exit nodes and part of the route is through clearnet.
Ah, thanks. I overlooked that
The Tor entry node is usually on localhost.
True, and using a non-localhost entry node is something the user would already need to be conscious of.
I’ve commented on this feature request at #30951 (comment).
Given the insistence and somewhat stilted, formal writing style of the issue author, I was curious as to their motivation. It turns out that the primary activity of the https://github.com/iotamega GitHub account is opening this feature request and issue #29916. Per their sites https://x.com/Founders, https://bytesandburgers.com/about/ and https://founders.work/, they (wish to?) appear to be based in the United States.
it holds significant promise for enhancing privacy and security, particularly in regions where internet freedoms are limited.
in certain regions, Tor and I2P connections may be filtered out
Sincere question for my understanding, are there examples of regions where clearnet is unfiltered but tor/i2p/cjdns networks are blocked?
@jonatack I gotta say, looking up the background of the author on a pretty ordinary feature request feels a bit creepy to me.
Anyway, it seems reasonable to have V2-only purely on privacy grounds. Nodes that turn that on voluntarily would, modulo traffic analysis, be “black boxes” to passive surveillance attackers, improving the privacy of BTC for everyone else. Don’t need to make that the default any time soon. But good if a non-trivial number of people can and do turn it on.
Also, V2-over-IP will always be lower latency than tor/i2p/cjdns. We should have an option for passive surveillance resistance that is also low latency.
@jonatack I gotta say, looking up the background of the author on a pretty ordinary feature request feels a bit creepy to me. @petertodd The rationale was mentioned in my comment, but to iterate on it, the proposal came out of left field from an unknown entity who insisted repeatedly in an odd manner on it. Also, the proposal may be potentially dangerous for the network (cf #29618 (comment) and #30951 (review)). I believe it’s our responsibility to have a minimally adversarial mindset in that context on this project.
(Another developer wrote to me that they felt it was too personal, while two other developers shared that they agreed with me. While I’m very imperfect, my guideline is to try to do what’s best for bitcoin.)
Anyway, it seems reasonable to have V2-only purely on privacy grounds. Nodes that turn that on voluntarily would, modulo traffic analysis, be “black boxes” to passive surveillance attackers, improving the privacy of BTC for everyone else.
See #30951 (review).
Don’t need to make that the default any time soon.
IIRC we’ve seen the same argument made to justify adding another config option last year, then a subsequent push to make it the default. Slippery slope.
Also, V2-over-IP will always be lower latency than tor/i2p/cjdns. We should have an option for passive surveillance resistance that is also low latency.
CJDNS is a low-latency IPv6 overlay.
I see both points of view here, and I have a hard time weighing them:
The second concern here would be far less relevant if the option only affected outbound connections. That would imply an additional advice for people who prefer more private P2P communication to not accept inbound connections (or only accepting ones over Tor/…). But perhaps that is good advice regardless?
@jonatack While we should always be vigilant about the possibility of contributors with bad intentions, I think it is more productive to do so by judging contributions by their merit than by trying to infer people’s intent.
A good question to ask here is if Bitcoin had shipped from day zero with V2-style encryption, would we ever “upgrade” the P2P protocol to turn it off? I believe the answer is clearly no: there’s no downside to encrypting the P2P layer. So with regard to long-term upgrade plans, it’s fine if in the long run everything eventually moves to V2, in the same way that we’ve done other backwards incompatible P2P upgrades in the past. This of course is just an obscure option, so there’s no rush to contemplate that future. But we should encourage all software to upgrade to V2 connections. @sipa I don’t think a “false sense of security” is a good argument not to have this feature. If anything, I would argue that the promises of Tor and I2P also have an approximately equally or perhaps even greater “false sense of security” due to sybil attacks; IP networking at least has IP address prefix scarcity in its favor. @sipa I don’t think you quite understood my argument either. This isn’t just about users’ own transactions: v2-only nodes deny information to passive surveillance adversaries, creating dark spots in their understanding of tx and block propagation. In that case it doesn’t matter that the adversary knows you’re running a Bitcoin node. @jonatack Re: comparing this to full-rbf, that’s an odd comparison to make as, among other things, full-rbf prevents really nasty MEV issues with asset auction protocols; miners enabled it en-mass precisely because it was the easiest way to mitigate the MEV by letting others do the MEV and collecting the rewards of it via fees. Though maybe v2-only will have a similar situation crop up, eg a Snowden 2.0 leak about widespread passive survaillance. But like full-rbf, if that happens we’ll be glad we can easily turn it on.
CJDNS is a low-latency IPv6 overlay.
CJDNS is still a routed overlay network, where packets do not always go the shortest (internet) route to the destination. That is a latency hit vs native IP.
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
Even with V2-only your friend will still doxx themselves, see #30951 (comment). Running a node thinking they are hidden whereas they are not is dangerous.
To summarize - connecting to publicly known bitcoin nodes is already revealing the fact that one runs a bitcoin node, regardless of encryption. V2-only is not the solution they are looking for, a false sense of security could get them into deeper trouble. Tor/I2P/VPN is much better.
CJDNS is still a routed ove rlay network, where packets do not always go the shortest (internet) route to the destination. That is a latency hit vs native IP.
There are some edge cases where super low latency matters, such as mining (or spy nodes :sweat_smile: ), but in general, propagation of anything over the P2P network can be slow and that’s fine. There’s no tight UI loop. It’s not worth to compromise privacy over latency-like it might the case of web browsing, or even the lightning network.
If anything, an overlay network that has higher latency than Tor but gives more privacy against timing correlations (mixnet kind of construction) would be suitable for bitcoin.
To summarize - connecting to publicly known bitcoin nodes is already revealing the fact that one runs a bitcoin node, regardless of encryption. V2-only is not the solution they are looking for,
:+1: Even with Tor, the shape and timing patterns of the traffic can reveal something about the nature of the underlying traffic. But its a lot better at hiding what’s inside than a low-latency protocol that directly connects to known bitcoin peers.
On Thu, Oct 24, 2024 at 02:52:55AM -0700, laanwj wrote:
CJDNS is still a routed ove rlay network, where packets do not always go the shortest (internet) route to the destination. That is a latency hit vs native IP.
There are some edge cases where super low latency matters, such as mining (or spy nodes :sweat_smile: ), but in general, propagation of anything over the P2P network can be slow and that’s fine. There’s no tight UI loop. It’s not worth to compromise privacy over latency-like it might the case of web browsing, or even the lightning network.
FWIW I’ve discussed transaction latency with mining pools, and they’ve told me that low-latency propagation actually increases profits enough that they make an effort to optimize for it. That’s actually a complaint they have about Stratum V2 and similar systems: pushing block template creation to hashing locations (eg behind a slow internet connection) will noticably decrease profits as the templates add transactions later.
It’s nice that things like Tor exist to decouple the “entrance” of a brand new tx into the P2P network. But once it’s there, miners would much rather it get to all low-latency P2P nodes, including those run by miners, as fast as possible.