doc: tor.md and -onlynet help updates #20757

This continues the tor documentation and help improvements of #19961 and clarifies issues that contributors have been mentioning and noticing, like in #20555 (comment).

More info:

• #19961 (review)
• #19961 (review)

<!--e57a25ab6845829454e8d69fc972939a-->

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

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #20957 (doc: Update tor.md for notes on how to preserve v2 urls (with a not recommended note) by nolim1t)
• #20582 ([doc] Fix documentation of options onlynet and listenonion by wodry)

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.

Seem ok to me

I like this better! ACK 3e84fe1f3330e227f00584dacd7e76045e8541f9 & 599a833c4a3ba8660e9d3c8b237997cca2b9eae4

Some edits to last commit

Thank you @Rspigler and @Saibato for the excellent feedback. Updated to hopefully address your suggestions. Would you please have another look? Here are all of the changes (last commit only):

<details><summary><code>git diff 8d6197d 316ecd0</code></summary><p>

diff --git a/doc/tor.md b/doc/tor.md
index dc26647641..5666ac522b 100644
--- a/doc/tor.md
+++ b/doc/tor.md
@@ -132,8 +132,9 @@ To see verbose Tor information in the bitcoind debug log, pass `-debug=tor`.
 
 ### Control Port
 
-You may need to set up the Tor Control Port. On most Linux distributions there
-will be the following commented-out settings in `/etc/tor/torrc`:
+You may need to set up the Tor Control Port. On Linux distributions there may be
+some or all of the following settings in `/etc/tor/torrc`, generally commented
+out by default (if not, add them):
 
@@ -141,9 +142,9 @@ CookieAuthentication 1
 
-Uncomment those, save, and restart Tor (usually `systemctl restart tor` or `sudo
-systemctl restart tor` on most systemd-based systems, including recent Debian
-and Ubuntu, or just restart the computer).
+Add or uncomment those, save, and restart Tor (usually `systemctl restart tor`
+or `sudo systemctl restart tor` on most systemd-based systems, including recent
+Debian and Ubuntu, or just restart the computer).
 
@@ -191,18 +192,24 @@ run bitcoind, run this as root:
 usermod -a -G ${TORGROUP} ${USER}
 
-Then restart the computer (logging out and back in again should also work), and
-confirm that the user is in the Tor group by running the groups command above.
+Then restart the computer (logging out and back in again should also work) and
+log in as the user that will run bitcoind.
 
-If the `/run/tor/control.authcookie` exists in your system, log in as the user
-that will run bitcoind and run this command:
+If the file `/run/tor/control.authcookie` exists in your system, you can confirm
+the user is in the Tor group by re-running:
+
+```
+stat -c '%G' /run/tor/control.authcookie
+```
+
+or with:
 
 cat /run/tor/control.authcookie > /dev/null
 
-If the above prints nothing and returns, Bitcoin Core should work with your Tor
-configuration. If it prints an error, a configuration problem will likely
+If the last command prints nothing and returns, Bitcoin Core should work with
+your Tor configuration. If it prints an error, a configuration problem may
 prevent Bitcoin Core from working with your Tor.
 
 #### `torpassword` authentication

</p></details>

I definitely like the direction we're heading in. But I have some questions from further testing I did:

We use stat -c '%G' /run/tor/control.authcookie to check the group of the cookie file, and then later recommend running the same command to confirm the user is in the Tor group?

Also, I tried running cat /run/tor/control.authcookie > /dev/null on a VM where I hadn't set up /etc/tor/torrc properly yet (so according to the docs, it should have printed an error). However, the command printed nothing and returns, which according to the docs means Core should work with Tor.

<!--4a62be1de6b64f3ed646cdc7932c8cf5-->

🕵️ @harding has been requested to review this pull request as specified in the REVIEWERS file.

Couple of things that I wanted to discuss and I don't think there will be a better place because its related to Bitcoin Core and Tor:

1. Dandelion++ was not implemented in Bitcoin Core. Details here: #20203 So Tor is very important for Bitcoin Core users. How do we make it easier for everyone to use and get more users running onion service when using Bitcoin Core? Maybe make the documentation user friendly? Can we add few screenshots? Can we add using Bitcoin Core on Android using ABCore or Nayuta as mentioned in the last part here: https://bitcoin.stackexchange.com/questions/98913/how-to-run-bitcoin-core-as-onion-service-on-windows-ubuntu-and-android

2. Tor recently had a consensus bug and I think it has lot of issues which are regularly exploited on different levels with some of them mentioned here: http://hackerfactor.com/blog/index.php?/archives/906-Tor-0day-The-Management-Vulnerability.html How do we improve privacy in Bitcoin Core without being dependent on Tor which has its own issues to deal with? Can we contact the author of this above mentioned blog and request to patch Tor for a good use (Bitcoin Core) and we maintain a fork of Tor? Are there enough developers interested to work on something like this which will involve lot of code, review, tests etc. ?

I tried asking on Twitter but there was no response: https://twitter.com/prayankgahlot/status/1305919047398162434

A couple of suggestions @prayank23.

1. Use IRC more (bitcoin-core-pr-reviews, bitcoin-core-dev channels). That is much better suited for general discussion and conversation (and I would prefer to respond to your questions there than on a Core PR in the middle of review). Of course sometimes no one responds on IRC, StackExchange or anywhere else. We all have to deal with this if we ask lots of questions. One of the downsides of open source. There is no boss or manager who is paid to answer all of your questions. Keep asking them though, it is a good way to learn. I have seen you get a lot of responses to your questions though you seem to get more frustrated than others when you don't get a response.

2. cc certain individuals with expertise in the area on IRC e.g. those who generally open PRs on Tor. If they are free I'm sure they will engage you in conversation on the topic they have expertise in.

However, the above is not helping this doc PR get merged. Core is not going to maintain a fork of Tor. That would be horrendous scope creep. We all have a motivation to improve documentation (Tor or otherwise). Feel free to open specific PRs to improve documentation. Some changes may not get review interest and some changes won't get merged. Again something you are going to have to get used to on open source projects.

Use IRC more (bitcoin-core-pr-reviews, bitcoin-core-dev channels). That is much better suited for general discussion and conversation (and I would prefer to respond to your questions there than on a Core PR in the middle of review). Of course sometimes no one responds on IRC, StackExchange or anywhere else. We all have to deal with this if we ask lots of questions. One of the downsides of open source. There is no boss or manager who is paid to answer all of your questions. Keep asking them though, it is a good way to learn. I have seen you get a lot of responses to your questions though you seem to get more frustrated than others when you don't get a response.

I have tried both IRC and Stackexchange. They work better for few things and sometimes the worst place to look for any help or discuss something. Your opinion on other things are irrelevant for discussion related to this PR.

cc certain individuals with expertise in the area on IRC e.g. those who generally open PRs on Tor. If they are free I'm sure they will engage you in conversation on the topic they have expertise in.

Yes I have done that for several things and sometimes even tried tagging people here on important issues/PR. Sometimes it works or maybe works for some people who are more open to contribution and humble.

However, the above is not helping this doc PR get merged.

Point 1 is about improving docs and few suggestions. Point 2 is about getting opinion on a blog which highlights issues with Tor

This PR is about Tor docs

Core is not going to maintain a fork of Tor. That would be horrendous scope creep.

Okay

We all have a motivation to improve documentation (Tor or otherwise). Feel free to open specific PRs to improve documentation. Some changes may not get review interest and some changes won't get merged. Again something you are going to have to get used to on open source projects.

Cool. I understand the things but we can always do better to improve things and go out of the box.

@prayank23 It's difficult to successfully propose changes to tor.md as it attracts requests and discussion, but we have been improving it little by little over time. What would be useful here is either specific feedback like @Rspigler has been providing (I'll update to address it!) or ACKs. FWIW, Tor is currently looking to hire an anti-censorship developer, if you're interested.

@jonatack ACK on changes proposed in this PR

I have suggested two additions in "Privacy" section: 1. Use Tor and Tor bridges according to user environment 2. Renewal of onion address

I think I will open a new PR for it and discussion on other topics will only happen if people think they are important (irrespective of platform used for discussion) for improving privacy in Bitcoin Core.

Thanks for sharing the tweet link.

Thanks for the feedback. I dropped the confusing parts at the end; updated the last commit per git diff 316ecd0 2bfc81b @Rspigler, @Saibato, @michaelfolkson, @prayank23, @RiccardoMasutti -- would you please have a look and comment, or ACK if the changes look good to you?

Linter error seems unrelated:

A new Boost dependency in the form of "boost/thread/mutex.hpp" appears to have been introduced:
src/sync.cpp:#include <boost/thread/mutex.hpp>
src/test/sync_tests.cpp:#include <boost/thread/mutex.hpp>

ACK 2bfc81b141dc8d6ba8546a03fb35561d806ead63 Tested cookie authentication on Debian according to docs, all issues discussed here (https://github.com/bitcoin/bitcoin/pull/20757#issuecomment-757380937) fixed.

ACK 2bfc81b141dc8d6ba8546a03fb35561d806ead63

I haven't tested but read through and looks good.

crACK 2bfc81b141dc8d6ba8546a03fb35561d806ead63

Suggest viewing the last commit with git show --color-moved=dimmed-zebra

ACK 193f9a9c975b612454a1f8121c09ef1e68d56dc1

ACK https://github.com/bitcoin/bitcoin/commit/193f9a9c975b612454a1f8121c09ef1e68d56dc1

Tested with below bitcoin.conf to automatically create bitcoin core onion service:

<pre> testnet=1 listen=1 onlynet=onion torcontrol=127.0.0.1:9151 debug=tor </pre>

Result for getnetworkinfo:

<pre> "localaddresses": [ { "address": "d2hsogah4kb5tswzy234xe6vnfw2qtj3ho26mf7yrmytp5vcryltreqd.onion", "port": 18333, "score": 4 } ] </pre>

DNS requests thing mentioned in https://github.com/bitcoin/bitcoin/pull/20757/commits/dfc4ce12735c405519de9e35b150052af23924a5 looks interesting although I couldn't find a way to test it and see the requests in Wireshark. Maybe the only thing which can make DNS requests while using Bitcoin Core is during IBD?

we maintain a fork of Tor

Believe me, you have no idea what you're suggesting here. A lot of resources go into development of Tor, and the Tor project has its own struggle to fight differently from the one bitcoin is, I think it would be an extremely bad idea to combine those. For example they have people dedicated to finding ways to circumvent internet censorship of regimes like China's, playing cat and mouse games.

Of course you are welcome to get involved in Tor's development, it being an open source project.

A much more realistic strategy that we have been pursuing with BIP155 addrv2 is to diversify potential overlay (and mesh) networks that can be used. For example #20685 adds working I2P support.

Believe me, you have no idea what you're suggesting here. A lot of resources go into development of Tor, and the Tor project has its own struggle to fight differently from the one bitcoin is, I think it would be an extremely bad idea to combine those

I was not sure and was thinking of solutions to decrease the dependency on Tor for privacy in Bitcoin. Looking for opinions from people who know better than me.

Of course you are welcome to get involved in Tor's development, it being an open source project.

I will try.

A much more realistic strategy that we have been pursuing with BIP155 addrv2 is to diversify potential overlay (and mesh) networks that can be used. For example #20685 adds working I2P support.

Sounds good :)