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.

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:

+                       Note: Only the -proxy option will set the proxy used for DNS requests.
+                       With this option these will not route over Tor.
+                       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.

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.!

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?.

changed hidden to onion and rebased 468c60c 654dc04

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

Rebased addressed review and added the detrimental followup -onlynet fixup.commit e9452a1

Rebased 901ac08 fixed the -onlynet settings for proxy use ready to review.

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

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.

🐙 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".}

• 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.