Running Bitcoin core node without Tor.

[bittyuser]

Hello new to the forum but not to bitcoin.

Setup my bitcoin node using the raspibolt guide (https://raspibolt.org/guide/raspberry-pi/) . Apparently it is taking so long to download. Now the verification progress is at 0.4. I was thinking the slow download is due to running thru TOR.

I am running the node on a Raspberry Pi 4B which is the 4gig ram version. I am running Pi Hole along with the node.

Anyway to speed up the download?

The idea is to run the node and setup my private electrum server so that I could use it with sparrow desktop wallet.

Also please share what's the best practice when running a node?

[BlackHatCoiner]

Hey, there. I'm running a Raspibolt node.

Tor is very rarely the problem with slow syncing. It's either failing to find peers, or there is lack of memory. But before that, is your external drive an HDD? If that's so, then expect slow syncing. When I finished syncing a couple of years ago, I think it had taken me around 2 weeks, because of that. So, maybe you should shut down everything, move your blocks and chainstate in an SSD, let it sync there, and then move these directories back to your HDD drive. 

[Accardo]

Hey, there. I'm running a Raspibolt node.

Tor is very rarely the problem with slow syncing. It's either failing to find peers, or there is lack of memory. But before that, is your external drive an HDD? If that's so, then expect slow syncing. When I finished syncing a couple of years ago, I think it had taken me around 2 weeks, because of that. So, maybe you should shut down everything, move your blocks and chainstate in an SSD, let it sync there, and then move these directories back to your HDD drive. 

In addition, the HDD can contain a symbolic link that'll be pointing at the location where the blocks and chainstate are stored in an SSD, and the system will run on the link as though it's the main directory. Symbolic link can be created with Mklink command using command prompt, and it's preferable to run it as admin. This link would be helpful https://www.howtogeek.com/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/

Also a thread where such a problem was discussed and solved https://bitcointalk.org/index.php?topic=5387672.0

[DireWolfM14]

TOR does indeed affect the download speed, but it's not the most significant factor.  If you are able to connect to ten peers, then I wouldn't worry about the connection type.  The most likely contributing factor is either your hard drive type or the connection to the hard drive.  If you have an old Pi with a USB 2.0 connection, that will slow things down.  A mechanical hard drive can also cause thing to slow down.

It's worth noting that a watched pot never boils.  Regardless of your setup, be patient and you'll enjoy having a full node running in due time.

[bittyuser]

Hey, there. I'm running a Raspibolt node.

Tor is very rarely the problem with slow syncing. It's either failing to find peers, or there is lack of memory. But before that, is your external drive an HDD? If that's so, then expect slow syncing. When I finished syncing a couple of years ago, I think it had taken me around 2 weeks, because of that. So, maybe you should shut down everything, move your blocks and chainstate in an SSD, let it sync there, and then move these directories back to your HDD drive. 

Hey man thanks for replying. I am using a 1TB Samsung T7 external SSD and tested the SSD and got about 350 mb/s. The SSD is connected to the blue USB port in the pi 4. Btw I am using Bullseye as per the guide. Apparently tried with Bookworm and there were permission issues that I couldn't resolve.

[BlackHatCoiner]

Hey man thanks for replying. I am using a 1TB Samsung T7 external SSD and tested the SSD and got about 350 mb/s.

Then it's not the disk. Could you quantify "slow"? If you've left it for a day and it's in 0.4, then there isn't necessarily anything wrong. It could take a couple more days to finish. If you experienced connection issues, then you would have stuck at a particular progress for a very long time.

Downloading would surely go faster without Tor. You can try using a VPN as proxy if hiding this activity from your ISP is needed.

[Yamane_Keto]

Did you change dbcache, you can change the value to a higher value (node never flushes the UTXO,) change the value to a value less than 4000, which is the size of your RAM,  will help to increase sync speed, but do not increase the number to a large number or close to 4000 to avoid crash problems.
You'll find more information here and the table below shows how much the sync speed will increase.



https://blog.lopp.net/effects-dbcache-size-bitcoin-node-sync-speed/

Connecting to Tor may increase speed if your ISP has restrictions on downloading Bitcoin.

[LoyceV]

Now the verification progress is at 0.4.

At 40%, chainstate is still fairly small. You can expect your download to slow down further when your RAM becomes the limiting factor.

https://blog.lopp.net/effects-dbcache-size-bitcoin-node-sync-speed/

You can't really compare dbcache-performance on a system with 8 times more RAM.

Connecting to Tor may increase speed if your ISP has restrictions on downloading Bitcoin.

That's very unlikely.

[Cricktor]

I am using a 1TB Samsung T7 external SSD and tested the SSD and got about 350 mb/s. The SSD is connected to the blue USB port in the pi 4. Btw I am using Bullseye as per the guide. Apparently tried with Bookworm and there were permission issues that I couldn't resolve.

You can run into an issue, when your SSD demands too much power from the Raspi 4B. A Raspi 4B can only provide a total power budget of 1.2A@5V (or 6W) for all its USB ports combined! Not exactly sure about the Samsung T7, it will mostly work but maybe can overwhelm the Raspi.

With only 4GB of RAM you will later in IBD run into I/O intense periods when chainstate grows way larger than 4GB and you can't give sufficient RAM to dbcache (see below).

The OS shouldn't be much of a factor here.


From an own full IBD experiment started somewhere in June 2023 with an Umbrel node that only ran a Bitcoin Core container via Tor on a Raspi 4B with 8GB RAM and a 1TB SATA SSD connected with an USB3-to-SATA adapter with UASP properly activated and working, I experienced a full IBD within about 95h until full sync with onlynet=onion, onlynet=i2p basically (I also had a dbcache=4883 in my bitcoin.conf file).

Your IBD will be slower as you can't reserve much more than maybe 2 or 2.5GB to dbcache. During IBD you may consider to set blocksonly=1 to avoid having to verify possibly incoming transactions.

If anyone is interested, I can provide snips from the debug.log that I preserved.

[bittyuser]

I am using a 1TB Samsung T7 external SSD and tested the SSD and got about 350 mb/s. The SSD is connected to the blue USB port in the pi 4. Btw I am using Bullseye as per the guide. Apparently tried with Bookworm and there were permission issues that I couldn't resolve.

You can run into an issue, when your SSD demands too much power from the Raspi 4B. A Raspi 4B can only provide a total power budget of 1.2A@5V (or 6W) for all its USB ports combined! Not exactly sure about the Samsung T7, it will mostly work but maybe can overwhelm the Raspi.

With only 4GB of RAM you will later in IBD run into I/O intense periods when chainstate grows way larger than 4GB and you can't give sufficient RAM to dbcache (see below).

The OS shouldn't be much of a factor here.


From an own full IBD experiment started somewhere in June 2023 with an Umbrel node that only ran a Bitcoin Core container via Tor on a Raspi 4B with 8GB RAM and a 1TB SATA SSD connected with an USB3-to-SATA adapter with UASP properly activated and working, I experienced a full IBD within about 95h until full sync with onlynet=onion, onlynet=i2p basically (I also had a dbcache=4883 in my bitcoin.conf file).

Your IBD will be slower as you can't reserve much more than maybe 2 or 2.5GB to dbcache. During IBD you may consider to set blocksonly=1 to avoid having to verify possibly incoming transactions.

If anyone is interested, I can provide snips from the debug.log that I preserved.

Yup I have dbcache=2000 and blocksonly=1. Btw how to avoid Tor for faster download? Do I need to comment out the network portion of my bitcoin.conf and stop tor.service from running? I really wanna get this download faster.

Also I am using a 65W power adaptor even though raspberry Pi has 15W.

[nc50lc]

Btw how to avoid Tor for faster download? Do I need to comment out the network portion of my bitcoin.conf and stop tor.service from running? I really wanna get this download faster.

It isn't the issue but if you really want to test, you can add these to your bitcoin.conf file or use as command line arg:

Code:

onlynet=ipv4
onlynet=ipv6
listenonion=0

"onlynet=ipv4" and "onlynet=ipv6" limits your node's outbound connection to those networks, and..
"listenonion=0" disables inbound connections via Tor.

Of course, don't forget to restart Bitcoin Core after changing the settings for it to apply.

[Cricktor]

Also I am using a 65W power adaptor even though raspberry Pi has 15W.

This doesn't resolve the Raspi 4B's internal power budget limitations of its USB ports. An original Raspi power adapter for the Raspi 4B is totally sufficient, a Raspi 5 power adapter definitely on the safe side. Your 65W power adapter is way over the top and maybe better suited for some other device, but of course it doesn't hurt. Your Raspi won't take more than ~15W from it, anyway.

You may never experience a problem with your Samsung T7 SSD attached to your Raspi. But there's no guarantee. From few pictures of this device's side opposite to the connection port it's labeled for a power consumption of DC+5V and 1.5A (likely the maximum rating at worst case), but that would definitely exceed the Raspi's power budget.

I find it very bad that Samsung doesn't say anything about the power ratings of the T7 SSD variants in the data sheets. How stupid is that!

I'm just saying what is a not well known and frankly a little bit annoying limitation of the Raspi 4B. USB3 is commonly expected to support up to 2A, ideally per port.

A possible remedy is to use a sufficiently self-powered USB3 hub in-between.

[bittyuser]

Btw how to avoid Tor for faster download? Do I need to comment out the network portion of my bitcoin.conf and stop tor.service from running? I really wanna get this download faster.

It isn't the issue but if you really want to test, you can add these to your bitcoin.conf file or use as command line arg:

Code:

onlynet=ipv4
onlynet=ipv6
listenonion=0

"onlynet=ipv4" and "onlynet=ipv6" limits your node's outbound connection to those networks, and..
"listenonion=0" disables inbound connections via Tor.

Of course, don't forget to restart Bitcoin Core after changing the settings for it to apply.

This is how my bitcoin.conf looks like:

Code:

# Network
onlynet=ipv4
# onlynet-ipv6
listen=1
listenonion=0
#proxy=127.0.0.1:9050
#bind=127.0.0.1

# Raspberry Pi optimizations
maxconnections=40
maxuploadtarget=5000

# Initial block download optimizations
dbcache=2000
blocksonly=1

I observed the downloads and verification is slightly better. Also I stopped tor.service. Not sure if that played a part. Just gonna let it download and verify 100% then will revert back the bitcoin.conf file and turn on tor.service.

Ok played around with reinstating tor.service and revert back the bitcoin.conf. I noticed

Code:

2024-09-30T10:59:31Z Socks5() connect to 2001:4c3c:4b02:eb00::2:8333 failed: general failure

Is this something to be concerned of? Because I always gets that.

[nc50lc]

I observed the downloads and verification is slightly better. Also I stopped tor.service. Not sure if that played a part. Just gonna let it download and verify 100% then will revert back the bitcoin.conf file and turn on tor.service.

Maybe just a bit of luck on the quality of your peers?
In terms of download, even 10 peers with good connection is good enough for fast sync; maybe you had bad luck with finding pees when connecting through Tor.
Then in verification stage, there's when you'll experience some slowdown depending on your hardware and settings, fast download or not.

Ok played around with reinstating tor.service and revert back the bitcoin.conf. I noticed

Code:

2024-09-30T10:59:31Z Socks5() connect to 2001:4c3c:4b02:eb00::2:8333 failed: general failure

Is this something to be concerned of? Because I always gets that.

Looks like an issue with your connection to certain IPv6 peer. That's normal if proxy is enabled.
If there's no other errors after it, there's nothing to be concerned of.