Slow Initial Blockchain Download on Bitcoin Core

I know there are loads of threads on this, but I couldn’t find the specific answer I’m looking for. I tried to comment on some older threads but got flagged for them being over 120 days old, so here we are with a fresh post. I’ve got two nodes up and running and I'm in the process of setting up my third one. The first two nodes were built between blocks 700,000 and 750,000, and that went pretty smoothly. Now, with the third node, my Initial Blockchain Download (IBD) is crawling. Let me break down my setup for you. **Hardware:** 1. Raspberry Pi 4 Model B with 8GB RAM. 2. Cat6 ethernet cable. 3. 2TB SSD 2.5''. 4. SATA (on the drive) to USB 3.0 (on the RPi). **Internet speed:** Download: 200 Mbps Upload: 5 Mbps Ping: 4 ms **Software:** Raspbian OS Bitcoin Core 25.0 My config is: After hitting block 790,000, things really slowed down. I spent 5 days getting to block 790,000 and then 3 more days just to reach 810,000. There are still about 10,000 blocks to go, which is gonna take even longer. I get that this is normal since it scans and validates everything recursively. But does anyone know if -txindex=1 makes the Initial Blockchain Download slower? If it does, what’s the reasoning behind that?

txindex does slow down the IBD, but it shouldn't make it that slow. So I want to ask you, where did you configure the datadir? Because if you're going to make I/O go through the SATA connection to USB3, that's going to be quite slower than just writing on the SSD directly. USB3 standard is 10GB/s maximum, and the disk is probably doing much less.

Not sure I understand this. The datadir is on the SSD. The SSD is external to the Raspberry. So essentially I run:

Why don't you just copy the blockchain from your existing nodes to the new node? I guess that's around the time the Ordinal spam largely increased the number of transactions, and the size of chainstate. It currently takes 8.5 GB on disk, which won't fit your 8 GB RAM anymore. It looks like 16 GB is the new minimum for a fast IBD.

Ok you made me lough out loud. How can I be so silly?! It didn't even cross my mind. However, supposing I wanted to do it, would I need to copy the chainstate and blocks directories? Or all the items from the Bitcoin Core directory (.conf, .log etc) ? I won't stop the process now, since I am almost done, I guess. Makes sense, but 16 GB is a lot for a cheap computer. RPi doesn't support 16GB anyway.

I'd copy everything in ~/.bitcoin/ (after shutting down Bitcoin Core). Yep, it sucks And the Bitcoin dust those Ordinal spammers create will remain unspent taking up space in chainstate forever.

Must be your RPi's CPU struggling on script verifications after v25.0's default "assumevalid" blocks which is before block height 784000. Here's for reference: github.com/bitcoin/bitcoin/blob/v25.0/src/kernel/chainparams.cpp#L107C128-L107C128 It's not recommended but if you think it's necessary to speed up your node's IBD, you can set a custom assumevalid block by setting -assumevalid=<block_hash>.

Thanks, I will see the reference because it is something I ignored until today. Wouldn't it be bad for security though? Is this why you say it is not recommended? Definetely gonna try it after the sync is finished. Unfortunately we have to live with it. Pruned nodes in the future will avoid the issue, I suppose.

Is it your full configuration file or you removed line dbcache? Pruned node need full UTXO in order to verify new TX/block, so i doubt it's possible. At best, we'll see slightly more efficient UTXO representation.

I have set my dbcache on the commandline running The reason is that I want to run with default dbcache when IBD is finished. Doesn't it have the same result as adding dbcache=4096 on the conf file and then run: Yeap, you must be right. Like how much? Perhaps all of it? 8192? I don't run anything else on this device. My plan, in general, is to run Bitcoin & Monero node on the same machine. EDIT: I set it to 7000 and let's see... [moderator's note: consecutive posts merged]

That leaves nothing for other programs, so it's too much. I'm curious if that helps. More dbcache also means less file cache for the OS.

It's not necessary bad, security-wise, because it's just the script verifications that are skipped. Everything in the assumed valid blocks are still being verified by your node. The topic is quite famous after its implementation so you will find a lot of helpful related topics across the internet. For example: https://bitcoin.stackexchange.com/a/88666

Exactly, but I haven't found any explanation online, so I thought perhaps one would know in this forum. Feels like above 4GB doesn't help too much. It's like there is a soft-cap and then the return you get is diminishing. Perhaps I am wrong though. I am sorry I don't follow you on this. You mean perhaps I should add less than 7000 and go for 6000 for example? Thanks mate, much appreciated!

Try 3/4ths of the total RAM. Your disk doesn't seem to be the problem I thought you had an internal SSD and externally-attached 2TB SSD... my bad. Also combine it with the assumevalid directive that nc50lc posted about, maybe set it to 800000 blocks, to really speed up things, as these things must have been verified thousands of times by now.

I will set it to 800,000 and also set dbache to 6000 and I will see if it makes a difference.

Have you done any checks on the SSD? I spent a couple of hours the other day trying to figure out why a PC was so slow and it turned out the almost new SSD was failing SMART checks. Was looking for malware, was checking running apps, etc. Till I finally ran crystaldisk and poof. But neither the PC or Windows put up a smart error. -Dave

Hi Dave, no I haven't checked the disk. I think it's an exFAT, but I am not sure. Also I run Raspbian and I am not aware of what crystal disk is. Is it a tool?

Crystaldiskinfo is a SMART https://en.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Technology checker for drives for windows. I don't know of an equivalent for RPi, will have to look. But it does show what the drive thinks is going on it with it, not what Windows or what the PC itself thinks. They can for whatever reason hide / not report SMART issues. -Dave

I was referring to swappiness value (each distro probably have different default value) which affect swap behavior. That means i suggest you to check that value and optionally reduce it. Here's an example guide, https://linuxize.com/post/how-to-change-the-swappiness-value-in-linux/.

To sum up: The IBD went from 0 to 790,000 in 5 days, then from 790,000 to 810,000 in 3 days, then from 810,000 to 814,000 in 2 days and currently, from 814,000 to 816,000 in 10 hrs. I guess it will reach 819,000 soon enough. Thank you all for the answers, apparently it was what Loyce said above regarding the ordinals and the larger transactions. Now, I am at 816,000 and it moves quickly. It must be finished later during the day. Finally, I did increase my dbcache to 6000 (from a total of 8GB RAM), as all of you suggested. However, I did not use the assumevalid directive, because I wanted to read more about it before using it, but unfortunately I didn't have the time.