doc: Improve Tor docs #21157

ghost · 2021-02-11T21:45:15Z

Highlight the part which mentioned about DNS requests and Tor usage
Add an example to make it easier for normal users or even power users to ignore all the other details and try basic setup first to avoid confusion
Add 4 privacy recommendations

About usage of Tor and Tor bridges, suggestions to consider tradeoffs based on user environment.
Mention about Deleting "onion_v3_private_key" frequently doesn't help and for some users its better to not use Bitcoin Core Onion Service.
Trade-offs involved in using onlynet=onion
Downloading packages using torsocks
Context: doc: tor.md and -onlynet help updates #20757 (comment)

Reasons:

Point mentioned about DNS requests is important. I am not sure if we can include more details in this doc but it should be highlighted. I had asked one related question recently on Reddit: https://www.reddit.com/r/Bitcoin/comments/l641hj/dns_requests_in_bitcoin_core/
Usage of Tor and Tor bridges is not same in all places. Users should be aware of such things.
Adding an example makes it easier for normal users to refer this doc when they try Bitcoin Core Onion Service first instead of reading several other articles, thread, questions etc. on different websites. Recently someone tweeted a thread about installing Bitcoin Core: https://twitter.com/Ethan_Heilman/status/1355645616056098817

Fixes #19923

jonatack

Some suggestions below.

doc/tor.md

jonatack · 2021-02-11T23:27:00Z

(p.s. thank you, it's very kind, but no need to add me as a co-author just for reviewing)

Saibato · 2021-02-12T11:36:14Z

tACK 056ad79

nit, Maybe u can add a followup PR?
And electorate further a max privacy ( probable dual node remote Tor service ) config, and the subsequent config steps. since by default a node will listen for clearnet and Tor connections.
And service ( if that became or is possible, instantly even later on the fly i.e when the node runs and a user would just install first time Tor or enable it, while a default configed node is running ) in and outbound pure Tor onions, while all dns (UDP) and gossip (TCP) will still route over ip4/6.

For maximal privacy, not listening at all is preferable over creating an
onion service

ghost · 2021-02-12T14:05:33Z

And electorate further a max privacy ( probable dual node remote Tor service ) config, and the subsequent config steps. since by default a node will listen for clearnet and Tor connections.
And service ( if that became or is possible, instantly even later on the fly i.e when the node runs and a user would just install first time Tor or enable it, while a default configed node is running ) in and outbound pure Tor onions, while all dns (UDP) and gossip (TCP) will still route over ip4/6.

This looks interesting but I think we can do this in a new PR together if you could share more details with me on Twitter
or Reddit I will experiment with things and let you know.

jonatack

A couple more comments below.

Given the number of times I've seen people think the onlynet=tor is the only good option (e.g. the GUI pull that would only display the onion icon if all peers are onion peers), it would seem valuable to add some of the points mentioned by @sipa or maybe the wiki I linked, but that could also be done in a different pull.

doc/tor.md

ghost · 2021-02-12T17:11:44Z

it would seem valuable to add some of the points mentioned by @sipa or maybe the wiki I linked, but that could also be done in a different pull

Sure. We can add some of the things mentioned above about onlynet=onion

Maybe in "Privacy Recommendations"? Can include few important points mentioned by @sipa and @jonatack

Not sure what exactly should be the sentences and if this PR or a new PR.

RiccardoMasutti · 2021-02-15T12:55:57Z

I think we should also talk about torsocks and advice users to download packages with it:

Torsocks is a torifying wrapper that is primarily used to redirect all the network traffic of individual SOCKS-friendly applications through the Tor network. It also ensures DNS queries are handled correctly and explicitly blocks all UDP traffic from the application in question. Torsocks is the successor of tsocks and is still actively maintained. It is simply packaged as torsocks and is available (and often automatically included with the tor package) in many *nix based distributions.

ghost · 2021-02-15T15:52:10Z

I think we should also talk about torsocks and advice users to download packages with it:

Sure. Let me add this and other things suggested above by sipa and jonatack.

ghost · 2021-02-15T23:07:44Z

I have added things suggested by @sipa and @jonatack related to usage of onlynet=onion and downloading packages using torsocks suggested by @RiccardoMasutti as privacy recommendations in c3f2243

doc/tor.md

ghost · 2021-02-23T12:00:12Z

Let's make it less complicated by improving docs:

https://twitter.com/StopAndDecrypt/status/1363977828291784706

jarolrod

Concept ACK, Some suggestions below. I still need to get to the additions in the Privacy recommendations section

doc/tor.md

jarolrod

Some more suggestions on the Privacy Recommendation section. Also, you must squash your commits into one. Any further commits should also be squashed.

doc/tor.md

michaelfolkson

Concept ACK. Just a couple of nits so far but this is looking good, thanks for working on this.

I'll follow the instructions at a later date and give some feedback on how easy they were to follow and if I feel they could be improved.

doc/tor.md

DrahtBot · 2021-03-15T16:50:08Z

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

RiccardoMasutti

ACK. Nice job guys.

Willtech · 2021-03-20T13:47:52Z

torsocks seems to easily work with torsocks bitcoin-qt --listen=0 in my testing. Requires --listen=0

torsocks is included by default with sudo get install tor on any recent Fedora

Is it useful to tell people to install nyx if they wish to monitor Tor?
If we become Tor central is that bad?

I think we should also talk about torsocks and advice users to download packages with it:

ghost · 2021-03-21T06:18:36Z

Is it useful to tell people to install nyx if they wish to monitor Tor?

Yes. Looks interesting. Never used it before but tried today and best thing I like about is the description in FAQ:

Simple - because the Greek goddess of night is short and memorable. Terminal applications are handiest when they're brief and easy to type. Top, ssh, scp - anything longer is just begging to be aliased down.

Maybe we can have a mini nyx for bitcoind or new RPC. Although a new follow up PR would be better to increase the probability of getting things merged soon and make it easier for people to review.

If we become Tor central is that bad?

Can you explain this in detail?

jonatack

A few grammar fixups and suggestions.

doc/tor.md

jonatack · 2021-03-21T14:27:36Z

torsocks seems to easily work with torsocks bitcoin-qt --listen=0 in my testing. Requires --listen=0
* Is it useful to tell people to install nyx if they wish to monitor Tor?

Mentioning using nyz (and watch -netinfo, e.g. bitcoin-cli -netinfo help) as node network monitoring tools could be useful indeed.

ghost · 2021-03-21T17:50:07Z

A few grammar fixups and suggestions.

@jonatack Thanks for the review. Made changes in 193f24c

ghost · 2021-03-27T17:41:58Z

doc/tor.md

+**3. Add user to Tor group ("satoshi" in this example):**
+
+```
+sudo usermod -a -G debian-tor satoshi


I think we will get permission error if we don't reboot system after adding user to Tor group. So maybe 4 can be replaced by sudo reboot. Let me know if you test these steps on Ubuntu @michaelfolkson

The note to reboot after using usermod exists in the latest commit e1604b3 from Feb 4.

ghost · 2021-03-28T14:55:36Z

~~I won't be active anymore. This is my only PR open in Bitcoin Core. Maintainers can close it or keep it open based on process followed.~~

~~Thanks everyone.~~

Reopened PR. Will update with one change discussed above about reboot

Willtech · 2021-04-02T08:36:02Z

Concept ACK
Need to re-check the proposed merge e.g. #21157 (comment)

Willtech · 2021-04-02T08:38:17Z

doc/tor.md

+- In some regions of the world usage of the Tor network is monitored and/or blocked.
+  If you are in an environment that does not permit direct Tor connections or the use
+  of Tor bridges, then considering the trade-offs, it may not be safe to use Tor.
+  Another option for Bitcoin network privacy is to use I2P (option `i2p`).


What is I2P (option i2p)?

I2P is the Invisible Internet Project, a second privacy network that was added to Bitcoin Core for the upcoming release.

I've written some docs for an initial doc/i2p.md file here, just need to overcome my desire to avoid bikeshedding to propose it 😛

I interpret this paragraph as advice to people to be careful in regions where Tor is legally disallowed or discouraged. I would suspect that places that legally ban Tor also legally ban I2P, so I think the final sentence here is a bit out of place---it seems to suggest that people who can't use Tor for legal reasons can use I2P.

I'd suggest rewriting the paragraph to encompass both options. E.g.: "In some regions of the world usage of privacy networks such as Tor or I2P (option: i2p) in monitored or blocked...it may notbe safe to use Tor or I2P."

doc/tor.md

RiccardoMasutti

ACK 16db258

jonatack

A few comments after re-reviewing. Some parts seem a bit redundant or verbose; don't hesitate to tighten them up.

doc/tor.md

rebroad · 2021-05-03T13:27:57Z

doc/tor.md

+Ensure that `torrc` has these settings, and save:
+
+```
+ControlPort 9051


In my experience this was the only line needed. I haven't needed the following two lines on any of my nodes.

listen is 1 by default except if proxy is used so maybe we can remove this line or add proxy as well.

debug=tor is for logs

@rebroad Just realized this comment was about Tor config file. Sorry earlier I thought its about torcontrol in bitcoin.conf

Are you using torpassword in bitcoin.conf?

rebroad · 2021-05-03T13:30:24Z

Have you mentioned the importance of using Tor version 4? Ideally it would be nice if bitcoin-qt could pop up an alert to the user if the tor version is too old to be useable.

michaelfolkson · 2021-05-04T17:27:53Z

@rebroad:

Have you mentioned the importance of using Tor version 4?

What is the importance of using Tor version 4? It is important to use Tor v3 addresses as v2 addresses are EOL but beyond that I'm not clear on the importance of using Tor version 4. Some critical bug fixes?

ghost · 2021-05-05T18:57:15Z

Have you mentioned the importance of using Tor version 4?

Latest Tor version is 0.4.5.7 according to https://www.torproject.org/download/tor/

Ideally it would be nice if bitcoin-qt could pop up an alert to the user if the tor version is too old to be useable.

I think this is a good suggestion and can be added with a new PR if others agree with it. I had some issues with Tor version once: #21147

ghost · 2021-06-02T16:35:14Z

Added proxy in example and rephrased one trade-off according to the suggestion in #21157 (comment)

Its been 4 months, PR reviewed by 11 people, almost every suggestion according to the scope of PR was acknowledged and made changes accordingly. Feel free to ACK/NACK so that we can merge this soon and improve Tor docs.

harding · 2021-06-02T22:41:09Z

ACK cb46911 . Also implementing the suggestion in https://github.com/bitcoin/bitcoin/pull/21157/files#r644364143 would be fine (I don't think it matters either way)

+ Highlight DNS requests part + Add 1 example in the end + Add 4 Privacy recommendations + Mention about `onlynet=i2p`

RiccardoMasutti

ACK a51c1b7

doc/tor.md

ghost · 2021-06-23T01:16:48Z

Thanks everyone for review. I am closing this PR in favor of alternative PRs: 22316 and 22317

Almost everything remains same. Feel free to ACK/NACK it. Keeping things separate so that one type of change doesn't keep the whole PR pending.

DrahtBot · 2021-06-23T05:12:52Z

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

doc: Highlight DNS requests part in tor.md #22317 (doc: Highlight DNS requests part in tor.md by prayank23)
doc: Add 5 privacy recommendations in tor.md #22316 (doc: Add 5 privacy recommendations in tor.md by prayank23)

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.

ecde04a [Consensus] Bump Active Protocol version to 70923 for v5.3 (random-zebra) b63e4f5 Consensus: Add v5.3 enforcement height for testnet. (furszy) f44be94 Only relay IPv4, IPv6, Tor addresses (Pieter Wuille) 015298c fix: tor: Call event_base_loopbreak from the event's callback (furszy) 34ff7a8 Consensus: Add mnb ADDRv2 guard. (furszy) b4515dc GUI: Present v3 onion addresses properly in MNs list. (furszy) 337d43d tests: don't export in6addr_loopback (Vasil Dimov) 2cde8e0 GUI: Do not show the tor v3 onion address in the topbar. (furszy) 0b5f406 Doc: update tor.md with latest upstream information. (furszy) 89df7f2 addrman: ensure old versions don't parse peers.dat (Vasil Dimov) bb90c5c test: add getnetworkinfo network name regression tests (Jon Atack) d8e01b5 rpc: update GetNetworksInfo() to not return unsupported networks (Jon Atack) 57fc7b0 net: update GetNetworkName() with all enum Network cases (Jon Atack) 647d60b tests: Modify rpc_bind to conform to bitcoin#14532 behaviour. (Carl Dong) d4d6729 Allow running rpc_bind.py --nonloopback test without IPv6 (Kristaps Kaupe) 4a034d8 test: Add rpc_bind test to default-run tests (Wladimir J. van der Laan) 61a08af [tests] bind functional test nodes to 127.0.0.1 Prevents OSX firewall (Sjors Provoost) 6a4f1e0 test: Add basic addr relay test (furszy) 78aa61c net: Make addr relay mockable (furszy) ba954ca Send and require SENDADDRV2 before VERACK (Pieter Wuille) 61c2ed4 Bump net protocol version + don't send 'sendaddrv2' to pre-70923 software (furszy) ccd508a tor: make a TORv3 hidden service instead of TORv2 (Vasil Dimov) 6da9a14 net: advertise support for ADDRv2 via new message (furszy) e58d5d0 Migrate to test_large_inv() to Misbehaving logging. (furszy) d496b64 [QA] fix mininode CAddress ser/deser (Jonas Schnelli) cec9567 net: CAddress & CAddrMan: (un)serialize as ADDRv2 Change the serialization of `CAddrMan` to serialize its addresses in ADDRv2/BIP155 format by default. Introduce a new `CAddrMan` format version (3). (furszy) b8c1dda streams update: get rid of nType and nVersion. (furszy) 3eaa273 Support bypassing range check in ReadCompactSize (Pieter Wuille) a237ba4 net: recognize TORv3/I2P/CJDNS networks (Vasil Dimov) 8e50853 util: make EncodeBase32 consume Spans (Sebastian Falbesoner) 1f67e30 net: CNetAddr: add support to (un)serialize as ADDRv2 (Vasil Dimov) 2455420 test: move HasReason so it can be reused (furszy) d41adb4 util: move HasPrefix() so it can be reused (Vasil Dimov) f6f86af Unroll Keccak-f implementation (Pieter Wuille) 45222e6 Implement keccak-f[1600] and SHA3-256 (Pieter Wuille) 08ad06d net: change CNetAddr::ip to have flexible size (furszy) 3337219 net: improve encapsulation of CNetAddr. (furszy) 910d5c4 test: Do not instantiate CAddrDB for static call (Hennadii Stepanov) 6b607ef Drop IsLimited in favor of IsReachable (Ben Woosley) a40711b IsReachable is the inverse of IsLimited (DRY). Includes unit tests (marcaiaf) 8839828 net: don't accept non-left-contiguous netmasks (Vasil Dimov) 5d7f864 rpcbind: Warn about exposing RPC to untrusted networks (Luke Dashjr) 2a6abd8 CNetAddr: Add IsBindAny method to check for INADDR_ANY (Luke Dashjr) 4fdfa45 net: Always default rpcbind to localhost, never "all interfaces" (Luke Dashjr) 31064a8 net: Minor accumulated cleanups (furszy) 9f9c871 tests: Avoid using C-style NUL-terminated strings as arguments (practicalswift) f6c52a3 tests: Add tests to make sure lookup methods fail on std::string parameters with embedded NUL characters (practicalswift) a751b9b net: Avoid using C-style NUL-terminated strings as arguments in the netbase interface (furszy) f30869d test: add IsRFC2544 tests (Mark Tyneway) ed5abe1 Net: Proper CService deserialization + GetIn6Addr return false if addr isn't an IPv6 addr (furszy) 86d73fb net: save the network type explicitly in CNetAddr (Vasil Dimov) ad57dfc net: document `enum Network` (Vasil Dimov) cb160de netaddress: Update CNetAddr for ORCHIDv2 (Carl Dong) c3c04e4 net: Better misbehaving logging (furszy) 3660487 net: Use C++11 member initialization in protocol (Marco) 082baa3 refactor: Drop unused CBufferedFile::Seek() (Hennadii Stepanov) e2d776a util: CBufferedFile fixes (Larry Ruane) 6921f42 streams: backport OverrideStream class (furszy) Pull request description: Conjunction of a large number of back ports, updates and refactorings that made with the final goal of implementing v3 Onion addresses support (BIP155 https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki) before the tor v2 addresses EOL, scheduled, by the Tor project, for (1) July 15th: v2 addr support removal from the code base, and (2) October 15th: v2 addr network disable, where **every peer in our network running under Tor will loose the connection and drop the network**. As BIP155 describes, this is introducing a new P2P message to gossip longer node addresses over the P2P network. This is required to support new-generation Onion addresses, I2P, and potentially other networks that have longer endpoint addresses than fit in the 128 bits of the current addr message. In order to achieve the end goal, had to: 1. Create Span class and push it up to latest Bitcoin implementation. 2. Update the whole serialization framework and every object using it up to latest Bitcoin implementation (3-4 years ahead of what we currently are in master). 3. Update the address manager implementing ASN-based bucketing of the network nodes. 4. Update and refactor the netAddress and address manager tests to latest Bitcoin implementation (4 years ahead of what we currently are in master). 5. Several util string, vector, encodings, parsing, hashing backports and more.. Important note: This PR it is not meant to be merged as a standalone PR, will decouple smaller ones moving on. Adding on each sub-PR its own description isolated from this big monster. Second note: This is still a **work-in-progress**, not ready for testing yet. I'm probably missing to mention few PRs that have already adapted to our sources. Just making it public so can decouple the changes, we can start merging them and i can continue working a bit more confortable (rebase a +170 commits separate branch is not fun..). ### List of back ported and adapted PRs: Span and Serialization: ---------------- * bitcoin#12886. * bitcoin#12916. * bitcoin#13558. * bitcoin#13697. (Only Span's commit 29943a9) * bitcoin#17850. * bitcoin#17896. * bitcoin#12752. * bitcoin#16577. * bitcoin#16670. (without faebf62) * bitcoin#17957. * bitcoin#18021. * bitcoin#18087. * bitcoin#18112 (only from 353f376 that we don't support). * bitcoin#18167. * bitcoin#18317. * bitcoin#18591 (only Span's commit 0fbde48) * bitcoin#18468. * bitcoin#19020. * bitcoin#19032. * bitcoin#19367. * bitcoin#19387. Net, NetAddress and AddrMan: ---------------- * bitcoin#7932. * bitcoin#10756. * bitcoin#10765. * bitcoin#12218. * bitcoin#12855. * bitcoin#13532. * bitcoin#13575. * bitcoin#13815. * bitcoin#14532. * bitcoin#15051. * bitcoin#15138. * bitcoin#15689. * bitcoin#16702. * bitcoin#17243. * bitcoin#17345. * bitcoin#17754. * bitcoin#17758. * bitcoin#17812. * bitcoin#18023. * bitcoin#18454. * bitcoin#18512. * bitcoin#19314. * bitcoin#19687 Keys and Addresses encoding: ---------------- * bitcoin#11372. * bitcoin#17511. * bitcoin#17721. Util: ---------------- * bitcoin#9140. * bitcoin#16577. * bitcoin#16889. * bitcoin#19593. Bench: ---------------- * bitcoin#16299. BIP155: ---------------- * bitcoin#19351. * bitcoin#19360. * bitcoin#19534. * bitcoin#19628. * bitcoin#19841. * bitcoin#19845. * bitcoin#19954. * bitcoin#19991 (pending). * bitcoin#19845. * bitcoin#20000 (pending). * bitcoin#20120. * bitcoin#20284. * bitcoin#20564. * bitcoin#21157 (pending). * bitcoin#21564 (pending). * Fully removed v2 onion addr support. * Add hardcoded seeds. * Add release-notes, changes to files.md and every needed documentation. I'm currently working on the PRs marked as "pending", this isn't over, but I'm pretty pretty close :). What a long road.. ACKs for top commit: random-zebra: utACK ecde04a Fuzzbawls: ACK ecde04a Tree-SHA512: 82c95fbda76fce63f96d8a9af7fa9a89cb1e1b302b7891e27118a6103af0be23606bf202c7332fa61908205e6b6351764e2ec23d753f1e2484028f57c2e8b51a

86a4a15 Highlight DNS request part (Prayank) Pull request description: _What?_ Highlight DNS requests part in Proxy section _Why?_ 1. DNS requests are very important while considering privacy 2. Lot of users might skip reading it because of the way it is mixed with everything else in the doc right now 3. I have seen lot of users ignoring DNS requests or unaware of such things while using privacy tools _How?_ Initially I had tried keeping these lines separate from code block but [Jonatack didn't agree with the changes](bitcoin/bitcoin#21157 (comment)). Harding suggested using [bold/italic in `<pre></pre>`](bitcoin/bitcoin#21157 (comment)). I have used the suggestions from previous PR and added `---` This is a part of alternative described in bitcoin/bitcoin#22316 ACKs for top commit: jonatack: ACK 86a4a15 Rspigler: ACK 86a4a15 achow101: ACK 86a4a15 RiccardoMasutti: ACK 86a4a15 lsilva01: ACK bitcoin/bitcoin@86a4a15 kristapsk: ACK 86a4a15 theStack: ACK 86a4a15 Tree-SHA512: a4fe0e8c08df330e5ca78ce19ce74be7034c653f4374469d928908847a6debf385283e3a6da66de600566c7bab6290ccd35df26864aef94cbb3f294123391437

86a4a15 Highlight DNS request part (Prayank) Pull request description: _What?_ Highlight DNS requests part in Proxy section _Why?_ 1. DNS requests are very important while considering privacy 2. Lot of users might skip reading it because of the way it is mixed with everything else in the doc right now 3. I have seen lot of users ignoring DNS requests or unaware of such things while using privacy tools _How?_ Initially I had tried keeping these lines separate from code block but [Jonatack didn't agree with the changes](bitcoin#21157 (comment)). Harding suggested using [bold/italic in `<pre></pre>`](bitcoin#21157 (comment)). I have used the suggestions from previous PR and added `---` This is a part of alternative described in bitcoin#22316 ACKs for top commit: jonatack: ACK 86a4a15 Rspigler: ACK 86a4a15 achow101: ACK 86a4a15 RiccardoMasutti: ACK 86a4a15 lsilva01: ACK bitcoin@86a4a15 kristapsk: ACK 86a4a15 theStack: ACK 86a4a15 Tree-SHA512: a4fe0e8c08df330e5ca78ce19ce74be7034c653f4374469d928908847a6debf385283e3a6da66de600566c7bab6290ccd35df26864aef94cbb3f294123391437

ghost mentioned this pull request Feb 11, 2021

doc: Improve Tor docs #21155

Closed

jonatack reviewed Feb 11, 2021

View reviewed changes

DrahtBot added the Docs label Feb 11, 2021

jonatack reviewed Feb 12, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

doc/tor.md Outdated Show resolved Hide resolved

RiccardoMasutti suggested changes Feb 15, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

jarolrod reviewed Feb 26, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

doc/tor.md Outdated Show resolved Hide resolved

jarolrod reviewed Mar 1, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

doc/tor.md Show resolved Hide resolved

doc/tor.md Outdated Show resolved Hide resolved

doc/tor.md Show resolved Hide resolved

jarolrod reviewed Mar 2, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

michaelfolkson reviewed Mar 9, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

doc/tor.md Outdated Show resolved Hide resolved

RiccardoMasutti approved these changes Mar 15, 2021

View reviewed changes

jonatack reviewed Mar 21, 2021

View reviewed changes

ghost commented Mar 27, 2021

View reviewed changes

Willtech reviewed Apr 2, 2021

View reviewed changes

ghost closed this Apr 3, 2021

fanquake added the Up for grabs label Apr 3, 2021

RiccardoMasutti suggested changes Apr 15, 2021

View reviewed changes

doc/tor.md Outdated Show resolved Hide resolved

doc/tor.md Outdated Show resolved Hide resolved

RiccardoMasutti approved these changes Apr 18, 2021

View reviewed changes

jonatack reviewed Apr 22, 2021

View reviewed changes

rebroad reviewed May 3, 2021

View reviewed changes

laanwj removed the Up for grabs label May 28, 2021

Improve Tor docs

a51c1b7

+ Highlight DNS requests part + Add 1 example in the end + Add 4 Privacy recommendations + Mention about `onlynet=i2p`

RiccardoMasutti approved these changes Jun 3, 2021

View reviewed changes

ghost mentioned this pull request Jun 4, 2021

test: Fix p2p_leak.py intermittent failure #22153

Merged

furszy mentioned this pull request Jun 7, 2021

Road to Tor v3 support (BIP155) PIVX-Project/PIVX#2411

Merged

Rspigler reviewed Jun 21, 2021

View reviewed changes