It looks like doc/tor.md could use some updates and improvements, not only for Tor v3, but also for setting multiple addresses with -externalip (see the conversation from http://www.erisian.com.au/bitcoin-core-dev/log-2020-09-16.html#l-39), how to see information about your Tor config via Bitcoin Core, and other improvements.
Closes #19924.
Pls feel free to grab from https://github.com/bitcoin/bitcoin/commit/654dc04b67a44199352a1b25494c9d617cd090bc
Then I can strip this from #19358 and rename that and re push As. torcontrol :do not override with default proxy settings in hidden service, if the user has chosen otherwise according with the wording in the docs .
Since we until now notoriously in disrespect override the users wished settings with the defaults in torcontrol.
PR #19358 should be applied or tor.md doc changed to reflect that footgun.
69- Note that both addresses of a dual-stack system may be easily
70- linkable using traffic analysis.
71+ -externalip=X You can tell bitcoin about its publicly reachable addresses
72+ using this option, and this can be a .onion address. Given
73+ the above configuration, you can find your .onion address in
74+ /var/lib/tor/bitcoin-service/hostname. For connections
But this new text reads:
Given the above configuration …
and just a few lines above it says how to configure the hidden service via torrc:
HiddenServiceDir /var/lib/tor/bitcoin-service/ HiddenServicePort 8333 127.0.0.1:8333 HiddenServicePort 18333 127.0.0.1:18333
So it is ok to mention /var/lib/tor/bitcoin-service/hostname.
I would suggest to drop the last line HiddenServicePort 18333 127.0.0.1:18333 because it is for testnet and also to add HiddenServiceVersion 3 so that the tor daemon creates a v3 service:
0HiddenServiceDir /var/lib/tor/bitcoin-service/
1HiddenServiceVersion 3
2HiddenServicePort 8333 127.0.0.1:8333
bitcoind configure its onion service via torrc?
#19961 (review) Even given the above configuration, you make a point to consider we are talking about the operation of the parameter.
If the hidden service is created via tor-control and you need to discover it please check you debug.log for lines similar to the following, it should automatically be added as AddLocal
02020-08-11T13:42:26Z tor: Got service ID {random_service}, advertising service {random_service}.onion:8333
12020-08-11T13:42:26Z AddLocal({random_service}.onion:8333,4)
Few things that we can add in the updates:
Examples to run Bitcoin as onion service, use of tor bridges and safe ways to connect over tor: #19923
We can mention “How to check onion address”? : https://github.com/bitcoin/bitcoin/issues/19924
Thanks for taking this on! My concern is that the doc doesn’t really help the most common end users.
Connecting to Tor’s control socket API requires one of two authentication methods to be configured. It also requires the control socket to be enabled, e.g. put ControlPort 9051 in torrc config file. For cookie authentication the user running bitcoind must have read access to the CookieAuthFile specified in Tor configuration.
This is nonsense/scary to most people. This ultimately means that most users either don’t end up enabling Hidden Services, or have to go to other websites/tutorials to do so (which could be giving them wrong information). I think our docs could do a much better job explaining to the layperson how to do so.
I think our docs could do a much better job explaining to the layperson how to do so.
Agree. I think adding screenshots and examples could help.
I think our docs could do a much better job explaining to the layperson how to do so.
I don’t know if a tutorial for non-technical people is the kind of doc that should be in the source code repository, but it is indeed beyond the scope of what I planned to propose (which I’m scaling down to be reviewable).
Updated. If everyone can review today, maybe this can still be in 0.21 as rc4 is being finalised.
It may be easiest to review each commit separately. Happy to drop the last commit if it’s too much to review.
139-An alternative authentication method is the use
140-of the `-torpassword=password` option. The `password` is the clear text form that
141-was used when generating the hashed password for the `HashedControlPassword` option
142-in the tor configuration file. The hashed password can be obtained with the command
143-`tor --hash-password password` (read the tor manual for more details).
144+Since Tor version 0.2.7.1, Bitcoin Core makes use of Tor's control socket API to
nit: it is not proper to say “since Prog1 version X, Prog2 does this…”. It should be “Since Bitcoin Core version 1.2.3 we make use of…”.
I guess it is ok to just drop “Since Tor version 0.2.7.1, “.
160+authentication, the user running bitcoind must have read access to the
161+`CookieAuthFile` specified in the Tor configuration. In some cases this is
162+preconfigured and the creation of an onion service is automatic. If permission
163+problems are seen in the debug log (use `-debug=tor` for this logging), they can
164+be resolved by adding both the user running Tor and the user running bitcoind to
165+the same group and setting permissions appropriately. On Debian-based systems,
chmod -R 777 . - it always helps with filesystem permissions problems.
suggstetion i.e from https://github.com/ElementsProject/lightning/blob/master/doc/TOR.md
0---
1You also need to make your user a member of the Tor group. "Your user" here is whatever user will run lightningd. On Debian-derived systems, the Tor group will most likely be debian-tor. You can try listing all groups with the below command, and check for a debian-tor or tor groupname.
2
3getent group | cut -d: -f1 | sort
4
5Alternately, you could check the group of the cookie file directly. Usually, on most Linux systems, that would be /run/tor/control.authcookie:
6
7stat -c '%G' /run/tor/control.authcookie
8
9Once you have determined the ${TORGROUP} and selected the ${LIGHTNINGUSER} that will run lightningd, run this as root:
10
11usermod -a -G ${TORGROUP} ${LIGHTNINGUSER}
12
13Then restart the computer (logging out and logging in again should also work). Confirm that ${LIGHTNINGUSER} is in ${TORGROUP} by running the groups command as ${LIGHTNINGUSER} and checking ${TORGROUP} is listed.
14
15If the /run/tor/control.authcookie exists in your system, then log in as the user that will run lightningd and check this command:
16
17cat /run/tor/control.authcookie > /dev/null
18---
171+
172+An alternative authentication method is to use the `-torpassword=password`
173+option. The `password` is the clear text form that was used when generating the
174+hashed password for the `HashedControlPassword` option in the Tor configuration
175+file. The hashed password can be obtained with the command `tor --hash-password
176+password` (refer to the [Tor User Manual](https://tb-manual.torproject.org) for
148+Bitcoin Core automatically creates an onion service to listen on. The goal is to
149+increase the number of available onion nodes.
150+
151+This feature is enabled by default if Bitcoin Core is listening (`-listen`) and
152+it requires a Tor connection to work. It can be explicitly disabled with
153+`-listenonion=0`. If it is not disabled, it can configured using the
for some config and setup hints to add u could add, u might want to look into https://github.com/ElementsProject/lightning/blob/master/doc/TOR.md pls also note that the Torcontrol and onlynet bug fix PR;s are not merged in 0.21 so maybe some hint her fro the user to be not surprised by unexpected behavior might be a good idea. ref. 654dc04 @Saibato I rewrote the section 3 commit with that information, and cherry-picked your commit into this PR with a few fixups. Let me know.
Thanks for taking this on! My concern is that the doc doesn’t really help the most common end users.
Connecting to Tor’s control socket API requires one of two authentication methods to be configured. It also requires the control socket to be enabled, e.g. put ControlPort 9051 in torrc config file. For cookie authentication the user running bitcoind must have read access to the CookieAuthFile specified in Tor configuration.
This is nonsense/scary to most people. This ultimately means that most users either don’t end up enabling Hidden Services, or have to go to other websites/tutorials to do so (which could be giving them wrong information). I think our docs could do a much better job explaining to the layperson how to do so. @Rspigler in the end, I rewrote it in the last push with info from the c-lightning doc @Saibato suggested. It may not be for laypeople, but it is more of a tuturial now. Please have a look if you can.
44@@ -40,7 +45,11 @@ outgoing connections, but more is possible.
45 -onlynet=onion Make outgoing connections only to .onion addresses. Incoming
46 connections are not affected by this option. This option can be
47 specified multiple times to allow multiple network types, e.g.
48- ipv4, ipv6, or onion.
49+ ipv4, ipv6 or onion. If you use this option with values other
50+ than onion you *cannot* disable onion connections; outgoing onion
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.
Does this mean onlynet=ipv4 onion=0 does not disable onion connections? This seems confusing.
-noonion or onion=0 is always needed to explicitly disable outbound onion access, as described in the -proxy and onion section?
Does this mean onlynet=ipv4 onion=0 does not disable onion connections? This seems confusing.
Yes and No , a default fallback outbound pure .onion not IP name resolving proxy just for onion address will be created by default even without -proxy definition if ̶o̶n̶i̶o̶n̶!̶=̶0̶ ̶ ̶ to be precise if -onion== "" and regardless of -onlynet= if -listenonion=1 ( default) if the inbound Tor onion service could be created successfully by the ever polling torcontroller in bitcoind (What creates your advertised Tor address created by bitcoind independent of what onion services defined in torrc ) The idea was, (i guess) if that is successfully to create also an outbound proxy to reach Tor onion nodes.
So suppose u have a running bitcoind daemon and edit at some point just torrc to allow the control port or start the Tor service, bitcoind does if -listeonion=1 permanent poll for such changes and instantly creates on the fly an inbound onion address and an outbound proxy. So if u want to be sure that the outbound default proxy is disabled since u want i.e. just ipv4 set -noonion since -onlynet=ipv4 wont do that and please note the inbound Tor is created regardless of that if -listenonion=1 what is the default.
If that is a desired way to act depends, fixes or changes to that are not merged yet and at least that’s the way it is and its now documented so that users are aware of that.
@Rspigler tyi, only explicit -nonion or -onion=0 can prevent outbound onion connections, solely -onllynet=pv4/ipv6 is not sufficient to disable that.
that what is said in the PR now dropped.
0Please use -noonion or -onion=0 if you want to be sure to have no
1outbound onion connections over the default proxy or your defined proxy..
So please be so kind to hint what was misunderstanding in this wording that u came to the conclusion that -onion=0 would not prevent all outbound onion connections so that we can adapt that in followup PR
20
21 The first step is running Bitcoin Core behind a Tor proxy. This will already anonymize all
22 outgoing connections, but more is possible.
23
24- -proxy=ip:port Set the proxy server. If SOCKS5 is selected (default), this proxy
25+ -proxy=ip:port Set a proxy server. If SOCKS5 is selected (default), this proxy
What does it mean “If SOCKS5 is selected”? How does one select SOCKS5 or what other options are there to select from?
I think this should be removed:
0 -proxy=ip:port Set a proxy server. This proxy
as -proxy= only supports SOCKS5 proxies.
44@@ -30,7 +45,11 @@ outgoing connections, but more is possible.
45 -onlynet=onion Make outgoing connections only to .onion addresses. Incoming
46 connections are not affected by this option. This option can be
47 specified multiple times to allow multiple network types, e.g.
48- ipv4, ipv6, or onion.
49+ ipv4, ipv6 or onion. If you use this option with values other
50+ than onion you *cannot* disable onion connections; outgoing onion
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.
Huh! :-( This is indeed a strange behavior, but I think something like the following belongs to bitcoind -help rather than doc/tor.md:
If -onlynet= is used with other networks and -onlynet=onion is not among them, but -onion= or -proxy is provided then outbound onion connections will still be made! Use -noonion or -onion=0 to disable outbound onion connections in this case.
Given that this is a guide on how to enable and configure Tor, not how to disable it, I would suggest to drop the last part and leave it to just:
0-onlynet=onion Make outgoing connections only to .onion addresses. Incoming
1 connections are not affected by this option.
-onlynet=onion Make outgoing connections only to .onion addresses. Incoming connections are not affected by this option.
I guess its hard to grasp and i was :woman_facepalming: too when i stumbled about, but what we believed the code does from src comments or doc and almost any post i am aware about bitcoin and Tor and social media is not what really happens when assuming option do what they say and u follow the docs.
only -noonion or -onion=0 can prevent that, onlynet= is buggy since #7553 (2016) Similar but also fact is that although seeders are not called directly in IP if the DNS returns are random that is not the case when bootstrap over Tor here the seeders have full control and can be sure ( or ther MITM’S or proxys) that the first entry in the DNS return a exit gets will be called since socks5 works that way all seeders ( or what they want to be called ) will be called in a distinct sequence over exist and then ADDR gossip that is highly disturbing give the timing correlation bogus Tor relays and exits can do. Tacking in account that all that happens and wrong configured at bootstrap at least once, pure Tor nodes are quite f***ed if they not aware.
236+cat /run/tor/control.authcookie > /dev/null
237+```
238+
239+If the above prints nothing and returns, Bitcoin Core should work with your Tor
240+configuration. If it prints an error, a configuration problem will likely
241+prevent Bitcoin Core from working with your Tor.
I think this is excessive and should be removed.
0operator
1_tor
2You have new mail in /home/toolame/mailbox
so, if I am a dummy user, how do I know which is the tor group?
0$ stat -c '%G' /run/tor/control.authcookie
1stat: illegal option -- c
2usage: stat [-FLnq] [-f format | -l | -r | -s | -x] [-t timefmt] [file|handle ...]
This doc shouldn’t be targeted for users who lack basic knowledge of how filesystem permissions work.
Dropped the last two commits to reduce the scope to have this merged in time for rc4. I think they were good but they can be proposed in another PR.
Can everyone please ACK?
