Bitcoin Core finds no addresses to connect

[BlackHatCoiner]

Bitcoin Client Software and Version Number: Bitcoin Core 230000 (23.0).
Operating System: Linux raspibolt 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux.
System Hardware Specs: 3.7 Gi total memory (929 Mi used, 122 Mi free, 2.7 Gi buff/cache, 2.7 Gi available), 1 TB external HDD (153 GB left available).
Description of Problem: My node finds no addresses to connect. I have tried removing peers.dat and restarting bitcoin daemon. I have also tried restarting the computer. I have confirmed it has Internet connection, and it does initiate connection with the DNS seeds. It simply finds 0 addresses. I have tried adding a node with addnode, but it remains at 0 incoming and outgoing.
Log Files from the Bitcoin Client:

Code:

$ tail -f /home/bitcoin/.bitcoin/debug.log
2024-01-13T11:04:50Z init message: Starting network threads…
2024-01-13T11:04:50Z net thread start
2024-01-13T11:04:50Z dnsseed thread start
2024-01-13T11:04:50Z addcon thread start
2024-01-13T11:04:50Z Waiting 300 seconds before querying DNS seeds.
2024-01-13T11:04:50Z opencon thread start
2024-01-13T11:04:50Z msghand thread start
2024-01-13T11:04:50Z tor: Got service ID <deducted>, advertising service <deducted>.onion:8333
2024-01-13T11:04:50Z AddLocal(<deducted>.onion:8333,4)
2024-01-13T11:04:50Z init message: Done loading
2024-01-13T11:07:15Z Imported mempool transactions from disk: 278 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast
2024-01-13T11:07:15Z loadblk thread exit
2024-01-13T11:09:50Z Loading addresses from DNS seed seed.bitcoin.wiz.biz.
2024-01-13T11:09:50Z Loading addresses from DNS seed seed.btc.petertodd.org.
2024-01-13T11:09:50Z Loading addresses from DNS seed seed.bitcoin.sipa.be.
2024-01-13T11:09:50Z Waiting 300 seconds before querying DNS seeds.
2024-01-13T11:14:50Z Loading addresses from DNS seed seed.bitcoin.sprovoost.nl.
2024-01-13T11:14:50Z Loading addresses from DNS seed seed.bitcoin.jonasschnelli.ch.
2024-01-13T11:14:50Z Loading addresses from DNS seed dnsseed.emzy.de.
2024-01-13T11:14:50Z Waiting 300 seconds before querying DNS seeds.
2024-01-13T11:19:50Z Loading addresses from DNS seed seed.bitcoinstats.com.
2024-01-13T11:19:50Z Loading addresses from DNS seed dnsseed.bitcoin.dashjr.org.
2024-01-13T11:19:50Z Loading addresses from DNS seed dnsseed.bluematt.me.
2024-01-13T11:19:50Z 0 addresses found from DNS seeds
2024-01-13T11:19:50Z dnsseed thread exit

[1715033736]

1715033736

[1715033736]

1715033736

[1715033736]

1715033736

[1715033736]

1715033736

[1715033736]

1715033736

[o_e_l_e_o]

Have you checked that your Tor daemon is running properly? You can use the -debug=tor argument to log additional info regarding your Tor set up.

Any new antivirus or firewall software or updates which could be blocking ports, etc?

[DaveF]

In addition to the PC itself did anything upsteam i.e. your internet connection / firewall there.
Have you rebooted that equipment.

Probably as o_e_l_e_o said something TOR related, but you never know if something past the PC itself could be causing issues.

-Dave

[achow101]

It looks like the DNS server you are using isn't returning any responses for the DNS seeds. Have you specified any particular DNS server? What response do you get if you get DNS records from the DNS seeds with dig?

[BlackHatCoiner]

Hm. Weird. I added debug=tor to the configuration file, rebooted the device, and it now works. Tor runs fine, Bitcoin Core is syncing. I literally did not change anything else, and that's the bad part, because I don't know what was the fault so I can fix it in the future. (The debug.log didn't show any errors, but I can share it if you insist)

Any new antivirus or firewall software or updates which could be blocking ports, etc?

No, nothing. I had followed Raspibolt's installation tutorial quite a long time ago. No software blocks port 8333.

It looks like the DNS server you are using isn't returning any responses for the DNS seeds. Have you specified any particular DNS server? What response do you get if you get DNS records from the DNS seeds with dig?

Oh, I must have screwed it up with DNS. Not entirely sure, but I think I had changed something around that last year. Here's dig's output:

Code:

$ dig

; <<>> DiG 9.16.42-Debian <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56056
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: 3bce0aa3567b5d1249fe618865a2decae8ab20eb1454add7 (good)
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			440064	IN	NS	i.root-servers.net.
.			440064	IN	NS	m.root-servers.net.
.			440064	IN	NS	a.root-servers.net.
.			440064	IN	NS	d.root-servers.net.
.			440064	IN	NS	f.root-servers.net.
.			440064	IN	NS	c.root-servers.net.
.			440064	IN	NS	l.root-servers.net.
.			440064	IN	NS	j.root-servers.net.
.			440064	IN	NS	k.root-servers.net.
.			440064	IN	NS	h.root-servers.net.
.			440064	IN	NS	e.root-servers.net.
.			440064	IN	NS	g.root-servers.net.
.			440064	IN	NS	b.root-servers.net.

;; Query time: 11 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Sat Jan 13 21:04:42 EET 2024
;; MSG SIZE  rcvd: 267

Edit: Just stopped again:

Code:

2024-01-13T19:37:11Z UpdateTip: new best=0000000000000000000240f175b8c1d2be32786af8fcad523989f39733c8ec91 height=825246 version=0x20400000 log2_work=94.658582 tx=950438404 date='2024-01-11T05:27:27Z' progress=0.999320 cache=217.7MiB(1461058txo)
2024-01-13T20:08:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 1890 seconds ago)
2024-01-13T20:19:11Z Potential stale tip detected, will try using extra outbound peer (last tip update: 2520 seconds ago)
2024-01-13T20:29:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3150 seconds ago)
2024-01-13T20:40:11Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3780 seconds ago)
2024-01-13T20:50:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 4410 seconds ago)

Code:

$ bitcoin-cli -getinfo
Chain: main
Blocks: 825246
Headers: 825666
Verification progress: 99.9304%
Difficulty: 73197634206448.34

Network: in 0, out 0, total 0
Version: 230000
Time offset (s): -1
Proxies: 127.0.0.1:9050 (ipv4, ipv6, onion, cjdns)
Min tx relay fee rate (BTC/kvB): 0.00001000

[achow101]

Here's dig's output:

dig for a particular domain is more interesting, e.g. dig seed.bitcoin.sipa.be

Edit: Just stopped again:

Code:

2024-01-13T19:37:11Z UpdateTip: new best=0000000000000000000240f175b8c1d2be32786af8fcad523989f39733c8ec91 height=825246 version=0x20400000 log2_work=94.658582 tx=950438404 date='2024-01-11T05:27:27Z' progress=0.999320 cache=217.7MiB(1461058txo)
2024-01-13T20:08:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 1890 seconds ago)
2024-01-13T20:19:11Z Potential stale tip detected, will try using extra outbound peer (last tip update: 2520 seconds ago)
2024-01-13T20:29:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3150 seconds ago)
2024-01-13T20:40:11Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3780 seconds ago)
2024-01-13T20:50:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 4410 seconds ago)

There were some improvements made to stalling detection behavior made in the last year. Can you try using 25.1 or 26.0?

[BlackHatCoiner]

dig for a particular domain is more interesting, e.g. dig seed.bitcoin.sipa.be

Here you go:

Code:

$ dig seed.bitcoin.sipa.be

; <<>> DiG 9.16.42-Debian <<>> seed.bitcoin.sipa.be
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61590
;; flags: qr rd ra; QUERY: 1, ANSWER: 25, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: 0af475c1f0939a11a87af7a465a31ae45af798cbd8c77e88 (good)
;; QUESTION SECTION:
;seed.bitcoin.sipa.be.		IN	A

;; ANSWER SECTION:
seed.bitcoin.sipa.be.	2425	IN	A	217.155.244.170
seed.bitcoin.sipa.be.	2425	IN	A	192.222.24.54
seed.bitcoin.sipa.be.	2425	IN	A	206.123.132.176
seed.bitcoin.sipa.be.	2425	IN	A	78.21.167.8
seed.bitcoin.sipa.be.	2425	IN	A	20.229.118.67
seed.bitcoin.sipa.be.	2425	IN	A	174.61.110.113
seed.bitcoin.sipa.be.	2425	IN	A	3.26.208.206
seed.bitcoin.sipa.be.	2425	IN	A	95.67.18.102
seed.bitcoin.sipa.be.	2425	IN	A	81.217.238.213
seed.bitcoin.sipa.be.	2425	IN	A	143.110.147.13
seed.bitcoin.sipa.be.	2425	IN	A	188.195.140.16
seed.bitcoin.sipa.be.	2425	IN	A	95.216.242.49
seed.bitcoin.sipa.be.	2425	IN	A	82.124.202.187
seed.bitcoin.sipa.be.	2425	IN	A	158.129.140.201
seed.bitcoin.sipa.be.	2425	IN	A	18.222.180.86
seed.bitcoin.sipa.be.	2425	IN	A	35.199.123.23
seed.bitcoin.sipa.be.	2425	IN	A	178.21.118.178
seed.bitcoin.sipa.be.	2425	IN	A	46.188.30.118
seed.bitcoin.sipa.be.	2425	IN	A	189.114.207.217
seed.bitcoin.sipa.be.	2425	IN	A	18.222.209.13
seed.bitcoin.sipa.be.	2425	IN	A	90.105.246.85
seed.bitcoin.sipa.be.	2425	IN	A	35.170.55.36
seed.bitcoin.sipa.be.	2425	IN	A	192.228.178.14
seed.bitcoin.sipa.be.	2425	IN	A	18.224.59.88
seed.bitcoin.sipa.be.	2425	IN	A	187.189.153.130

;; Query time: 11 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Sun Jan 14 01:21:08 EET 2024
;; MSG SIZE  rcvd: 477

There were some improvements made to stalling detection behavior made in the last year. Can you try using 25.1 or 26.0?

I just upgraded to 26.0. For about 10 minutes now, it has stuck at "initload thread exit":

Code:

$ sudo tail -f /home/bitcoin/.bitcoin/debug.log
2024-01-13T23:12:58Z opencon thread start
2024-01-13T23:12:58Z msghand thread start
2024-01-13T23:12:58Z [tor] Get SOCKS port command yielded 127.0.0.1:9050
2024-01-13T23:12:58Z [tor] Configuring onion proxy for 127.0.0.1:9050
2024-01-13T23:12:58Z [tor] ADD_ONION successful
2024-01-13T23:12:58Z [tor] Got service ID ujfmpotoyn22gnppdqbkhaulxcx5nvbkur3ymtmkibgxf3uoziqz4jyd, advertising service ujfmpotoyn22gnppdqbkhaulxcx5nvbkur3ymtmkibgxf3uoziqz4jyd.onion:8333
2024-01-13T23:12:58Z [tor] Cached service private key to /home/bitcoin/.bitcoin/onion_v3_private_key
2024-01-13T23:12:58Z AddLocal(ujfmpotoyn22gnppdqbkhaulxcx5nvbkur3ymtmkibgxf3uoziqz4jyd.onion:8333,4)
2024-01-13T23:14:04Z Imported mempool transactions from disk: 245 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast
2024-01-13T23:14:04Z initload thread exit

I searched the Internet for "stale tip detected" and no stackexchange posts dive into the detail of what's this all about. Can someone explain me what's the problem? First time reading about "stalling detection".

(I revealed the onion address, in case you want to diagnose it from your end)

[achow101]

So DNS is probably working, but it seems like it isn't actually able to connect to anything.

Are you able to reach other tor hidden services with that machine? I've also tried to connect to your node from mine but it is unable to reach it.

[BlackHatCoiner]

The error still persists.

Are you able to reach other tor hidden services with that machine? I've also tried to connect to your node from mine but it is unable to reach it.

No, and that's probably the problem. SOCKS5 doesn't seem to respond as expected:

Code:

$ torsocks curl -v http://duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
*   Trying 127.42.42.0:80...
1705223279 ERROR torsocks[39067]: Connection timed out (in socks5_recv_connect_reply() at socks5.c:547)
* Immediate connect fail for 127.42.42.0: Connection timed out
* Closing connection 0
curl: (7) Couldn't connect to server

It fails parsing the response:

Code:

$ tor-resolve duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
Jan 14 11:02:26.111 [err] Failed parsing SOCKS5 response

My /etc/tor/torrc does include "SocksPort 9050". I have lots of information in tor/debug.log and tor/notices.log, but I doubt they are helpful. Here's the last few lines from notices.log: https://pastebin.com/raw/iW4Ciewn.

[apogio]

Usually the answer is simpler than it looks like. If you followed step by step Raspibolt's instructions, you shouldn't have these issues.

I tried connecting to your node and it didn't work, so let's try to find what the differences are between raspibolt's instructions and your node. The answer must be there.

Is your node onlynet=onion?

[BlackHatCoiner]

Usually the answer is simpler than it looks like. If you followed step by step Raspibolt's instructions, you shouldn't have these issues.

It's been a while since I followed Raspibolt instructions, but I'm sure it isn't exactly Raspibolt. I was experimenting myself at some point.

Is your node onlynet=onion?

Yes. Here's my bitcoin.conf:

Code:

# RaspiBolt: bitcoind configuration
# /home/bitcoin/.bitcoin/bitcoin.conf

# Bitcoin daemon
server=1
txindex=1
debug=tor

# Network
listen=1
listenonion=1
onlynet=onion
proxy=127.0.0.1:9050
#bind=127.0.0.1

# Connections
rpcauth=<deducted>
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
whitelist=download@127.0.0.1          # for Electrs
whitelist=bloomfilter@192.168.0.0/16   # for Bisq


# Raspberry Pi optimizations
maxconnections=40
maxuploadtarget=5000

# Initial block download optimizations
#dbcache=2000
blocksonly=0

# filters
peerbloomfilters=1
pruned=0

You can verify yourself that this isn't copied-pasted from Raspibolt. For example, Raspibolt does bind to 127.0.0.1. I remember I had commented that, because it was producing issues with Bisq.  

[apogio]

You can verify yourself that this isn't copied-pasted from Raspibolt. For example, Raspibolt does bind to 127.0.0.1. I remember I had commented that, because it was producing issues with Bisq.  

Correct, I have removed this line too.

Yes. Here's my bitcoin.conf:

The differences with mine are:

1. I don't use onlynet=onion
2. I use v2transport=1
3. I use rpcbind and rpcallowip as explained in this tutorial: https://sparrowwallet.com/docs/connect-node.html

Could it be firewall rules? I use ufw. Is your 8333 port opened? I see you say nothing blocks it, but can you verify using sudo ufw status?

Can you please run bitcoin-cli getconnectioncount and then bitcoin-cli getpeerinfo?

[BlackHatCoiner]

Could it be firewall rules?

Doesn't seem to be the case:

Code:

$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
<deducted>
8333/tcp (v6)              ALLOW       Anywhere (v6)              # allow Bitcoin Core

Can you please run bitcoin-cli getconnectioncount and then bitcoin-cli getpeerinfo?

Code:

$ bitcoin-cli getconnectioncount
0
$ bitcoin-cli getpeerinfo
[
]

[apogio]

Does bitcoin-cli getnetworkinfo show you are reachable by the onion network?

Do you want to try if we can explicitly add a node via the addnode command?

Are these options uncommented in your /etc/tor/torrc file?

Code:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

Can you run sudo ss -tulpn | grep tor | grep LISTEN to see if the tor service is listening at the ports 9050, 9051?

[BlackHatCoiner]

Does bitcoin-cli getnetworkinfo show you are reachable by the onion network?

For some strange reason, right now I'm having 8 connections (1 in, 7 out). The networkactive boolean is set to true. However, I bet I'll be back at 0 connections within the hour.

Do you want to try if we can explicitly add a node via the addnode command?

As I have already said, I have tried but it didn't work. You can try to add me as a node, or tell me your URI so I can add you, but I doubt this will help. The problem isn't in DNS. As it appears out, it fails parsing SOCKS5 responses. With onionnet=onion, this means complete connection failure. Although, tor-resolve fails even now that I do have connections, so I don't cross my fingers it's entirely its fault either.

Are these options uncommented in your /etc/tor/torrc file?

No.

Can you run sudo ss -tulpn | grep tor | grep LISTEN to see if the tor service is listening at the ports 9050, 9051?

Code:

$ sudo ss -tulpn | grep tor | grep LISTEN 
tcp   LISTEN 1      4096       127.0.0.1:9050       0.0.0.0:*    users:(("tor",pid=39059,fd=6))                                                                                                      
tcp   LISTEN 0      4096       127.0.0.1:9051       0.0.0.0:*    users:(("tor",pid=39059,fd=7))

[apogio]

Code:

$ sudo ss -tulpn | grep tor | grep LISTEN 
tcp   LISTEN 1      4096       127.0.0.1:9050       0.0.0.0:*    users:(("tor",pid=39059,fd=6))                                                                                                      
tcp   LISTEN 0      4096       127.0.0.1:9051       0.0.0.0:*    users:(("tor",pid=39059,fd=7))

for me the output looks like this:

Code:

tcp   LISTEN 0      4096                    127.0.0.1:9050       0.0.0.0:*    users:(("tor",pid=23066,fd=6))
tcp   LISTEN 0      4096                    127.0.0.1:9051       0.0.0.0:*    users:(("tor",pid=23066,fd=7))

The "1" in port 9050 means that there is 1 byte on the Recv-Q (receiving queue) waiting to be read.

It's a rather curious number to be honest. Is it constantly "1" or have you noticed it going higher?

I suggest you run sudo ss -tulpn to see all the ports. Are there any other ports that have Recv-Q higher than 0? Perhaps port 8333?

[BlackHatCoiner]

The "1" in port 9050 means that there is 1 byte on the Recv-Q (receiving queue) waiting to be read.

Now it's "0".

It's a rather curious number to be honest. Is it constantly "1" or have you noticed it going higher?

I haven't noticed it at all.

Are there any other ports that have Recv-Q higher than 0?

No.

Currently, I'm at 12 connections (2 in, 10 out) and strangely have reached the tip. The problem has solved itself, but the mystery remains unsolved.

[Cricktor]

Are these options uncommented in your /etc/tor/torrc file?

No.

My /etc/tor/torrc has the following uncommented lines:

Code:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1
ExitPolicy reject *:*

My bitcoin.conf limits connections outside of my local network to Tor-only (showing only relevant lines):

Code:

listenonion=1
proxy=127.0.0.1:9050
bind=127.0.0.1  # no issues for me with Bisq
onlynet=onion

port=8333
rpcport=8332
rpcbind=127.0.0.1
rpcallowip=127.0.0.1

Number of connections for me is currently:
~$ bitcoin-cli getconnectioncount
40