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

Proposal: option to auto-select only from Tor nodes #2160

Closed
leafcutterant opened this issue Feb 10, 2017 · 5 comments
Closed

Proposal: option to auto-select only from Tor nodes #2160

leafcutterant opened this issue Feb 10, 2017 · 5 comments

Comments

@leafcutterant
Copy link

I'd like to propose a setting through which the auto-selection nodes would be limited to those on the Tor network (.onion nodes). It would help users who use Electrum through Tor and want to utilize the full anonymity potential (hopping through 6 Tor nodes instead of just 3), but don't want to be bothered by .onion nodes that are down, or want higher anonymity via auto-selection from .onion nodes every time the wallet starts (because if one server is chosen manually, it will always try to connect to that.)

What do you think?

@bauerj
Copy link
Collaborator

bauerj commented Feb 10, 2017

Sounds like a good idea.

But what should happen if there were only e.g. 7 .onion-nodes? Electrum connects to 8 servers by default to get block headers. Should this be a "prefer .onion-nodes" option?

@leafcutterant
Copy link
Author

In my opinion, Electrum should go on with fewer nodes in that case. I think those who value anonymity so much that they want to use only .onion nodes would be willing to cope with network lag.

On the the other hand, connecting to very few nodes makes it easier to serve fake data to the client. Next to the setting, there could be a fall-back setting, e.g. "Include at most ▯ non-Tor nodes", where ▯ could be changed

  • from 0 (don't connect to any nodes if no .onion nodes are available, and go on with .onion nodes even if fewer than 8 are reachable)
  • to 8 (this would be the "prefer .onion-nodes" equivalent, where it would connect only to clearnet nodes if no .onion-nodes are reachable).

@ahmarlen
Copy link

I'd like to express my support for this option. Whenever I connect to a .onion server, I'm doing it because I'd prefer if Electrum only used .onion servers for privacy and I'm sure other users like me feel the same way.

@ecdsa
Copy link
Member

ecdsa commented Feb 23, 2017

for the moment I fail to see how this option would improve privacy.
could someone please provide more details?

btw, it would be useful to remove .onion servers from the list when the user is not using tor.

@ecdsa ecdsa closed this as completed Feb 23, 2017
@leafcutterant
Copy link
Author

It doesn't improve privacy directly--it makes using only Tor nodes more convenient.

When you use Tor, you can achieve a higher degree of certainty in your anonymity if you connect to a .onion domain (a.k.a. "hidden service"), which entails going through 6 nodes in the Tor network, as opposed to connecting to a clearnet domain, which entails going through 3 nodes.

The way Electrum works now, if I want to use only .onion servers, the best thing I can do is setting the connection to one certain .onion server, and use that. If that single server becomes unresponsive or goes down--which is not an uncommon thing in the world of hidden services--I have to go to the network settings and choose another server.

The option I suggest (the basic one) makes server "shuffling" possible using only .onion servers, providing a more resilient user experience to those who want to raise their privacy standards.

The removal of .onion servers when not using a Tor sounds logical. But take note of a possible disadvantage: it gives the impression that there are no .onion Electrum servers, and people will be less interested towards using Electrum through Tor (the .onions displayed also serve as a reminder), thus resulting in more cases of people compromising their financial privacy.

Toporin pushed a commit to Toporin/electrum-satochip that referenced this issue Aug 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants