doc: tor.md and -onlynet help updates

jonatack commented at 8:22 pm on December 23, 2020: member

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:

jonatack renamed this:
~~doc: tor.md and -onlynet helpupdate -onlynet help in src/init.cpp~~
doc: tor.md and -onlynet help updates
on Dec 23, 2020

jonatack marked this as ready for review on Dec 23, 2020

DrahtBot commented at 9:38 pm on December 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:

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

DrahtBot added the label Docs on Dec 23, 2020

RiccardoMasutti commented at 12:27 pm on December 24, 2020: contributor

Seem ok to me

Rspigler commented at 4:58 am on January 6, 2021: contributor

I like this better! ACK 3e84fe1f3330e227f00584dacd7e76045e8541f9 & 599a833c4a3ba8660e9d3c8b237997cca2b9eae4

in doc/tor.md:82 in 8d6197d635 outdated

167+will be the following commented-out settings in `/etc/tor/torrc`:
168+
169+```
170+ControlPort 9051
171+CookieAuthentication 1
172+CookieAuthFileGroupReadable 1

Rspigler commented at 5:01 am on January 6, 2021:

On debian, I had to add CookieAuthFileGroupReadable 1, not comment-out

Saibato commented at 8:27 am on January 7, 2021:

yup, suboptimal wording

My suggestion would be will be the following by default commented-out settings, add or uncomment those ...

jonatack commented at 11:08 am on January 9, 2021:

Thanks for the feedback. Updated to:

0You may need to set up the Tor Control Port. On Linux distributions there may be
1some or all of the following settings in `/etc/tor/torrc`, generally commented
2out by default (if not, add them):
3
4ControlPort 9051
5CookieAuthentication 1
6CookieAuthFileGroupReadable 1
7
8Add or uncomment those, save, and restart Tor...

in doc/tor.md:133 in 8d6197d635 outdated

218+Once you have determined the `${TORGROUP}` and selected the `${USER}` that will
219+run bitcoind, run this as root:
220+
221+```
222+usermod -a -G ${TORGROUP} ${USER}
223+```

Rspigler commented at 5:03 am on January 6, 2021:

This all worked for me on Debian, except that usermod wasn’t found. To fix, I ran su -, then the command.

jonatack commented at 11:03 am on January 9, 2021:

Yes, it says “run this as root” and is to be expected. Thanks for verifying!

in doc/tor.md:195 in 8d6197d635 outdated

221+```
222+usermod -a -G ${TORGROUP} ${USER}
223+```
224+
225+Then restart the computer (logging out and back in again should also work), and
226+confirm that the user is in the Tor group by running the groups command above.

Rspigler commented at 5:05 am on January 6, 2021:

What “groups command above”? The above commands just show the Tor group is debian-tor, not that the user is in the Tor group? What works is the /run/tor/control.authcookie example below.

Rspigler commented at 5:07 am on January 6, 2021: contributor

Some edits to last commit

jonatack force-pushed on Jan 9, 2021

jonatack commented at 11:35 am on January 9, 2021: member

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):

 0diff --git a/doc/tor.md b/doc/tor.md
 1index dc26647641..5666ac522b 100644
 2--- a/doc/tor.md
 3+++ b/doc/tor.md
 4@@ -132,8 +132,9 @@ To see verbose Tor information in the bitcoind debug log, pass `-debug=tor`.
 5 
 6 ### Control Port
 7 
 8-You may need to set up the Tor Control Port. On most Linux distributions there
 9-will be the following commented-out settings in `/etc/tor/torrc`:
10+You may need to set up the Tor Control Port. On Linux distributions there may be
11+some or all of the following settings in `/etc/tor/torrc`, generally commented
12+out by default (if not, add them):
13 
14@@ -141,9 +142,9 @@ CookieAuthentication 1
15 
16-Uncomment those, save, and restart Tor (usually `systemctl restart tor` or `sudo
17-systemctl restart tor` on most systemd-based systems, including recent Debian
18-and Ubuntu, or just restart the computer).
19+Add or uncomment those, save, and restart Tor (usually `systemctl restart tor`
20+or `sudo systemctl restart tor` on most systemd-based systems, including recent
21+Debian and Ubuntu, or just restart the computer).
22 
23@@ -191,18 +192,24 @@ run bitcoind, run this as root:
24 usermod -a -G ${TORGROUP} ${USER}
25 
26-Then restart the computer (logging out and back in again should also work), and
27-confirm that the user is in the Tor group by running the groups command above.
28+Then restart the computer (logging out and back in again should also work) and
29+log in as the user that will run bitcoind.
30 
31-If the `/run/tor/control.authcookie` exists in your system, log in as the user
32-that will run bitcoind and run this command:
33+If the file `/run/tor/control.authcookie` exists in your system, you can confirm
34+the user is in the Tor group by re-running:
35+
36+```
37+stat -c '%G' /run/tor/control.authcookie
38+```
39+
40+or with:
41 
42 cat /run/tor/control.authcookie > /dev/null
43 
44-If the above prints nothing and returns, Bitcoin Core should work with your Tor
45-configuration. If it prints an error, a configuration problem will likely
46+If the last command prints nothing and returns, Bitcoin Core should work with
47+your Tor configuration. If it prints an error, a configuration problem may
48 prevent Bitcoin Core from working with your Tor.
49 
50 #### `torpassword` authentication

Rspigler commented at 11:05 pm on January 9, 2021: contributor

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.

DrahtBot commented at 11:46 am on January 13, 2021: member

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

in doc/tor.md:208 in 316ecd0df2 outdated

253+password` (refer to the [Tor Dev
254+Manual](https://2019.www.torproject.org/docs/tor-manual.html.en) for more
255+details).
256 
257 ## 4. Privacy recommendations
258

unknown commented at 3:31 pm on January 25, 2021:

Few things that we can add in “Privacy recommendations” section:

If Using Tor bridges or even Tor, consider privacy based on your environment: https://bitcoin.stackexchange.com/questions/98772/what-are-the-safe-ways-to-connect-to-bitcoin-network-using-tor
We discussed about renewal of onion address in every few days here and its difficult to disagree with Greg Maxwell when its something related to Bitcoin especially privacy and security, although I am still not sure and looking for more opinion about: For absolute security delete onion_private_key at each reboot or some frequent interval. mentioned in https://en.bitcoin.it/w/index.php?title=Setting_up_a_Tor_hidden_service&oldid=65982

unknown commented at 4:44 pm on January 25, 2021:

And here are few things suggested specifically for docs

Cc: @michaelfolkson

jonatack commented at 5:51 pm on January 25, 2021:

I read the links but it’s not clear to me from your comment what specific changes you would like to make to this PR, so resolving this for now. Feel free provide specific suggestions or open a pull with changes you would like to propose that you don’t see here.

ghost commented at 3:42 pm on January 25, 2021: none

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:

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

michaelfolkson commented at 4:32 pm on January 25, 2021: contributor

A couple of suggestions @prayank23.

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

ghost commented at 4:43 pm on January 25, 2021: none

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.

jonatack commented at 5:59 pm on January 25, 2021: member

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

ghost commented at 6:12 pm on January 25, 2021: none

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

jonatack force-pushed on Jan 25, 2021

jonatack commented at 8:28 pm on January 25, 2021: member

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?

doc: update -onlynet help in src/init.cpp 784a278e87

doc: update -proxy, -onion and -onlynet info in tor.md

Improve the description of what these options do with regards to
tor or network traffic.

Some of the wording is from a laanwj review in PR 19358.

dfc4ce1273

doc: update/improve automatic tor section of tor.md 9af99b6f39

jonatack commented at 8:32 pm on January 25, 2021: member

Linter error seems unrelated:

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

Rspigler commented at 11:03 pm on January 25, 2021: contributor

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

michaelfolkson commented at 11:28 am on January 26, 2021: contributor

ACK 2bfc81b141dc8d6ba8546a03fb35561d806ead63

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

in doc/tor.md:55 in 2bfc81b141 outdated

51+	                connections will be enabled when you use -proxy or -onion. Use
52+	                -noonion or -onion=0 if you want to be sure there are no outbound
53+	                onion connections over the default proxy or your defined -proxy.
54 
55 In a typical situation, this suffices to run behind a Tor proxy:
56

MarcoFalke commented at 11:45 am on January 26, 2021:

I think section 2 can be removed? There should be no package manager out there that ships tor 0.2.7. Even xenial has it: https://packages.ubuntu.com/xenial/tor

jonatack commented at 2:16 pm on January 26, 2021:

Good point. The manual config section still seems useful (if I understand correctly) but updated it and moved it after the automatic config section in 193f9a9c975b61.

MarcoFalke approved

MarcoFalke commented at 11:48 am on January 26, 2021: member

crACK 2bfc81b141dc8d6ba8546a03fb35561d806ead63

doc: update tor.md manual config, move after automatic config 193f9a9c97

jonatack force-pushed on Jan 26, 2021

jonatack commented at 2:24 pm on January 26, 2021: member

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

Rspigler commented at 7:08 pm on January 26, 2021: contributor

ACK 193f9a9c975b612454a1f8121c09ef1e68d56dc1

ghost commented at 10:32 am on January 27, 2021: none

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

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

Result for getnetworkinfo:

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?

MarcoFalke merged this on Jan 27, 2021

MarcoFalke closed this on Jan 27, 2021

jonatack deleted the branch on Jan 27, 2021

sidhujag referenced this in commit c2824b005a on Jan 27, 2021

laanwj commented at 10:52 am on January 28, 2021: member

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.

ghost commented at 10:58 am on January 28, 2021: none

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 :)

Fabcien referenced this in commit 1361f2c6b0 on Feb 15, 2022

Fabcien referenced this in commit bb0557c2cc on Feb 15, 2022

DrahtBot locked this on Aug 18, 2022

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

Conflicts