Difficulty finding peers

[wild-kard]

Hey really appreciate all the work you've done on this process. I've followed your guide for getting bitcoin core installed on tails and I can't seem to find any peers. Any ideas why that Could be?

I have a stable tor connection (can use tor browser) and setup a bitcoin.conf as outlined in the guide.

[PulpCattel]

Hey there, I'm glad this guide is still helpful. As you probably have noticed, I don't have time to regularly update it. Nonetheless, the general concepts should still be applicable (minus Wasabi 2.0, which is known to be incompatible with Tails).

Back to your issue (I will assume you are using the latest Bitcoin Core version, 23.0).

If you are using a bitcoin.conf file like this:

prune=10000
proxy=127.0.0.1:9050
onlynet=onion

Then it should work. If instead you are using a conf like this:

prune=10000
proxy=127.0.0.1:9050
onlynet=onion
dns=0
dnsseed=0

The first time you run it your nodes may have trouble finding peers, this is because we are preventing DNS queries (which are used to discover peers when we know none).

You have various options (the first one is probably the best but they should be more or less equivalent):

• If you have another node of yours (or a friend's node, etc.), e.g., on another machine, you can add it to the conf, seednode=ADDRESS.onion (see bitcoind --help for more info about seednode). Your Tails node will connect to it and get peers from it. Once you have peers you can then remove this node from your conf file.
• Instead of your node, you can add a .onion node from e.g., https://bitnodes.io, pick one with good uptime or that you like for whatever reason. Once you have peers you can then remove this node from your conf file. If you want to be safer, since you probably don't trust this node, you can pick multiple of them (as many as you want), just add more seednode= until you feel comfortable.
• You can start the first time without dns=0 and dnsseed=0 (in particular, dnsseed should be the one that matters), and after it finds a few peers you can add them back.

If nothing solves it, then this would appear to be a network problem. But we'll cross that bridge if we get there.

[wild-kard]

This all makes sense. I have tried running core without the dns=0 and dnsseed=0 options. I have also tried seeding a couple of peers from bitnodes,

However, it seems I am still not connecting to any peers.

[PulpCattel]

Okay, so you have said you can user tor browser from Tails, so your network and Tor itself seem to be working.

A few ideas:

• Make sure you are using one of the latest Bitcoin Core, previous versions only support V2 onions, and those are deprecated by the Tor Network.
• Make sure you are telling Core to use your data dir in the persistent storage. Check if you have a .bitcoin folder in your Tails /home/user path. If there's then Core is not using your bitcoin.conf file.
• Check Core logs, you should find a debug.log file in your bitcoin data dir. See if there's anything interesting there, should be decently human readable.
• proxy=127.0.0.1:9050 should be the only setting required to be able to connect, try to run with only that in your config (and prune of course if needed), and see if that helps.
• Tails includes a program that should be called onion circuits, which shows all the Tor circuits. You can check if when you run Bitcoin Core some attempts to create a connection are made there. This could for example show you that the seeding peers are offline and unreachable.

[wild-kard]

Using the latest version of bitcoin core.

My bitcoin.conf seems to be in the right place and the debug log confirms that it is pulling in the parameters that it should be. I do see some active onion circuits.

Perhaps you can help me parse the debug log?

2022-08-16T14:16:27Z Bitcoin Core version v23.0.0 (release build)
2022-08-16T14:16:27Z InitParameterInteraction: parameter interaction: -proxy set -> setting -listen=0
2022-08-16T14:16:27Z InitParameterInteraction: parameter interaction: -proxy set -> setting -upnp=0
2022-08-16T14:16:27Z InitParameterInteraction: parameter interaction: -proxy set -> setting -natpmp=0
2022-08-16T14:16:27Z InitParameterInteraction: parameter interaction: -proxy set -> setting -discover=0
2022-08-16T14:16:27Z InitParameterInteraction: parameter interaction: -listen=0 -> setting -listenonion=0
2022-08-16T14:16:27Z InitParameterInteraction: parameter interaction: -listen=0 -> setting -i2pacceptincoming=0
2022-08-16T14:16:27Z Qt 5.15.2 (static), plugin=xcb (static)
2022-08-16T14:16:27Z Static plugins:
2022-08-16T14:16:27Z  QXcbIntegrationPlugin, version 331520
2022-08-16T14:16:27Z Style: fusion / QFusionStyle
2022-08-16T14:16:27Z System: Linux 5.10.0-16-amd64, x86_64-little_endian-lp64
2022-08-16T14:16:27Z Screen: eDP 1920x1080, pixel ratio=1.0
2022-08-16T14:16:27Z Assuming ancestors of block 000000000000000000052d314a259755ca65944e68df6b12a067ea8f1f5a7091 have valid signatures.
2022-08-16T14:16:27Z Setting nMinimumChainWork=00000000000000000000000000000000000000002927cdceccbd5209e81e80db
2022-08-16T14:16:27Z Prune configured to target 10000 MiB on disk for block and undo files.
2022-08-16T14:16:27Z Using the 'x86_shani(1way,2way)' SHA256 implementation
2022-08-16T14:16:27Z Using RdSeed as additional entropy source
2022-08-16T14:16:27Z Using RdRand as an additional entropy source
2022-08-16T14:16:29Z Default data directory /root/.bitcoin
2022-08-16T14:16:29Z Using data directory /home/amnesia/Persistent/Bitcoin
2022-08-16T14:16:29Z Config file: /home/amnesia/Persistent/Bitcoin/bitcoin.conf
2022-08-16T14:16:29Z Config file arg: onlynet="onion"
2022-08-16T14:16:29Z Config file arg: proxy="127.0.0.1:9050"
2022-08-16T14:16:29Z Config file arg: prune="10000"
2022-08-16T14:16:29Z Config file arg: seednode="nyodug3rw3vahewnzdvb4g7lh74bhsckr4a352agaizzqtmbigfj3rid.onion:8333"
2022-08-16T14:16:29Z Config file arg: seednode="vsswgjfgvr4psxkxp7mvglyyupzc3pjf37rdvvlqexctmtkmco63q6ad.onion:8333"
2022-08-16T14:16:29Z Using at most 125 automatic connections (1024 file descriptors available)
2022-08-16T14:16:29Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2022-08-16T14:16:29Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2022-08-16T14:16:29Z Script verification uses 3 additional threads
2022-08-16T14:16:29Z scheduler thread start
2022-08-16T14:16:29Z Using wallet directory /home/amnesia/Persistent/Bitcoin
2022-08-16T14:16:29Z init message: Verifying wallet(s)…
2022-08-16T14:16:29Z Using /16 prefix for IP bucketing
2022-08-16T14:16:29Z init message: Loading P2P addresses…
2022-08-16T14:16:29Z Loaded 619 addresses from peers.dat  1ms
2022-08-16T14:16:29Z init message: Loading banlist…
2022-08-16T14:16:29Z SetNetworkActive: true
2022-08-16T14:16:29Z Cache configuration:
2022-08-16T14:16:29Z * Using 2.0 MiB for block index database
2022-08-16T14:16:29Z * Using 8.0 MiB for chain state database
2022-08-16T14:16:29Z * Using 440.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2022-08-16T14:16:29Z init message: Loading block index…
2022-08-16T14:16:29Z Switching active chainstate to Chainstate [ibd] @ height -1 (null)
2022-08-16T14:16:29Z Opening LevelDB in /home/amnesia/Persistent/Bitcoin/blocks/index
2022-08-16T14:16:29Z Opened LevelDB successfully
2022-08-16T14:16:29Z Using obfuscation key for /home/amnesia/Persistent/Bitcoin/blocks/index: 0000000000000000
2022-08-16T14:16:29Z LoadBlockIndexDB: last block file = 0
2022-08-16T14:16:29Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=1, size=293, heights=0...0, time=2009-01-03...2009-01-03)
2022-08-16T14:16:29Z Checking all blk files are present...
2022-08-16T14:16:29Z Opening LevelDB in /home/amnesia/Persistent/Bitcoin/chainstate
2022-08-16T14:16:29Z Opened LevelDB successfully
2022-08-16T14:16:29Z Using obfuscation key for /home/amnesia/Persistent/Bitcoin/chainstate: 319877f5b9b9032a
2022-08-16T14:16:29Z Loaded best chain: hashBestChain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 date=2009-01-03T18:15:05Z progress=0.000000
2022-08-16T14:16:29Z init message: Verifying blocks…
2022-08-16T14:16:29Z  block index              87ms
2022-08-16T14:16:29Z Unsetting NODE_NETWORK on prune mode
2022-08-16T14:16:29Z init message: Pruning blockstore…
2022-08-16T14:16:29Z block tree size = 1
2022-08-16T14:16:29Z nBestHeight = 0
2022-08-16T14:16:29Z loadblk thread start
2022-08-16T14:16:29Z Loaded 0 addresses from "anchors.dat"
2022-08-16T14:16:29Z Imported mempool transactions from disk: 0 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast
2022-08-16T14:16:29Z loadblk thread exit
2022-08-16T14:16:29Z 0 block-relay-only anchors will be tried for connections.
2022-08-16T14:16:29Z init message: Starting network threads…
2022-08-16T14:16:29Z net thread start
2022-08-16T14:16:29Z dnsseed thread start
2022-08-16T14:16:29Z Waiting 11 seconds before querying DNS seeds.
2022-08-16T14:16:29Z opencon thread start
2022-08-16T14:16:29Z init message: Done loading
2022-08-16T14:16:29Z msghand thread start
2022-08-16T14:16:29Z addcon thread start
2022-08-16T14:16:29Z GUI: Platform customization: "other"
2022-08-16T14:16:40Z Loading addresses from DNS seed 
[seed.btc.petertodd.org](http://seed.btc.petertodd.org/)
.
2022-08-16T14:16:40Z Loading addresses from DNS seed 
[seed.bitcoin.sipa.be](http://seed.bitcoin.sipa.be/)
.
2022-08-16T14:16:40Z Loading addresses from DNS seed 
[dnsseed.bitcoin.dashjr.org](http://dnsseed.bitcoin.dashjr.org/)
.
2022-08-16T14:16:40Z Waiting 11 seconds before querying DNS seeds.
2022-08-16T14:16:51Z Loading addresses from DNS seed 
[seed.bitcoin.jonasschnelli.ch](http://seed.bitcoin.jonasschnelli.ch/)
.
2022-08-16T14:16:51Z Loading addresses from DNS seed 
[seed.bitcoin.sprovoost.nl](http://seed.bitcoin.sprovoost.nl/)
.
2022-08-16T14:16:51Z Loading addresses from DNS seed 
[dnsseed.emzy.de](http://dnsseed.emzy.de/)
.
2022-08-16T14:16:51Z Waiting 11 seconds before querying DNS seeds.
2022-08-16T14:17:02Z Loading addresses from DNS seed 
[seed.bitcoin.wiz.biz](http://seed.bitcoin.wiz.biz/)
.
2022-08-16T14:17:02Z Loading addresses from DNS seed 
[dnsseed.bluematt.me](http://dnsseed.bluematt.me/)
.
2022-08-16T14:17:02Z Loading addresses from DNS seed 
[seed.bitcoinstats.com](http://seed.bitcoinstats.com/)
.
2022-08-16T14:17:02Z 0 addresses found from DNS seeds
2022-08-16T14:17:02Z dnsseed thread exit
2022-08-16T14:48:44Z Potential stale tip detected, will try using extra outbound peer (last tip update: 1890 seconds ago)
2022-08-16T14:59:14Z Potential stale tip detected, will try using extra outbound peer (last tip update: 2520 seconds ago)
2022-08-16T15:09:44Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3150 seconds ago)
2022-08-16T15:20:14Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3780 seconds ago)
2022-08-16T15:30:44Z Potential stale tip detected, will try using extra outbound peer (last tip update: 4410 seconds ago)
2022-08-16T15:41:14Z Potential stale tip detected, will try using extra outbound peer (last tip update: 5040 seconds ago)
2022-08-16T15:51:44Z Potential stale tip detected, will try using extra outbound peer (last tip update: 5670 seconds ago)
2022-08-16T16:02:14Z Potential stale tip detected, will try using extra outbound peer (last tip update: 6300 seconds ago)
2022-08-16T16:12:44Z Potential stale tip detected, will try using extra outbound peer (last tip update: 6930 seconds ago)

Could that listenonion=0 parameter have something to do with this issue?

[PulpCattel]

Interesting, yeah it seems it's all good from your side.

2022-08-16T14:17:02Z 0 addresses found from DNS seeds this is not right of course.

Could that listenonion=0 parameter have something to do with this issue?

I don't think so, if you look the output of bitcoind --help, listenonion does not seem related to this issue.

A few other things to try:

• Remove the port from seednode=, seems silly but you can try (docs specifically says <IP> and not <IP:PORT> like it does for e.g., proxy), I honestly don't remember if it matters, but your node is not picking them up for some reason.
• Try without onlynet=onion.
• To have more info you can use the debug setting, tor, net, proxy, addrman for example.

# Output debugging information (default: -nodebug, supplying <category> is
# optional). If <category> is not supplied or if <category> = 1,
# output all debugging information. <category> can be: addrman,
# bench, blockstorage, cmpctblock, coindb, estimatefee, http, i2p,
# ipc, leveldb, libevent, lock, mempool, mempoolrej, net, proxy,
# prune, qt, rand, reindex, rpc, selectcoins, tor, util,
# validation, walletdb, zmq. This option can be specified multiple
# times to output multiple categories.
#debug=<category>

[wild-kard]

I see a message I haven't seen before, it's saying that the proxy failed to connect,

"connect() to 127.0.0.1:9050 failed after wait: connection refused (111)"

After enabling more verbose debug outputs I now see lots of regular connection timeouts from my proxy

[PulpCattel]

"connect() to 127.0.0.1:9050 failed after wait: connection refused (111)"

Yep, this is surely the issue. Have you changed your torrc file or edited Tor in any way? Or perhaps are you using a non-standard Tails User? Just guessing at the moment, at least the Bitcoin Core part seems okay then, I doubt this is a Core problem at this point.

[wild-kard]

I have not, this is a fresh tails install that I setup on my unbuntu machine with a simple wget and dd according to the official tails docs https://tails.boum.org/install/expert/index.en.html

[PulpCattel]

Try: curl --proxy socks5h://127.0.0.1:9050 https://check.torproject.org or similar from command line, to see if Tor proxy works there.

I'll have to try to reproduce it.

[wild-kard]

curl: (7) failed to connect to 127.0.0.1 port 9050: connected refused

[wild-kard]

After running into this problem, I spent the last few days banging my head against the keyboard because TOR completely stopped working, for whatever reason. I could still use the TOR browser just fine, but any CLI operations would give me a socks5 connection refusal.

Today I FINALLY figured out that it was a firewall issue.

Running sudo iptables -I OUTPUT 2 -p tcp -d 127.0.0.1 -m tcp --dport 9050 -j ACCEPT

finally lets me wget again and now with that port finally open I'm connected to peers and syncing headers

I don't know if this is a tails issue, I don't know if tails configures iptables at boot? I don't know why I didn't have this problem the very first time I installed bitcoin core with wget...all I know is that opening up port 9050 on my proxy seems to have fixed the issue.

I have also discovered, that for whatever reason, starting bitcoin core without a bitcoin.conf and navigating to the settings in the GUI and checking the "Connect through SOCS5 proxy" box under the network tab, and restarting the daemon... is seemingly more reliable for connecting through TOR than manually configuring the config file.

[PulpCattel]

@wild-kard Thanks for reporting, sorry I didn't have the time to investigate this further.

So, the good news is that we know it's a firewall issue. The bad news, at least for my guide, is that this solution requires sudo privileges (which needs to be manually selected at boot), requires touching iptables rules, and it must be performed at every boot. Therefore is not a sustainable, nor convenient, nor safe solution.

I don't know if tails configures iptables at boot?

Yes it does, and it's relatively strict but AFAIK 127.0.0.1:9050 has always been reachable.

I don't know why I didn't have this problem the very first time I installed bitcoin core with wget

This gives me a little hope, if you can confirm this, then there's a chance it is something you have done and not a Tails problem or new quirk. The weird thing is that a restart should reset it, unless you have saved in the persistent storage some configuration files, or messed up with Tails internal stuff (which seems unlikely).

is seemingly more reliable for connecting through TOR than manually configuring the config file.

What do you mean "more reliable"? I'd discourage to use Core without configuration file, but I guess it should work the same as long as you only use the GUI, I think.

I'll try soon to reproduce.

[wild-kard]

I tried debugging on two different computers, with two different usb sticks and on two different networks with two different ISPs. I tried completely fresh tails installs multiple times and continuously ran into the socks5 connection error. It was only the very first time I set up tails that I was able to wget from the terminal without issue.

I was not able to get socks5 to connect at the CLI (outside of the very first time I downloaded core) until I changed the iptables.

As for syncing core...I've found that creating my .conf and starting core, I still cannot find peers, and I have the same issues that we were originally trying to tackle earlier this week. However, if I start core without the config file and navigate to the gui settings and enable socks5 I am able to start finding peers immediately and syncing.

I do not know why this is.

[wild-kard]

What are the security implications of configuring the iptables? I understand it requires root but you can atleast make root persistent if you choose.

AFAIK no one else can access your 127s except for you.

[PulpCattel]

One thing to notice is that I'm specifically talking in the context of this guide, which targets average users and it's expected to be convenient and safe.

What are the security implications of configuring the iptables?

It's something that it is easy to mess up (e.g., extreme but clear, you put the wrong letter in the command and you wipe out your iptables rules without noticing. It would be restored at next boot, but still is terrible), and it touches a very security-focus part, the firewall. As a power user it can be okay (one other much more technical guide of mine does indeed configure iptables, https://github.com/PulpCattel/JoinMarket-On-Tails).

I understand it requires root but you can at least make root persistent if you choose.

Again, as a power user it is your choice, but for the purpose of this guide setting root by default is terrible. With admin privileges it's much easier to shoot yourself in the foot, potentially irreversibly. It also increases the attack surface. You can find online much better sources than me to read about this.

AFAIK no one else can access your 127s except for you.

I guess a compromised app, or some javascript in your browser, may be able to play with localhost, but I wasn't referring to the specific IP:PORT opened, rather the general concept.

So TL;DR is something like: I wouldn't recommend it, but it's clearly doable as long as you are okay with the trade-off.

[wild-kard]

I see what you mean about the iptables. Alternatively I think you could use startup parameters instead of a configuration file.

Adding -proxy=127.0.0.1:9050 for example I believe is the same as ticking the options in the gui.

[PulpCattel]

Adding -proxy=127.0.0.1:9050 for example I believe is the same as ticking the options in the gui.

I think so too, though I'm not sure how the interaction with the GUI settings works. BTW, this is why earlier I mentioned to use bitcoind --help, the config file mimic the same options you have from command line. So proxy=127.0.0.1:9050 in bitcoin.conf is the same as the -proxy option. And the same is true for prune, dnsseed, etc.

Generally speaking, the config file is almost always better. You can set it once and forget about it, you never risk to miss an option, and you don't need to type or copy/paste long commands.