Tor Single Onion Service support #9836

When enabled, this will allow the bitcoin client to set up its hidden service as a Single Onion Service. This will improve the speed of the service at the expense of its anonymity by removing the three hops between the service and its Rendezvous Point. Client anonymity will not be affected by this change.

We should be careful with this because many users actually intend to get anonymity. Perhaps it would be correct to use this when we are also taking v4 connections from the open internet, since in the case the anonymity is compromised by the other connections.

Yes, optional and default to off to retain the status quo is the good choice. There is the consideration that v4+onion can degrade anonymity due correlation, although there is currently no warning if serving on both networks. In that case it wouldn't matter if this was on, but since users are most familiar with the standard onion hidden service then the expected behavior should remain as is. The option can exist for those who want to run open nodes on v4+onion and make the best use of their bandwidth in supporting the p2p network.

Any idea how to request this from the Tor control socket?

ADD_ONION takes flags=NonAnonymous.

@keystrike Thanks, that seems simple to add to torcontrol.

While this is not a Bitcoin Core related issue, it's definitely worth noting this in the documentation of this feature.

Tor instances can either be in anonymous hidden service mode, or non-anonymous single onion service mode. All hidden services on the same tor instance have the same anonymity. To guard against unexpected loss of anonymity, Tor checks that the ADD_ONION "NonAnonymous" flag matches the current hidden service anonymity mode. The hidden service anonymity mode is configured using the Tor options HiddenServiceSingleHopMode and HiddenServiceNonAnonymousMode. If both these options are 1, the "NonAnonymous" flag must be provided to ADD_ONION. If both these options are 0 (the Tor default), the flag must NOT be provided.

https://github.com/torproject/torspec/blob/master/control-spec.txt#L1516

If I've read the control specifications right, both HiddenServiceSingleHopMode and HiddenServiceNonAnonymousMode must be set to 1 in the tor configuration file for the NonAnonymous flag to be activated. So in some sense, this protects users from doing stupid things by merely setting the wrong flag in the bitcoin configuration.

A small word of caution, if the tor daemon is running unrelated hardcoded (aka non-ephemeral) hidden services on the same instance then setting then HiddenServiceSingleHopMode and HiddenServiceNonAnonymousMode will cause ALL of those hidden services to be non-anonymous too.

Good point! Also once a service is run in NonAnonymous mode then it can't be run in Anonymous mode again. New keys need to be generated. I've posted a message in tor-dev to solicit comments as they may have useful suggestions.

tl;dr Ping Tor org on GitHub to double check? Some tools may interfere with the configuration causing nasty side effects? A decent warning in the documentation about side effects seems appropriate.

That's a good idea. The Tor developers maintain an active github organization, they helped guide the development of the ephemeral hidden services and stream isolation and iirc they were more than happy to help Bitcoin with any further developments that involve Tor in any form or shape. We can ping their GitHub organization for a double check.

I don't know if the issue you mentioned directly impacts the ephemeral services created by ADD_ONION in Bitcoin Core but when a bad configuration occurs then it is indeed a nasty side effect for all hardcoded onion services running through that particular Tor instance.

I can think of tools like OnionShare, Ricochet that could potentially interfere with the daemon, but I have not tested that. A mention that this mode can have side effects is worth documenting to prevent accidents, but that's about all you can do.

This will not work as expected and cause too many problems for little gains. You have to alter the entire Tor instance and make it in non anonymous mode by adding 2 configuration options set to 1.

Something more important is that, as a security measure, Tor won't allow you to open a SocksPort in non-anonymous mode (if you set those 2 torrc configuration options) which means that you will not be able to connect to any other .onion nodes, you will only accept incoming connections on your .onion hostname (and do outgoing connections to other nodes on the clearnet, without Tor). Not to say this will also break all other applications that use Tor on that server.

I think that this feature is unnecessary in Bitcoin Core. We assume who uses Bitcoin Core with Tor desires anonymity as well (maybe even partially). The users who don't want/need anonymity but use Tor and get it by default are not hurt, as opposite to those that want/need it but don't get it. Last but not least, it will be very hard to explain all this in few words that anyone can understand to the end users in order for them to take an informed decision and use the options correctly.

P.S. the traffic generated (both incoming and outgoing) by a full node can be easily handled with 3-hop circuits. Single onion services exist for very large centralized web servers that need to handle > tens of thousands of users behind Tor. I don't think Bitcoin Core will ever need to connect to such a crazy amount of peers (nor it should so).

ADD_ONION takes flags=NonAnonymous -- this is only an instruction to add a tag in the private_key file that contains the newly generated private key for that onion service so that a NonAnonymous onion service can never be re-used in anonymous mode later, and vice versa. It does not magically make things work, it won't work without further torrc options added.

Overall given the arguments above I think #10161 should not be merged.

@gits7r Ouch. I tend to agree then. People who really, really want it could configure it in the torrc level. But it seems to cause too many complex, confusing interactions to just offer as a configuration option of bitcoin core itself.

Thanks for getting back @gits7r. Ouch indeed. I didn't realize speed improvements would not be significant in our case. I agree it should be left out so I'll close the issue.

If someone wants to run a single hop onion service for whatever reason then they can still hardcode one in torrc. I don't see any substantial benefit to adding it for ephemeral onions tho.