Option to make each request to server in separate TCP connection

[ectomens]

Currently, information about all addresses is requested in one TCP connection, so bad Electrum server can group addresses belonging to one person. This is unwanted in some cases.

I think, we need an option for making each request in separate TCP connection. Then servers located in .onion could not group addresses neither by same TCP connection nor by IP.

[EagleTM]

I second this - definitely needs to be a option to toggle because you may want to connect to one trusted server rather than spreading it out over a number of servers.

[ectomens]

2 options:

1. Ask each address in separate TCP connection.
2. Ask each address from random server [disabled of 1 is off].

For servers in .onion (1) is enough, but for public servers, which could distinguish users by (Tor exit node) IP, we need 1 and 2 for extra anonimity.

[EagleTM]

I don't see the benefit of implementing 1. - it would still be trivial for an operator of a server to collude the addresses by requesting IP

[ectomens]

EagleTM, if electrum server is accessed via onion layer (which is the best variant, I think), then electrum server operator sees no IP. If electrum server is accessed via Tor (exit node -> clearnet) and is popular enough then anytime multiple users are accessing this electrum server from same Tor exit node, so distinguishing them is not trivial as well.

[atweiden]

Building on suggestions so far, maybe with bip32 mode in the future, users could specify a server to connect to for each bip32 account in a wallet. We could also figure out a way to load multiple wallet files in a single GUI screen, kind of like multibit. Then select a server for each one.

As a more general solution, in --paranoid mode, add the context menu items Refresh Balance and Refresh Balance From. Client would not query any address balances unless explicitly told to do so in this mode.

Right-click an address in the Receive screen and click Refresh Balance to connect to a random server and query one specific address's balance, unless -1 | --oneserver mode is enabled. This context menu item would also work with multiple addresses highlighted/selected at once.

Refresh Balance From would allow the user to specify a particular server to query an address balance from.

If running in --scramble mode, the client would automatically connect to different randomly chosen servers for each address in the wallet, as has been suggested ITT.

[ecdsa]

@kyuupichan has implemented interface with select.select instead of threads. once his branch is merged, it might be possible to do that

[JeremyRand]

Since this issue is fairly old and I don't see a definitive answer, I'd like to ask before we expend resources on implementation: would a PR be accepted that creates an interface for each address subscription (with a randomly chosen server for each of those interfaces)? The behavior would be optional (maybe the user wants to use a trusted server); whether it's enabled by default is open to negotiation. It seems like a major privacy benefit, but I'm not really qualified to evaluate whether it would put too much load on the network. One of the Namecoin developers is interested in implementing this, if the concept is considered mergeable.

Also please note that it's feasible to create connections via multiple Tor exit relays; that's what https://github.com/spesmilo/electrum/pull/5470 does. So, the suggested attack where a server correlates multiple TCP connections by looking for a common exit IP is not an attack that we need to worry about.

[ecdsa]

@JeremyRand it is difficult to assess the privacy benefit of this idea.

1. with TOR, a single connection per address is an improvement. However, performance might be severely degraded.
2. without TOR, a server can still correlate your IP to a subset of your addresses. So, instead of leaking all your addresses to a single server, you are going to leak part of them it to multiple entities. 2.1: if auto-connect is used (i.e. servers are selected randomly), you want to add a strategy that ensures that you disclose the same subset of your addresses to a given server. if you don't do that, you will eventually leak more information to more servers than if you use a single server. 2.2: if auto-connect is not used, the user needs to be asked which servers will see which part of their addresses, and asked again if a server is unavailable. That seems really bad in terms of usability, unless the "subset of their addresses" if an entire wallet.

[SomberNight]

That seems really bad in terms of usability, unless the "subset of their addresses" if an entire wallet.

Note that currently if a user has multiple wallets open, all addresses in all wallets will be subscribed to using the same interface. So one idea is to at least separate the wallets; use a separate interface for each wallet.

[JeremyRand]

with TOR, a single connection per address is an improvement. However, performance might be severely degraded.

@ecdsa I'm fine with making this option only be available if Tor is in use (I think you're right that it will do more harm than good if used without Tor). What would be the main source of performance degradation? Is the issue that wallets with a large number of addresses would cause problems? If so, we could add a rule that, if this mode is enabled, only addresses that aren't touched by any existing transactions, or addresses that currently have a nonzero balance, would be subscribed to. This would decrease the number of subscribed addresses substantially, and I think it's fairly safe to assume that users who want very strong privacy are willing to avoid address reuse.

(Such a mode would probably be useful on its own as well, since it would probably improve performance for any users who don't reuse addresses, regardless of whether they use Tor.)

[ecdsa]

I agree it should only be used with Tor. Concerning performance, I think it is difficult to make predictions, those things should be tested. My main concern is that a wallet with 1000 addresses might never reach the synchronized state, because at any moment at least one of those 1000 connections could be down, for a reason or another.