Add an option for evenly connecting to nodes on different types of networks

msxmine commented at 6:57 pm on October 20, 2017: none

FEATURE REQUEST

Currently, when a bitcoin node is set up with a connection to both TOR and normal IPv4/6 internet, the 8 outbound-only connection slots, almost always get filled with nodes connecting over IP. Adding a config option, which would try to ballance these connections based on what kind of network they go through, would be benefficial in many ways:

It would add edges between bitcoin network on TOR and normal internet, reducing delays, and the risks associated with an attacker isolating a part of TOR-bitcoin-network from the rest of the world (Or an ISP/government man-in-the-middling all the normal IP connections)
It would help hide/annonymise normal user’s transactions from his/her ISP, by mixing them with TOR-outbound ones
It would reduce the stress on normal general purpose TOR exit nodes, as users would more likely/reliably connect to TOR-IPv4/6 bitcoin nodes instead of exiting into normal internet first, and then connecting to default IPv4/6-only bitcoin nodes

I understand it is possible to create such bridges already, by forcing connections to TOR-only nodes, or by just running a node with lots of inbound slots, but I think the proposed option, would greatly increase the number of such relays, and remove the need for user to maintain a TOR-node whitelist, by handing this work off to normal bitcoind connection finding algorithm.

This could be implemented as a minimum number of connections for each network, or just a simple evening boolean switch. (Which could be enabled by default for bitcoind installs with TOR connectivity)

In the future, if bitcoin was to support a new network type (for example cjdns/I2P/GNUnet), this option would help establish a presence on the new network faster

bitcoind: 0.15

fanquake added the label P2P on Oct 22, 2017

unsystemizer commented at 8:20 pm on November 4, 2017: contributor

the 8 outbound-only connection slots, almost always get filled with nodes connecting over IP.

I know this doesn’t address the request, but if you “addnode” a Tor node does that help secure at least 1 outbound connection and make at least one Tor connection recover after restart?

TheBlueMatt commented at 10:30 pm on November 4, 2017: member

Dont think this should be an option, we should just do this (eg 2 from each type of net, one from each protected from rotation) without any options.

msxmine commented at 12:19 pm on November 15, 2017: none

Yes, addnode is an option, however as I mentioned earlier , it requires the user to effectively maintain a whitelist of trusted, running TOR-facing nodes. I think having a minimum for each network as the default is a good idea. Right now, besides using addnode, the only method for reliably connecting over TOR is the onlynet=onion option, however this removes most of benefits I mentioned in the first comment, as our node no longer is a bridge - it uses only TOR connections, and that is a completely different use-case. Besides, there are comparatively few people running nodes, they want accessible over both IP and TOR, so the default behaviour, not using them to their full potential - as bridges between networks, is I think a waste. The people running these nodes, may not even know, that they are not connecting to TOR at all, because by chance, they got to only the IP part of bitcoin network. I wanted to set up such node, and just looked at getnetworkinfo, only later I realised that I had no TOR connections, when i ran getpeerinfo. (Obviously, this is not as big of an issue for listening nodes with 100s of connections)

laanwj closed this on Mar 30, 2021

jonatack commented at 4:36 pm on June 23, 2021: member

PRs that addressed this network diversity issue with respect to inbound peer eviction protection: #19670, #20197, #21261, #22284.

DrahtBot locked this on Aug 18, 2022

Add an option for evenly connecting to nodes on different types of networks #11537

FEATURE REQUEST