onlynet=onion trade-offsonion_v3_private_key is not one of the 'best practices'I have divided #21157 in 3 parts (Alternative to PR 21157):
Why?
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
No conflicts as of last run.
my opinion is don't split up #21157. Splitting up #21157 adds greater burden on reviewers and burden on you with required rebases.
While #21157 has required a lot of review attention, I don't think that splitting it up will make it easier to merge. If there is discussion to be had and reviewers still have feedback, seems suboptimal to split up this discussion over three PR's which all have the same purpose: to improve the tor docs.
If you have made the decision to split up #21157, then you should close it in favor of the three separate PR's.
three PR's which all have the same purpose: to improve the tor docs.
'Improving docs' is a bigger scoping of PR which is not helping in any way. Changes to docs that are specific get merged or rejected soon.
If you have made the decision to split up #21157, then you should close it in favor of the three separate PR's.
Done
ACK commit b7d465aa6d14b46c96870930679d6d5cb0b3b6f0
I think splitting the PR up how you have is beneficial (I had issues with the examples you added, but like this change and the DNS change in 22317).
Please tag when examples PR is added
240 | + 241 | + **Sybil Attacks** 242 | + 243 | + On the other hand, if you only make random Tor connections, you're much more vulnerable to Sybil attacks. 244 | + As Tor addresses may be created at no cost, an attacker can potentially flood the network with many Tor 245 | + nodes and receive all of the outbound Tor connections an `onlynet=tor` node makes.
nodes and receive all of the outbound Tor connections an `onlynet=onion` node makes.
242 | + 243 | + On the other hand, if you only make random Tor connections, you're much more vulnerable to Sybil attacks. 244 | + As Tor addresses may be created at no cost, an attacker can potentially flood the network with many Tor 245 | + nodes and receive all of the outbound Tor connections an `onlynet=tor` node makes. 246 | + 247 | + This is significantly less a concern with IPv4/IPv6 (especially with asmap) due to the cost of obtaining IPs in many
This is significantly less a concern with IPv4/IPv6 (especially when using the -asmap configuration option) due to the cost of obtaining IPs in many
243 | + On the other hand, if you only make random Tor connections, you're much more vulnerable to Sybil attacks. 244 | + As Tor addresses may be created at no cost, an attacker can potentially flood the network with many Tor 245 | + nodes and receive all of the outbound Tor connections an `onlynet=tor` node makes. 246 | + 247 | + This is significantly less a concern with IPv4/IPv6 (especially with asmap) due to the cost of obtaining IPs in many 248 | + networks. It's also alleviated if you make `-addnode` connections to trusted peers (even if they're onion addresses).
I'd put -addnode before IPv4/6 as it's a concrete step that Tor users can take.
ACK 2c18e7f
Good changes. ACK 2c18e7f6614d665f4eb9891f83391a5317e7d113 Apologies for missing the onlynet=onion/tor mistake
I think there is grammatical error but not sure:
--- a/doc/tor.md
+++ b/doc/tor.md
@@ -245,7 +245,7 @@ for normal IPv4/IPv6 communication, use:
As Tor addresses may be created at no cost, an attacker can potentially flood the network with many Tor
nodes and receive all of the outbound Tor connections an `onlynet=onion` node makes.
- This is significantly less a concern with if you make `-addnode` connections to trusted peers
+ This is significantly less a concern if you make `-addnode` connections to trusted peers
(even if they're onion addresses). It's also alleviated with IPv4/IPv6 (especially when using the -asmap
configuration option) due to the cost of obtaining IPs in many networks.
Yes, that change should be made, thanks!
248 | + This is significantly less a concern if you make `-addnode` connections to trusted peers 249 | + (even if they're onion addresses). It's also alleviated with IPv4/IPv6 (especially when using the -asmap 250 | + configuration option) due to the cost of obtaining IPs in many networks. 251 | + 252 | + If all of your connections are controlled by a Sybil attacker, they can easily prevent you from seeing confirmed 253 | + transactions and, with more difficulty, even trick your node into falsely reporting a transaction as confirmed
double space between transactions and and
Removed extra space in https://github.com/bitcoin/bitcoin/commit/45c1bfa90d70b334f5b5a025d785477980f239ee
tiny nit
- Tor bridges
- Disable listening for max privacy
- Torsocks
- `onlynet=onion` trade-offs
- Deleting `onion_v3_private_key` not best practice
222 | @@ -223,3 +223,40 @@ for normal IPv4/IPv6 communication, use: 223 | Otherwise it is trivial to link them, which may reduce privacy. Onion 224 | services created automatically (as in section 2) always have only one port 225 | open. 226 | + 227 | +- In some regions of the world the Tor network is monitored or blocked. 228 | + If you are in an environment that does not permit direct Tor connections or the use 229 | + of Tor bridges, then considering the trade-offs, it may not be safe to use Tor. 230 | + 231 | +- For maximum privacy, it is preferable to disable accepting incoming connections.
This seems like bad advice. Incoming connections should be encouraged, and any potential privacy risks addressed.
Both of these appear to be talking about security, not privacy. And not as general advice, but as super-paranoia.
This comment by Sipa specifically mentioned privacy: #21157 (review)
re: not encouraging this setting; I think the section on Sybil Attacks and Network Partitioning covers that, right?
I think many users will read this and go "oh good, I want maximal privacy, so I'll disable listening." IMO the statement as it is, and placed where it is, lacks nuance and context. Privacy is a slippery and multifaceted thing with a number of tradeoffs; I'm not sure that discussion should be in this doc, but it probably should be if advice like this is given in the repository, as any such advice here might be seen as a reference.
Also, some of the thoughts here may also pertain to other privacy networks, e.g. I2P and perhaps others at some point like CJDNS. Should there be privacy recommendations in each doc, or rather in one place (doc/privacy.md?) that interrelates between the networks.
IMO the statement as it is, and placed where it is, lacks nuance and context
Agree
I'm not sure that discussion should be in this doc
as any such advice here might be seen as a reference
They should be used as reference. I had two options when I started researching about these things:
I think 2 works better.
Example: Deleting onion_private_key is mentioned on multiple websites: Bitcoin Wiki, Bisq Wiki etc. Editing every wiki, commenting on each social media post, etc. will take lot of time and people will still believe what they read in docs and not me.
Should there be privacy recommendations in each doc, or rather in one place (doc/privacy.md?) that interrelates between the networks.
I think i2p and Tor have few similarities and differences. It's better we have separate docs and maintain privacy recommendations separately but have no issues with doc/privacy.md suggestion. I have added few things in a different repository used by lot of people to learn Bitcoin from command line:
Differences: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/15_0_Using_i2p.md
Trade-offs: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/15_1_i2p_service.md
235 | + 236 | +- Trade-offs involved in using `onlynet=onion`: 237 | + 238 | + The `onlynet=onion` configuration option can potentially ensure the node attempts to only 239 | + connect over Tor. It is more private when you combine it with no reachable IPv4/IPv6 address, 240 | + in particular if you want to broadcast transactions without them being correlatable with your IP.
This is bad advice. Tor is a centralised network, and using it as your only network puts the user at risk for no benefit. It isn't more private, as it doesn't do anything to stop the "cookies" (UTXO/address relationships) Bitcoin wallets need to work.
I think 'more private' here is a comparison between onlynet=onion and onlynet=onion + bind=onion. This was suggested by @sipa in #21157 (review)
I relate to Luke's feedback and am a bit uncomfortable with the lines of advice he points out; maybe they could use more nuance and context. Otherwise, they seem likely to be misinterpreted or followed somewhat blindly.
maybe they could use more nuance and context
Agree