Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bitcoin only connects to .onion nodes, not regular nodes over tor #79

Open
gStart9 opened this issue Jul 4, 2022 · 6 comments
Open

Comments

@gStart9
Copy link
Member

gStart9 commented Jul 4, 2022

The bitcoind configuration resulting from "Disable clearnet" being off (I believe uninentionally) results in bitcoind only connecting to .onion nodes, whereas it seems the better and preferred behavior should be to connect to .onion nodes as well as regular publicly-reachable nodes via tor.

Current options when "Disable clearnet" is turned off:
-onion=172.18.0.1:9050 , -proxy=172.18.0.1:9050 , and -externalip=onionaddress.onion and in the config, onlynet=onion

onlynet=onion configuration option means in all cases we will only ever connect to .onion nodes when making outgoing connections.
-proxy=172.18.0.1:9050 is there but unused/unusable, making me believe we're actually wanting to connect to regular nodes via tor as well.

The fix is to use the onlynet=ipv4 config option settings and make sure we keep -proxy=172.18.0.1:9050
As long as proxy=172.18.0.1 is present, we will use tor for all outbound connections regardless of whether it's to .onion or a public ipv4 address. -onion=172.18.0.1 specifies a proxy to use only when specifically connecting to .onion addresses (so that you can use 2 different proxies depending on the destination).

Advantages:

Possibly faster speeds - 3 hops through tor + 1 hop to the ip = 4 hops instead of 6 that onlynet=onion brings. Also may bring some speed advantages due to the current attacks on tor hidden services. And the final way it may speed things up is, IF the bitcoin network of .onion addresses is sybil'd to death, you may be only connecting to 1 node even if you make 8 outgoing connections to .onion nodes. This reasoning also leads us to possible advantage number 2:

More "secure" against sybil attacks - It costs nothing to spin up more onion addresses and point them all at the same node, making sybil attacks easier. Bitcoin has some semblance of sybil resistance built into its ip choices, never selecting more than 1 ip per class c (/24 network). At least getting IPv4s in different ranges has real costs, unlike making a million new .onion addresses.

@chrisguida
Copy link
Contributor

Did you confirm that onlynet=ipv4 allows connections to tor nodes in addition to clearnet nodes? That seems counterintuitive...

@gStart9
Copy link
Member Author

gStart9 commented Jul 6, 2022

onlynet=ipv4 when used with proxy=torip:torport will connect to publicly accessible "clearnet" nodes via tor. onlynet restricts the destination network (ipv4, ipv6, onion, i2p, cjdns are the current options), while proxy determines what proxy to use, and onion= optionally determines what proxy to use just for .onion addresses. Tor itself can only connect to ipv4 and .onion addresses, so onlynet=ipv4 + proxy=torip:torport will target the configuration option that the web interface could call something like "Outgoing p2p connections: All via tor", which may be among:
All directly via ipv4 only
All directly via ipv6 only
All directly via ipv4 or ipv6
All via tor [ipv4 or .onion]
All via tor to .onion only
... and if we ever decide to get even more fancy later:
All via cjdns
All via i2p
(IIRC cjdns and i2p have no exit nodes, so nodes must be inside those networks)

@dr-bonez told me (assuming we didn't miscommunicate) that "Disable clearnet" intentionally only connects to .onion nodes, which makes perfect sense to word it that way in the GUI, but I don't think that's an optimal Tor setting for the reasons outlined in the original post of this issue. I think we should at some point offer multiple options for people who want to use the different onlynet and proxy settings, but it will probably be somewhat complicated and confusing no matter what - even if or especially if we take the exact same approach in the GUI that the bitcoind.conf takes.

@chrisguida You mentioned that clearnet via tor doesn't seem very useful but I think it is -- not everyone wants their ISP or the spy nodes on the Bitcoin network to know they're running a Bitcoin node and expose their IP address. Sure, they can run it behind a VPN but that takes special setup that most people are not capable of, especially until we get wireguard on the Embassy, and even then the setup may be prone to leaks if the VPN goes down.

Anyway, lots to think about for the future.

@chrisguida
Copy link
Contributor

Ok, did you test this and verify this behavior? Please confirm.

As long as you've actually tested that this is indeed the behavior of these config options, I'd say I'm fine with either switching the current tor setting to also connect to clearnet nodes via tor, or adding an additional setting that preserves the current tor behavior in one setting and adds clearnet nodes via tor in the new setting. Copy would need to be updated in both cases.

@dr-bonez thoughts?

@dr-bonez
Copy link
Member

we need to be very clear that the alternative option uses exit nodes. since the legal ramifications of running an exit node are not small, it is reasonable to assume that a large portion of exit nodes are compromised. Users who want "Tor Only" are likely not comfortable with this risk, and should not make it unknowingly.

@dr-bonez
Copy link
Member

I'd like to remind that bitcoin p2p traffic is not encrypted. While the exit node may not be able to identify the source IP, it can read all of the p2p messages.

@cryptoquick
Copy link

Could BIP-151 be helpful?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

4 participants