pull down to refresh
Yup, running
onlynet=onion and onetry vs add - I don't want to waste time trying to reconnect a million times given the attrition I'm seeing.f your node is listening (accepting inbound connections), then you will likely get more than 10 total, but it depends on how well your .onion address is propagated into other peers' databases and the overall demand for Tor peers.
This is the heart of it, I guess - the drastic difference between how this works in practice w/ Tor nodes vs clearnet ones. It surprises me given that I suspect the Tor nodes are running on out-of-the-box nodes like MyNode, etc., that are long-lived, so the high rate of attrition is surprising.
But like I said, my surprise could just be because I'm an idiot. So far it sounds like my experience is not perplexing to people who are also doing this, so the evidence for my idiocy is increasing.
reply
difference between how this works in practice w/ Tor nodes vs clearnet ones.
The only difference should be that there are more clearnet nodes and thus more demand for nodes that accept clearnet connections.
For example, my node has 112 inbound connections (has accepted 112 connections from others) from which 11 are from Tor nodes.
bitcoin-cli getpeerinfo | jq 'map(select(.inbound)) | length' bitcoin-cli getpeerinfo | jq 'map(select(.inbound and .network == "onion")) | length'
A note about running with
-onlynet=onion - this way the node is more likely to fall victim of a sybil attack - because it is cheap to create .onion addresses somebody may create a lot of them and the victim's node to make all 10 outbound connection to the attacker. To avoid sybil just one connection to a honest node suffices. Now, unless there is a very specific reason for -onlynet=onion you may configure Bitcoin Core to connect also to clearnet peers via the Tor network. This will protect your nodes' whereabouts and will use the Tor exit nodes to connect to clearnet nodes. To sybil that one would need to control Tor exit nodes as well, or a lot of clearnet nodes.reply
Yup, understood wrt Tor / sybil.
My goal is to leak no IP info, so I'm starting w/ Tor-only. @ek was giving me a lot of help wrt using Core w/ a VPN, but I haven't yet come back to that one. In a pinch I know I can use the VPN and not care about port forwarding, but I've got a rock in my shoe about solving it the 'right' way.
reply
You might as well run with
-proxy=127.0.0.1:9050 (assuming this is where your Tor SOCKS5 proxy is listening) and omit the -onlynet=onion option. Then Bitcoin Core will be able to connect to IPv4, IPv6 and Tor peers, all via the Tor network, so the IPv4/6 peers pose no threat to revealing your IP address. This actually uses the entire Tor network as one big VPN with multiple exit points (the Tor exit nodes), also used by many others with the added benefit of being able to connect to .onion addresses without exiting the "VPN" ;)reply
Oh great, that sounds like it gets me everything I want. Have made the change and re-started. Thanks :)
reply
-onlynet=onion, right? If so, then all 10 of the outbound connections will be made to Tor peers. Here is a an example command to see your connections:.onionaddress is propagated into other peers' databases and the overall demand for Tor peers..onionaddresses are in a node's address database:bitcoin-cli addnode ...onion:8333 addorbitcoin-cli addnode ...onion:8333 onetry? I guess what you are observing is that you are adding manually outbound peers and then over time some of those connections are dropped which is normal and are not reestablished.