I just got myself a 5TB external HDD and finished transferring the blockchain and my torrents onto it. It's pretty handy, but I've got a big issue.
I can't forward port 8333 on my router, plus I'm using a VPN anyway, so that makes it pretty useless. So, I'm trying to set up a Tor hidden service to let incoming connections hit my node.
I checked out the guide on bitcoin.it for setting up a node over Tor on Linux, and everything seems good. I even asked AI to help me tweak my bitcoin.conf and ended up with this:
But after running my node for about 30 minutes, I see only one inbound Onion connection in my peer window on Qt, and a few others pop in and out quickly.
I'm curious if there's anything I can change in my config to help me contribute more to the network.
Need assistance with bitcoin.conf Aiming to support the network via Tor
7 replies 300 views
yield_forkFull Member
Posts: 162 · Reputation: 728
#2Sep 10, 2019, 04:43 PM
Hi, I'm not on Linux right now, I could show you my bitcoin.conf, which is configured to run over Tor, but it seems to be fine as it is. Usually, incoming connections take a long time to connect to your node, don't worry.
Check out this guide with more complete instructions: https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md
Alright, I did some more waiting and I now have 3 inbound onion connections. Awesome.
I'll keep the topic open in case any Bitcoin Core savants want to add anything.
I reckon I'm delighted with my current setup, I'm using a Cold Card hardware wallet with Bitcoin Core's PSBT controls, for a fully air-gapped setup, with my own full node routed through Tor, helping the network 24/7.
There's no problem with this configuration, but
1. maxconnections=125, maxuploadtarget=0, maxmempool=300 and blocksonly=0 actually are the default value used by Bitcoin Core. So adding those have no impact.
2. maxconnections actually only set maximum total connection (both incoming and outgoing), where Bitcoin Core already make up to 10 outbound/outgoing connection by default.
3. AFAIK txindex=1 doesn't help Bitcoin network or other node in any way.
Both Tor and Bitcoin Core already have good default configuration. So if you already receive incoming connection, realistically you only could wait until you receive more incoming connection.
Few member may mention that manually connect to well-connected node (using addnode=NODE_IP_OR_ONION) may help you receive more incoming connection faster. But i don't know whether it actually works.
yield_forkFull Member
Posts: 162 · Reputation: 728
#5Sep 13, 2019, 06:39 AM
When my node takes a long time to receive incoming connections, I add some onion network nodes manually by this command by getting the address from bitnodes, and after a while, I can see that the .onion address has indeed been added to the connections list.
As I want my node to only communicate via Tor with other nodes, I have the following differences in my bitcoin.conf:
I use a larger mempool and have my node save its current state before shutting down; full RBF enabled:
And I like to keep the history of my debug.log:
gr3g.0rbitHero Member
Posts: 1025 · Reputation: 2646
#7Sep 14, 2019, 04:40 AM
This is a bit late but since you're still open for suggestions on how to contribute even more:
You may consider adding peerblockfilters=1 and its requirement blockfilterindex=1 to your config.
That'll enable your node to serve some light clients that implemented BIP157 and BIP158.
Heads-up; once enabled, your node will have to create a separate blockfilterindex just like your txindex, but smaller in size.
And your node may gain a lot of light-client peers than full nodes depending on various conditions.
nick.wizardMember
Posts: 2 · Reputation: 124
#8Sep 16, 2019, 09:10 AM
Newly created onion addresses take time to propagate across the network. This is why your node receives few incoming onion connections.
The longer your node stays online, the more other nodes will receive your onion address in their list of already connected addresses. Within a few months, your node will be able to receive many more incoming connections much more quickly.
?Reply
Sign in to reply to this topic
Related topics
- Protecting a Bitcoin node from TOR / Eclipse attacks 13
- Are outgoing connections to clearnet peers via Tor really less secure? 5
- Bitcoin and Monero Privacy in a Dystopian World 19
- Is it possible to trace Coinjoin transactions? Debunking Bitcoin privacy misconceptions 19
- US offers $625,000 for tracking Bitcoin, Monero, and Lightning users 19
- Got a warning about Tor 7