Possible feature request: Improve privacy by excluding addresses from query

[d5000]

I'm thinking about a feature request for Electrum and thought to present the idea here for comments and to make sure I understood the problem correctly.

Currently, as far as I know, when an Electrum client connects to a server, it queries the balance of all addresses from a full node. This of course shows the full node that these addresses belong together, and makes it easy for chain analysis companies to run servers and know about which addresses belong to a wallet.

There would be a relatively easy way to prevent this to link all your addresses together: allowing the user to exclude or include addresses from server queries.

Two models come into mind:

1) Easy one but not that user friendly: Allow the user to exclude addresses manually. The idea in this case would be simply to add a menu item similar to the "Freeze Address" feature, which allows the user to exclude addresses from the server query. It should be possible to invert this also, i.e. to query only the excluded addresses.

I believe this should to be easy to code and also not require many interface changes. A quite substantial setback for this one is however that the first time the user connects to the server, all addresses will be queried, so if he had the bad luck to connect to a chain analysis server, the damage would have already been done.

This could be mitigated by an additional change: the time the server connects, only the first addresses could be quieried. Or directly allow the user to include addresses explicitly instead of excluding them.

2) Allow the wallet addresses to be categorized in groups, and only a single group would be queried at a time.

This "sub-wallet" feature would be more user-friendly but require more interface changes. However, it would be the ideal solution I think. The advantage versus "simply creating many wallets" is that you only need a single seed.

Any suggestions or opinions are welcome!

[DireWolfM14]

I'm not sure that either feature will be appealing to the Electrum developers since both suggestions would take away from the user-friendliness of the wallet.  The way Electrum counts your coins is by syncing with the SPV server on startup, and I can't see them wanting to change that.  Furthermore, I don't think these features would be popular with the masses.  Most people aren't sticklers for privacy as are the denizens of this forum.  Just peruse "crypto twitter" for an idea of how lazy some people are when it comes to their privacy.  I'd say that's the norm, and we're the exception.

If you are so concerned about your privacy, you really should be running your own SPV server.  Setting up a Dell Optiplex with Umbrel is the easiest thing imaginable, and they can be purchased on ebay for cheaper than a Raspberry Pi.

If running your own server is out of the question, you could do exactly what you suggest by treating your wallet as a cold wallet, and exporting the address/keys you want to interact with and importing them into another wallet.

Again, given the options that the technically astute users have and the lack of public concern for this level of privacy, I don't see the Electrum developers putting much effort into this.  But hey, I'm just one guy with an opinion, and you asked for it.  

[d5000]

I'm not sure that either feature will be appealing to the Electrum developers since both suggestions would take away from the user-friendliness of the wallet.

I don't think so.

For the first option, it could be only a single additional item in the menu, and possibly a new color for the address list to show the excluded addresses (e.g. red or orange; yellow, green and blue are already used). Users would barely notice the change. The possibility to sync only a subset of addresses should be optional, possibly it could be selected during the configuration of a new wallet.

For the second option, it should be completely optional feature, i.e. if you dont enable it when starting the wallet or afterwards in your options, users would not be bothered by it.

The way Electrum counts your coins is by syncing with the SPV server on startup, and I can't see them wanting to change that.

I found the part of the code where this syncing takes place, it's the Synchronizer class in synchronizer.py:

Code:

    async def main(self):
        self.adb.up_to_date_changed()
        # request missing txns, if any
        for addr in random_shuffled_copy(self.adb.db.get_history()):
            history = self.adb.db.get_addr_history(addr)
            # Old electrum servers returned ['*'] when all history for the address
            # was pruned. This no longer happens but may remain in old wallets.
            if history == ['*']: continue
            await self._request_missing_txs(history, allow_server_not_finding_tx=True)

There are two options to exclude addresses:

- a very easy option would be to feed the list of excluded addresses into the main method of the synchronizer and only request addresses not excluded. The question here of course is where the list of excluded addresses should be stored. (Edit: removed code snippet, not necessary to illustrate point as it's trivial.)

- a probably better way: self.adb.db.get_history() seems to be the method which retrieves the addresses from the database. The database methods should be those excluding the addresses in this case, returning only the addresses which are not marked as "excluded" into the for loop shown above.

Again, given the options that the technically astute users have and the lack of public concern for this level of privacy, I don't see the Electrum developers putting much effort into this.

The thing is that I think this is a low hanging fruit and would need few code changes, as shown above. The most relevant change would be the additional column in the address table.

It's even possible that I could code a proof of concept of this myself as I know a little bit of Python ...

[pooya87]

I like your idea and would love to see privacy improvement in Electrum but it has a flaw.
Generally speaking if you want to separate funds, it is best to separate them completely to reduce the chances of mixture and privacy leaking. This separation is best done when they are in different wallets. If you want same seed phrase, then use the 13th word to separate them. It would be easier and it doesn't need any changes to Electrum.

Without that separation the risks of mixture and "leaking" is higher:
- It could be by mistake when you use coins from different addresses in the same transaction, effectively linking them (something that is avoided easily by using separate wallets).

- It could be linking by IP address which happens when you sync your wallet even if you use different "categories of addresses" or as you call it sub-wallet. Because the IP is the same, when you connect to servers the "fingerprint" is still the same which helps the privacy invading entity to link them if they run more than one Electrum Node. The risk of this can be reduced when using separate wallets because it helps change IP easier or for example route that wallet instance through a different TOR exit.

[ABCbits]

2) Allow the wallet addresses to be categorized in groups, and only a single group would be queried at a time.

This "sub-wallet" feature would be more user-friendly but require more interface changes. However, it would be the ideal solution I think. The advantage versus "simply creating many wallets" is that you only need a single seed.

I prefer this model. It'll encourage user to use multiple address for different purpose that improve their privacy.

Any suggestions or opinions are welcome!

I have nothing against your idea, but it won't happen considering Electrum only have partial taproot support until today. Although it's different case if you become the developer or pay a developer to create and maintain this feature.

If running your own server is out of the question, you could do exactly what you suggest by treating your wallet as a cold wallet, and exporting the address/keys you want to interact with and importing them into another wallet.

Alternatively, switch to wallet with BIP 157/158 support such as Ginger and Wasabi wallet.

[d5000]

- It could be by mistake when you use coins from different addresses in the same transaction, effectively linking them (something that is avoided easily by using separate wallets).

Yes, I'm aware of that. It's of course a feature that only makes sense if you extensively use coin control with it. Thus the idea is that it should be completely optional.

A full-fledged sub-wallet feature, where Electrum automatically uses coins only from the same sub-wallet in each transaction, would of course require more changes. It would be nevertheless the ideal solution I think.

Because the IP is the same, when you connect to servers the "fingerprint" is still the same which helps the privacy invading entity to link them if they run more than one Electrum Node.

Ah, thanks for mentioning the fingerprint, I'll investigate about how much information is shared with the server.

Of course you can also here avoid that, restarting Electrum (and possibily the Tor daemon) every time you use a different group of addresses. That's of course something that should in the long run be simplified with an "one button" solution but then the feature would already become a bit "heavier" and more unlikely to be implemented.

I prefer this model. It'll encourage user to use multiple address for different purpose that improve their privacy.

Yes, I agree. You can of course do this also manually, creating basically two groups of addresses per wallet: one which is excluded, and the other one which is excluded when you "invert" the query. Otherwise a lot of manual work is required, for ideal privacy you should try to query each address in a separate connection with the server (over different Tor nodes).

[pooya87]

Of course you can also here avoid that, restarting Electrum (and possibily the Tor daemon) every time you use a different group of addresses. That's of course something that should in the long run be simplified with an "one button" solution but then the feature would already become a bit "heavier" and more unlikely to be implemented.

That's true, but remember that we always have to see what the average user would do not what the expert user can do. The logic I'm using is the same thing used to criticize coins that call themselves "anon-coin" but the anonymity feature is not active by default like Zcash.