torcontrol : avoid to set wrong outbound proxy and network settings when creating an inbound onion service.

Saibato commented at 8:04 am on June 23, 2020: contributor

While fiddling around with torcontrol and other tor proxy settings, I noticed that the node tried to connect over the default 9050 port and ignored my settings.

That was the case when the node try’s to create a default hidden ephemeral tor service at startup.

So ,when we define our own proxy settings in conf, we don’t want this to be skipped by the default proxy creation that we setup while creating the ephemeral hidden onion service. Note; When -torcontrol and -proxy is defined in conf, we should not override this with the default settings 127.0.0.1:9050. Since the proxy ip and port might for good reasons have been set to other values.

Before this fix default settings could override conf and you could end up not to be able to connect to .onion nodes or connect over the wrong proxy.

Also fixes #14722 some years ago noticed by qubenix EDIT:

While check more options I wondered what PR #14425 is about? And indeed the -onlynet flags are clearly disregarded in respect to onions since #7553. We could merge #14425 or adapt the tor.md doku to the actual behavior. Here my suggestion, with some British humor. :woman_shrugging: My guess the consumption of the Catch22 movie, had influence when parts of the option logic where implemented in the first place.

edit saibato The Tor doc change laanwj mentioned later in review had moved to #20091 This PR now also fixes #13378 and is replacement for the fix from wodry #14425

fanquake added the label P2P on Jun 23, 2020

DrahtBot commented at 9:51 am on June 23, 2020: member

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#23077 (Full CJDNS support by vasild)
#22651 (tor: respect non-onion -onlynet= for outgoing Tor connections by vasild)
#15423 (torcontrol: Query Tor for correct -onion configuration by luke-jr)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

in src/torcontrol.cpp:542 in e83815d1fb outdated

534-            SetReachable(NET_ONION, true);
535+            addrOnion = proxyType(resolved, gArgs.GetBoolArg("-proxyrandomize", true));
536+            if (SetProxy(NET_ONION, addrOnion)) {
537+                LogPrintf("tor: Default outbound tor .onion address proxy is set to 127.0.0.1:9050\n");
538+                SetReachable(NET_ONION, true);
539+            }

laanwj commented at 1:59 pm on June 29, 2020:

I think this should also log when SetProxy fails, as It means there is a bug in the software. After all it tries to set a hardcoded value which should never fail.

in src/torcontrol.cpp:533 in e83815d1fb outdated

532-            proxyType addrOnion = proxyType(resolved, true);
533-            SetProxy(NET_ONION, addrOnion);
534-            SetReachable(NET_ONION, true);
535+            addrOnion = proxyType(resolved, gArgs.GetBoolArg("-proxyrandomize", true));
536+            if (SetProxy(NET_ONION, addrOnion)) {
537+                LogPrintf("tor: Default outbound tor .onion address proxy is set to 127.0.0.1:9050\n");

laanwj commented at 2:01 pm on June 29, 2020:

Please log to the right category:

0LogPrint(BCLog::TOR, "tor: Default outbound tor .onion address proxy is set to 127.0.0.1:9050\n");

laanwj commented at 2:12 pm on June 29, 2020: member

Concept ACK, good catch.

Concept ACK on the doc change as well. Though I’d suggest not refering to “nameproxy” as that’s an internal implementation detail. I think the gist is:

0+                       Note: Only the -proxy option will set the proxy used for DNS requests.
1+                       With this option these will not route over Tor.
2+                       So please use -proxy if you have privacy concerns with this.

This is the case because -onion is for multi-network nodes. You only want to use this option if you want your node to be able to connect to hidden services as well. Otherwise, always use -proxy.

BTW: as you found, the go-to document for configuring bitcoin over tor is doc/tor.md. It suggests using -proxy to route everything over tor. At some point it might make sense to refer to that instead of trying to cram everything in the option help.

And indeed the -onlynet flags are clearly disregarded in respect to onions since #7553.

Last time I checked, onlynet=onion still works, in combination with proxy=127.0.0.1:9050, to only make outgoing connections to onion peers.

Saibato force-pushed on Jun 30, 2020

Saibato commented at 4:09 pm on June 30, 2020: contributor

Last time I checked, onlynet=onion still works, in combination with proxy=127.0.0.1:9050, to only make outgoing connections to onion peers.

thx, hmm, lets put it that way. Suppose a user selects -onlynet=ipv4 selects -listen and -proxy or none. I guess the least thing a human would expect in that case, is that the node would use a forgotten open existing tor port, to kindly out and inbound route onion traffic. So i vote for an additional PR in line with #14425.

The more elleborate tor,md change when merged including your suggestions, at least warn now the user off this implications with the options use, but honestly, would you expect a purebitcoind -listen -onlynet=ipv4 node would ever connect outbound automatic to tor ?

Fact is, exactly that happens, a node that had an onion tor past and knows some onions, even later with a pure -onlynet=ipv4 conf, will open automatic outbound to those onions over tor, if a configed tor lingers forgotten or not on that cruft.

̶I̶t̶s̶ ̶n̶o̶t̶ ̶e̶a̶s̶y̶ ̶t̶o̶ ̶c̶r̶a̶f̶t̶ ̶n̶o̶d̶e̶s̶ ̶t̶o̶ ̶d̶o̶ ̶t̶h̶i̶s̶ ̶i̶n̶ ̶a̶ ̶o̶n̶e̶ ̶s̶h̶o̶t̶ ̶t̶e̶s̶t̶ ̶s̶e̶t̶u̶p̶,̶ ̶I̶ ̶t̶r̶y̶ ̶t̶o̶ ̶p̶o̶s̶t̶ ̶h̶e̶r̶e̶ ̶a̶ ̶b̶a̶s̶h̶ ̶s̶c̶r̶i̶p̶t̶ ̶t̶h̶a̶t̶ ̶d̶o̶e̶s̶ ̶t̶h̶e̶ ̶s̶t̶e̶p̶s̶,̶ ̶s̶i̶n̶c̶e̶ ̶t̶h̶a̶t̶ ̶i̶s̶ ̶a̶ ̶b̶i̶t̶ ̶r̶e̶l̶a̶t̶e̶d̶ ̶t̶o̶ ̶w̶h̶a̶t̶ ̶w̶e̶ ̶f̶i̶x̶ ̶h̶e̶r̶e̶,̶ ̶m̶i̶g̶h̶t̶ ̶b̶e̶ ̶t̶h̶e̶ ̶r̶i̶g̶h̶t̶ ̶p̶l̶a̶c̶e̶?̶

Its a d-feature?. although u need some patience i.e. if you do just bitcoind -onlynet=ipv6-listen on such node with forgotten working tor, that had fw or poor ipv6 outbound after some time since almost all hardcoded v2 onions are broken AFAICS only 3 of them work.the rng will roundabout 1 hours later have found a working one and automatic outbound connect over tor, what a magic.!

Saibato referenced this in commit 463314b127 on Jul 2, 2020

Saibato force-pushed on Jul 2, 2020

in doc/tor.md:38 in 463314b127 outdated

33@@ -29,8 +34,13 @@ outgoing connections, but more is possible.
34 
35 	-onlynet=onion  Make outgoing connections only to .onion addresses. Incoming
36 	                connections are not affected by this option. This option can be
37-	                specified multiple times to allow multiple network types, e.g.
38-	                ipv4, ipv6, or onion.
39+	                specified multiple times to define a set of general allowed network
40+	                types, e.g. ipv4,ipv6 or onion. If you use this option

jonatack commented at 4:34 am on July 20, 2020:

s/,ipv6/, ipv6/

in src/torcontrol.cpp:525 in 463314b127 outdated

523@@ -524,11 +524,15 @@ void TorController::auth_cb(TorControlConnection& _conn, const TorControlReply&
524 
525         // Now that we know Tor is running setup the proxy for onion addresses

jonatack commented at 4:35 am on July 20, 2020:

nit: while here, can you please touch this up to add a missing comma and fix “setup”, which is a noun but not a verb:

s/running setup/running, set up/

in src/torcontrol.cpp:527 in 463314b127 outdated

523@@ -524,11 +524,15 @@ void TorController::auth_cb(TorControlConnection& _conn, const TorControlReply&
524 
525         // Now that we know Tor is running setup the proxy for onion addresses
526         // if -onion isn't set to something else.
527-        if (gArgs.GetArg("-onion", "") == "") {
528+        // Or if we have already an outbound proxy defined. we skip this footgun gracefully.

jonatack commented at 4:39 am on July 20, 2020:

0        // Or if an outbound proxy is already defined, we can skip this gracefully.

in src/torcontrol.cpp:535 in 463314b127 outdated

534-            SetReachable(NET_ONION, true);
535+            addrOnion = proxyType(resolved, gArgs.GetBoolArg("-proxyrandomize", true));
536+            if (SetProxy(NET_ONION, addrOnion)) {
537+                LogPrint(BCLog::TOR, "tor: Default outbound tor .onion address proxy is set to 127.0.0.1:9050\n");
538+                SetReachable(NET_ONION, true);
539+            } else LogPrint(BCLog::TOR, "tor: Error default outbound tor .onion address proxy for 127.0.0.1:9050 failed to create\n");

jonatack commented at 4:53 am on July 20, 2020:

0            } else {
1                LogPrint(BCLog::TOR, "tor: Failed to create default outbound tor .onion address proxy for 127.0.0.1:9050\n");
2            }

Saibato commented at 8:54 am on July 21, 2020:

thx, had run it trough clang-format-diff and it also re-formated the net enum, will come up with test and clang-diff fixup push that we that can autosquash … , if you want to be co, i could commit the suggest as is, since i see it the same way, my while dev sarcasm comments must not be merged in the final version?

Saibato commented at 8:57 am on July 21, 2020:

Also i think about, split the tor.md from this PR since wording yields always to intensive discussion.

jonatack commented at 4:55 am on July 20, 2020: member

Concept ACK. Would you mind adding test coverage for the issue and code changes (perhaps in test/functional/feature_proxy.py)?

Saibato referenced this in commit 381ed7bcc1 on Jul 23, 2020

Saibato force-pushed on Jul 23, 2020

Saibato referenced this in commit cdf0b200f2 on Jul 23, 2020

luke-jr changes_requested

luke-jr commented at 10:46 pm on July 23, 2020: member

Concept NACK, I think… If we’re using -torcontrol, it makes sense to override -proxy (which is primarily for non-onion connections, and only used as a default for onions if no other is specified).

Perhaps a better alternative would be to disable -torcontrol (parameter interaction) if -proxy or -onion are set?

Saibato commented at 2:28 pm on July 24, 2020: contributor

Concept NACK, I think… If we’re using -torcontrol, it makes sense to override -proxy (which is primarily for non-onion connections, and only used as a default for onions if no other is specified).

Perhaps a better alternative would be to disable -torcontrol (parameter interaction) if -proxy or -onion are set?

I thought also about your suggestion, but dismissed that, since we have more problems that we should solve.

If you say pure -onion how to make sure the node does not dox the hidden service when the nameproxy is only selected by -proxy? And -onlynet=onion had never worked for seeds since they use ipv4 connect and dns anyway in disregard of any conf and when you say -dns they resolve over tor and with 5 known correlated seeders on bootstrap you are doxed again. And then when you say -dnseed=0, after one hour or so when you least expect it the random conman selects one of the 3 only active fixed seed onions, oops doxed again. What is build here is the prefect catch22.

Pls look also at #14425 and the patch for -onlynet i posted there, The status quo should change anyway and i am open for suggestions, But when -torcontrol would override -proxy in general that was introduced when tor was enabled to make outbound sock5 onion connections, i see not really why we should mix inbound -torcontrol configurations with outbound proxy that cloud be a remote tor cruft not in any way related to the local tor service port.

Also #19043 -tortarget should be seen in that whole tor setup logic it make from a privacy perspective prefect sense to add such an option as you can easy forward over tor the hidden service from an other cruft, what makes things even more interesting if you want to have tx and mempool fill, uncorrelated to your normal node operations and somewhat quasi on the fly could enable this,.

Cloud you outline how you would see the tor implementation work? Want we have now is not in line with the documentation, so we have to change anyway. And since our implementation with the keys stored permanent is as ephemeral as the holy night. I would like to mention here that we have with the Tor browser a stress free on click way to generate new hidden true ephemeral services on the fly i.e. over 9150/51 for posting as temp 3D code for short inbound. I guess something you would like to have from an other PR of yours. What is a good idea and nice to have.. . so hmm.. what now?.

DrahtBot added the label Needs rebase on Aug 9, 2020

Saibato referenced this in commit 654dc04b67 on Aug 15, 2020

Saibato force-pushed on Aug 15, 2020

Saibato commented at 12:42 pm on August 15, 2020: contributor

changed hidden to onion and rebased https://github.com/bitcoin/bitcoin/pull/19358/commits/468c60c5ed908ca8029db241b75aa8f893866c74 https://github.com/bitcoin/bitcoin/pull/19358/commits/654dc04b67a44199352a1b25494c9d617cd090bc

DrahtBot removed the label Needs rebase on Aug 15, 2020

qubenix commented at 1:27 am on September 29, 2020: contributor

Tested 654dc04b67a44199352a1b25494c9d617cd090bc, does indeed fix #14722. This is obviously a better fix than #14729.

fanquake commented at 6:38 am on September 29, 2020: member

This is obviously a better fix than #14729.

Thanks for testing @qubenix. I’ll close #14729.

fanquake commented at 6:44 am on September 29, 2020: member

@Saibato note that you also need to remove any @ mentions from your commit messages, 654dc04b67a44199352a1b25494c9d617cd090bc in this case. Otherwise those users will likely be spammed with mentions on GitHub.

Saibato force-pushed on Sep 30, 2020

Saibato commented at 8:51 am on September 30, 2020: contributor

Rebased and changed the commit messages of c40a121 and https://github.com/bitcoin/bitcoin/pull/19358/commits/efacd5f4f921e46652c4ef0ae83cadd782395793 like @fanquake suggested.

Btw; the more “correct” PR description should be. torcontrol :do not override silent behind the back of the user with default proxy settings in hidden service, if the user has chosen other settings according with the wording in the docs

hebasto commented at 8:18 pm on October 2, 2020: member

Concept ACK on making config options interaction more clear.

Approach NACK. Only establishing an onion service for inbound Tor connections should be the sole responsibility of the TorController class. Keeping in its implementation the code which deals with a proxy settings for outbound Tor connections looks like a bad design, that leads to behavior like that.

Saibato commented at 4:54 pm on October 4, 2020: contributor

t leads to behavior like … @hebasto U right, only at first glance it seams the right and only possible place since you can not know in init if the async call fails or succeeds Might also be the reason no one saw that for a long time at first glance when reviewing ie. src/init.cpp that setting the proxy would be overruled later. its a real mess and we should assume shit happens. And now we fix it.

I will push an alternative that try’s to solves that partly in init.cpp`. by assuming a partly successful call and place a comment there that we set the final proxy when we return the socket and announce the address.

Btw: now that #19991 is merged this driveby hook in torcontrol is anyway double effort The 3 letters should and can now use the standardized htonl hook like in any other inet socket app if they sneaky and as good netiysens i guess its the inevitable right thing in therms of compatibility with there monitor software suites and the KYC demands core will face anyway. Although this torcontrol mess was quite funny and original. edit@saibato: obviously some sarcasm here but when i found out about how Tor is used in conjunction with the option implications over all those years and how seeding works at first start, that was like :eyes: :woman_facepalming: :eyes:

Saibato force-pushed on Oct 6, 2020

Saibato renamed this:
~~net: Make sure we do not override proxy settings in hidden service.~~
torcontrol : avoid to set a wrong outbound socks proxy when creating an inbound onion service.
on Oct 6, 2020

Saibato force-pushed on Oct 6, 2020

Saibato commented at 8:58 am on October 6, 2020: contributor

Rebased https://github.com/bitcoin/bitcoin/pull/19358/commits/2b9572bf298ca9d4307ec7fe3f5ab8aba4f15e7f and renamed the PR and changed the pr commit message and stripped the doc https://github.com/bitcoin/bitcoin/commit/efacd5f4f921e46652c4ef0ae83cadd782395793 from the PR in favor of a new tor doc PR

Saibato commented at 11:59 am on October 6, 2020: contributor

Rebased fixup commit https://github.com/bitcoin/bitcoin/commit/2b9572bf298ca9d4307ec7fe3f5ab8aba4f15e7f we now init the outbound proxy in init.cpp Addressed also review comment from @hebasto It leaves torcontrol to solely do inbound stuff and init;s the outbound stuff in init.cpp

Its also now a replacement for #14425 and fixes #13378

The PR differs now much from the original PR so friendly ping also to @qubenix @wodry @laanwj @jonatack @luke-jr

in src/torcontrol.cpp:538 in 293c35c82d outdated

533-            CService resolved(LookupNumeric("127.0.0.1", 9050));
534-            proxyType addrOnion = proxyType(resolved, true);
535-            SetProxy(NET_ONION, addrOnion);
536-            SetReachable(NET_ONION, true);
537-        }
538-

vasild commented at 12:45 pm on October 6, 2020:

Isn’t this removal sufficient to fix #14722?

Saibato commented at 1:02 pm on October 6, 2020:

in some sense yes, i would also feel better to just remove this since something like this was anyway somehow without the users explicit consent. But i guess the main concern was to leak ip, if there is no proxy, but the implementation we had now for years was sub optimal at best.

If we can find there common ground to have by default no outbound Tor socks proxy, i am fine with this to just remove this. :-). On the other hand from privacy point it might be good to only generate inbound onion services, if there is a Tor proxy set, to not leak ip. And maybe do a hint comment to the users to encourage them to define at least -proxy= and write some hints in the docs.

And then do an extra PR for the -onlynet=onion.

Saibato commented at 1:20 pm on October 6, 2020:

@vasild thx for also looking at this. u might also notice that since -listenonion is the default, i am thinking right now, why not just create the service if we have a proxy in first place?

Bitcoin’s net is now big enough and we no longer need to create random onions to grow the net, so if -listenonion is removed as default we would have a bit more privacy and a clear torcontrol api.

vasild commented at 1:34 pm on October 6, 2020:

Correct me if I am wrong, if only the above code snippet is removed (no other changes), then the behavior will be:

`-proxy=` provided	`-onion=` provided	outcome
no	no	outgoing tor connections are not possible
no	yes	outgoing tor connections will be made via the proxy provided in `-onion=`
yes	no	outgoing tor connections will be made via the proxy provided in`-proxy=` (`-onion=` defaults to `-proxy=`)
yes	yes	outgoing tor connections will be made via the proxy provided in `-onion=`

regardless of whether -torcontrol= is provided or not. Which to me makes perfect sense. Users that want to avoid clearnet outgoing connections should set -proxy= to the tor socks5 proxy.

I think fixing -onlynet= is a separate issue and warrants a separate PR.

Saibato commented at 4:23 pm on October 6, 2020:

Makes sense and i addressed ur suggestion.

We now will not create the default outbound proxy and fix by that also the issue and dump a reminder in log that the user might leak his ip when no proxy is defined and the service call succeeds later somehow on purpose or i.e. when he enables Tor and the node runs already with listenonion, so at least better than the old footgun.

And since we now do not override -onlynet in torcontrol even in that regard better than what we had since years.

unknown commented at 5:01 pm on December 6, 2020:

Correct me if I am wrong, if only the above code snippet is removed (no other changes), then the behavior will be:

Thank you for the work of analyzing the behavior, @vasild and creating the overview table, this is very good.

Please see laanwj’s destinction of when using names “Tor” and when using “Onion” here: #13575 (comment)

As I understand, the onion= option is only about “onion” connections (that is, connections to .onion Onion services (aka deprecated name Hidden service).

While the proxy= setting, when set to a Tor node, forwards IPv4 (non .onion) requests to the Tor network, when they go out to the clearnet from a Tor exit node. As I underdstand, this would be named “tor connection”.

So, e.g. if proxy is unset and onion is set, then there will be Onion (and maybe IPv4/IPv6) connections, but no Tor connections.

And if proxy is set and onion is unset, then there will only be Tor connections connections (both via exit node to clearnet and to Onion services).

Would be an experiment to set both proxy and onion to different tor servers and check if really IPv4 connections go through the proxy-Tor server, and .onion connections go through the onion-Tor server. But I think this is not really relevant as I can not think of a use case of having two Tor servers to separate tor and onion connections.

So I think the definition would be:

Tor connection: Connection to IPv4 (and IPv6?) clearnet through Tor network tunnel, and optional to .onion services.
Onion connection: Connection to .onion service.

Saibato force-pushed on Oct 6, 2020

in src/init.cpp:1986 in 8a6d636c60 outdated

1974@@ -1975,6 +1975,10 @@ bool AppInitMain(const util::Ref& context, NodeContext& node, interfaces::BlockA
1975             InitWarning(strprintf(_("More than one onion bind address is provided. Using %s for the automatically created Tor onion service."), bind_addr.ToStringIPPort()));
1976         }
1977         StartTorControl(bind_addr);
1978+        proxyType addrOnion;
1979+        if (gArgs.GetArg("-onion", "") == "" && !GetProxy(NET_ONION, addrOnion) ) {
1980+            LogPrintf("Tor: reminder: listenonion is not disabled and an outbound Tor proxy is not defined, that could leak your ip\n");
1981+        }

vasild commented at 9:35 am on October 7, 2020:

I think just !GetProxy(NET_ONION, addrOnion) is enough. If the second expression is true then for sure the first one is true too.

But more importantly, I think this log message is unnecessary - the fact that a node is running a tor onion service does not mean they want to hide their IP address from the world. I guess -onlynet=onion implies that.

And even if we want to log a message - the above logic is flawed because we would not log it if -onion= is provided but -proxy= is not and thus the node would make outgoing IPv4 connections directly (revealing its IP address).

Saibato commented at 10:31 am on October 7, 2020:

In my view Its the other way around , the first might be false like u noticed and the user wants to leak his ip with -onion? Since -onion is always without nameproxy and the user must know that that leaks anyway. So i thought we should not warn him when he wish for that.

To have no -proxy set is in my view more concerning. At least with deleting the nameproxy leaking version by default we had until now we overall are better off with ur suggestion to delete it at all.

There is no clean solution, when we say -listenonion by default. even if we use IsReachable(NET_ONION) we could not skip all cases, since all nets are on by default.

Like i said in an other PR its a mess and we should fix it before the transition to v3. Not even thinking about seeding and the -onlynet flags, its doxing mess wherever u dig deep. Its almost often counter intuitive crafted and the reverse of what u define with some privacy options.
edit@saibato

I think just !GetProxy(NET_ONION, addrOnion) is enough

yes.

Saibato commented at 11:24 am on October 7, 2020:

@vasild could u imagine that we define a flag -privacynode=maximum,medium,low. That is by default on maximum?

i.e. maximum no listenonion if no proxy with nameproxy no seeding no dns no uunp onlynet respected everywhere just v3 no persistent keystore bind only to unrouteable addr if Tor etc. or low just as is.

That would really make things more easy to craft in the different modules core will split anyway, by not annoying the user with warnings and a clear guideline for devs .to follow when obeying those setting.

Saibato force-pushed on Oct 7, 2020

Saibato renamed this:
~~torcontrol : avoid to set a wrong outbound socks proxy when creating an inbound onion service.~~
torcontrol : avoid to set wrong outbound proxy and network settings when creating an inbound onion service.
on Oct 7, 2020

Saibato commented at 12:21 pm on October 7, 2020: contributor

Rebased addressed review and added the detrimental followup -onlynet fixup.commit https://github.com/bitcoin/bitcoin/pull/19358/commits/e9452a1a8f673de1b310e918ae80c31b7be6f171

Saibato renamed this:
~~torcontrol : avoid to set wrong outbound proxy and network settings when creating an inbound onion service.~~
[WIP] torcontrol : avoid to set wrong outbound proxy and network settings when creating an inbound onion service.
on Oct 7, 2020

Saibato force-pushed on Oct 8, 2020

torconrol: avoid to set a wrong socks proxy when creating an onion service.

Before this fix default settings could override conf and you could end
up not be able to connect to .onion nodes or connect over the wrong proxy.

Side effect of this fix is that we no longer create the default
Tor socks outbound proxy, that we would have created by chance if an inbound
Tor service creation was successful.
Since the old version anyway would have leaked our ip, this fix
now dumps a warning that an outbound Tor proxy is not defined.

b564259963

Saibato force-pushed on Oct 8, 2020

Saibato renamed this:
~~[WIP] torcontrol : avoid to set wrong outbound proxy and network settings when creating an inbound onion service.~~
torcontrol : avoid to set wrong outbound proxy and network settings when creating an inbound onion service.
on Oct 8, 2020

init: followup up fix of -onlynet settings.

While the onlynet=onion problem is fixed by not creating and outbound proxy
in torcontrol.
We now with this fix respect also the possible fine grained ipv4/ipv6 setting
combinations.

901ac08bdb

Saibato force-pushed on Oct 8, 2020

Saibato commented at 6:17 pm on October 8, 2020: contributor

Rebased https://github.com/bitcoin/bitcoin/commit/901ac08bdb400aece7a8d910da977acea65fa6af fixed the -onlynet settings for proxy use ready to review.

Willtech commented at 7:48 pm on October 15, 2020: contributor

Please note this should possibly resolve Issue #12641 when validating? -DA.

Saibato commented at 6:02 am on October 16, 2020: contributor

Please note this should possibly resolve Issue #12641 when validating? -DA.

I guess what u observe is that Tor can for sure over ip4/6 Tor exit nodes connect to nodes in the ip4/6 clearnet. if the address given to the socks5 proxy is not an onion address like from your seed.dat or address learned from other nodes.. Did u expect with -proxy just Tor onion address outbound connections? If so, please set also -onlynet=onion, pls ping me when even with this you still see outbound non onion connections.. I observed so far only the other way around, lingered forgotten onions in peers,dat would connect outbound if -onlynet=ipv4 or 6 is set. ooops.

Willtech commented at 2:32 pm on October 17, 2020: contributor

Good Afternoon, Reply via email.

I guess what u observe is that Tor can for sure over ip4/6 Tor exit nodes connect to nodes in the ip4/6 clearnet. Well, yes if it is not set onlynet=onion Did u expect with -proxy just Tor onion address outbound connections? Both onion and proxy are set to the tor proxy. -onlynet=onion onlynet=onion is fine and connections to pure onion addresses works, that is not the problem, the problem is not respecting the proxy setting.

DrahtBot added the label Needs rebase on Nov 8, 2021

DrahtBot commented at 1:51 pm on November 8, 2021: member

🐙 This pull request conflicts with the target branch and needs rebase.

Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a “draft”.

DrahtBot commented at 12:17 pm on February 22, 2022: member

Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
Is it no longer relevant? ➡️ Please close.
Did the author lose interest or time to work on this? ➡️ Please close it and mark it ‘Up for grabs’ with the label, so that it can be picked up in the future.

fanquake added the label Up for grabs on May 12, 2022

fanquake closed this on May 12, 2022

DrahtBot locked this on May 12, 2023

torcontrol : avoid to set wrong outbound proxy and network settings when creating an inbound onion service. #19358

Conflicts