Using Bitcoin Client Software: Bitcoin Core version 230000 (23.0).
OS running: Linux raspibolt 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux.
System Specs: 3.7 Gi total RAM (929 Mi used, 122 Mi free, 2.7 Gi buff/cache, 2.7 Gi available), 1 TB external HDD (153 GB available).
Here's the issue: My node isn't able to find any addresses to connect to. I've already tried deleting peers.dat and restarting the bitcoin daemon. Also rebooted my computer. Internet is working, and it starts connecting with the DNS seeds, but still shows 0 addresses. I even attempted to add a node using addnode, but it just stays at 0 for both incoming and outgoing connections.
Here are the log files from the Bitcoin client:
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?
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
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?
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)
No, nothing. I had followed Raspibolt's installation tutorial quite a long time ago. No software blocks port 8333.
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:
Edit: Just stopped again:
dig for a particular domain is more interesting, e.g. dig seed.bitcoin.sipa.be
There were some improvements made to stalling detection behavior made in the last year. Can you try using 25.1 or 26.0?
Here you go:
I just upgraded to 26.0. For about 10 minutes now, it has stuck at "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)
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.
The error still persists.
No, and that's probably the problem. SOCKS5 doesn't seem to respond as expected:
It fails parsing the 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.
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?
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.
Yes. Here's my bitcoin.conf:
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.
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?
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?
Can you run sudo ss -tulpn | grep tor | grep LISTEN to see if the tor service is listening at the ports 9050, 9051?
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.
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.
No.
for me the output looks like this:
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?
Now it's "0".
I haven't noticed it at all.
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.
My /etc/tor/torrc has the following uncommented lines:
My bitcoin.conf limits connections outside of my local network to Tor-only (showing only relevant lines):
Number of connections for me is currently:
~$ bitcoin-cli getconnectioncount
40