BTC initial blockchain download is only at 40 blocks/hr

I was looking at their gui. I set it 1Gb less than I have for ram on a server. I will set mine 2Gb less since I want to run KDE desktop on the terminal side.
But I also do peer timeout 6 seconds, and connection timeout 500ms.

I’m going to check how well it works, even though I can go in to the .conf file directly and set my other bitcoin node and local copy the blockchain and that takes 4-6 hrs to sync it.

1 Like

but mine just crashed, so I have to see what’s up.

2025-09-03T03:54:09Z Fatal LevelDB error: Corruption: block checksum mismatch: /data/bitcoin/indexes/txindex/000647.ldb
2025-09-03T03:54:09Z You can use -debug=leveldb to get more complete diagnostic messages
2025-09-03T03:54:09Z
************************
EXCEPTION: 15dbwrapper_error
Fatal LevelDB error: Corruption: block checksum mismatch: /data/bitcoin/indexes/txindex/000647.ldb
bitcoin in scheduler
************************
EXCEPTION: 15dbwrapper_error
Fatal LevelDB error: Corruption: block checksum mismatch: /data/bitcoin/indexes/txindex/000647.ldb
bitcoin in scheduler
terminate called after throwing an instance of 'dbwrapper_error'
what():  Fatal LevelDB error: Corruption: block checksum mismatch: /data/bitcoin/indexes/txindex/000647.ldb

Ok, where do you clear the DB and reindex? I think they have something wrong but even the linux desktop QT app lets you reset it.

I don’t need to run the node on this machine since I do have a node somewhere else, but the dumb install of public pool forces this to be install and sync for some reason. I could cheat and set the trim to 1 MB

I wonder which version of bitcoin they are using. Because that doesn’t happen. I have one of these running as a media server because I have nodes but was thinking about having an alternative to my ckpool on another machine.

Their interface looks pretty, however, the QT desktop program from bitcoin works and have all the controls. You can’t even access the config file directly.

I’m going to uninstall and reinstall it.

But to let you know start9 is having the same error but they are blaming rust programming.
Which is another docker container environment.

We’ll see if it fails again, If it does, I’m going to bail on it and see if bitcoin knots works.

edit:
turning off tor drops connections down to 5 but the rate of blocks is quicker. 10 minutes later it had 10 connections.

but then it crashes w/o errors:

best=0000000000000001ebd19ea78a8e57ba66409df33900c41c97d9ec7217178216 height=263762 version=0x00000002 log2_work=72.777729 tx=25411090 date='2013-10-15T05:16:35Z' progress=0.020573 cache=861.0MiB(6674317txo)
2025-09-03T04:57:52Z UpdateTip: new best=000000000000000c6aeec631781619e3b88e95e31529fc524fe3f7743fc997b2 height=263763 version=0x00000002 log2_work=72.777874 tx=25411100 date='2013-10-15T05:19:09Z' progress=0.020573 cache=861.0MiB(6674317txo)
2025-09-03T04:57:52Z UpdateTip: new best=0000000000000003454c2e4ba914a51441164a22aec7c044e9e8095d910a73fc height=263764 version=0x00000002 log2_work=72.778018 tx=25411195 date='2013-10-15T05:19:42Z' progress=0.020573 cache=861.0MiB(6674330txo)
2025-09-03T04:57:52Z UpdateTip: new best=00000000000000116ad0cfb419a093ceabc8170e13de236829515cc331dbf373 height=263765 version=0x00000002 log2_work=72.778163 tx=25411424 date='2013-10-15T05:22:15Z' progress=0.020574 cache=861.0MiB(6674650txo)
2025-09-03T04:57:52Z UpdateTip: new best=0000000000000002da9f3ba227af035ad27de094a37099847392cc74156055fd height=263766 version=0x00000002 log2_work=72.778308 tx=25411528 date='2013-10-15T05:26:48Z' progress=0.020574 cache=861.0MiB(6674071txo)
2025-09-03T04:57:52Z UpdateTip: new best=000000000000000ec2426d9e4bbda222d3fd0b498e3e85ebc5933117962baf42 height=263767 version=0x00000002 log2_work=72.778453 tx=25411604 date='2013-10-15T05:28:12Z' progress=0.020574 cache=861.0MiB(6673472txo)
2025-09-03T04:57:52Z UpdateTip: new best=0000000000000007827cd28dcaadee482368c2417c3bc17c5f7a45704ca55048 height=263768 version=0x00000002 log2_work=72.778598 tx=25411641 date='2013-10-15T05:29:31Z' progress=0.020574 cache=861.0MiB(6673514txo)
2025-09-03T04:57:52Z UpdateTip: new best=000000000000000d018c29e07b4042b8ab0f6178581106eb434bd632cb5ec5b1 height=263769 version=0x00000002 log2_work=72.778742 tx=25411690 date='2013-10-15T05:30:22Z' progress=0.020574 cache=861.0MiB(6673555txo)
2025-09-03T04:57:52Z UpdateTip: new best=0000000000000005c0cb84cc9af4c6bd93bb052a7adef5f677b5b943789fe539 height=263770 version=0x00000002 log2_work=72.778887 tx=25411714 date='2013-10-15T05:32:42Z' progress=0.020574 cache=861.0MiB(6673549txo)
2025-09-03T04:57:52Z UpdateTip: new best=0000000000000000f0de562c2bb848ffa214828dc4c6754bf17e73c8a25a65c1 height=263771 version=0x00000002 log2_work=72.779032 tx=25411758 date='2013-10-15T05:33:13Z' progress=0.020574 cache=861.0MiB(6673656txo)
2025-09-03T04:57:52Z UpdateTip: new best=0000000000000005a079472f08b387fdae9c2d7bf7a40d7764485316f5bccd75 height=263772 version=0x00000002 log2_work=72.779177 tx=25411917 date='2013-10-15T05:39:28Z' progress=0.020574 cache=861.0MiB(6673720txo)
2025-09-03T04:57:52Z UpdateTip: new best=00000000000000081be30a49762882c8a106942916e530ed15b78ade7ade809f height=263773 version=0x00000002 log2_work=72.779321 tx=25411983 date='2013-10-15T05:40:50Z' progress=0.020574 cache=861.0MiB(6673452txo)
2025-09-03T04:57:52Z UpdateTip: new best=000000000000000e880ef12886b7d5c1f5f0f289f3b5f39deda07cde94d5bbb7 height=263774 version=0x00000002 log2_work=72.779466 tx=25412003 date='2013-10-15T05:40:43Z' progress=0.020574 cache=861.0MiB(6673451txo)
2025-09-03T04:57:52Z UpdateTip: new best=000000000000000ad2a94c03590ab237133160e37a19aee5d4358a50d64d4cb8 height=263775 version=0x00000002 log2_work=72.779611 tx=25412233 date='2013-10-15T05:56:13Z' progress=0.020574 cache=861.0MiB(6672685txo)
2025-09-03T04:57:52Z UpdateTip: new best=000000000000000163ac630240de87503357dc636661e2ef300f1b83b03cd2f1 height=263776 version=0x00000002 log2_work=72.779755 tx=25412711 date='2013-10-15T06:08:33Z' progress=0.020575 cache=861.0MiB(6672938txo)
2025-09-03T04:57:52Z UpdateTip: new best=000000000000000ca3601798fd049d68ea92c8575470481bc96b30d9fc319c1c height=263777 version=0x00000002 log2_work=72.779900 tx=25412788 date='2013-10-15T06:13:28Z' progress=0.020575 cache=861.0MiB(6672971txo)
2025-09-03T04:57:52Z UpdateTip: new best=0000000000000009cc6f559abeb8ac1f18134a2ccaa0a6295d404138ff3876b4 height=263778 version=0x00000002 log2_work=72.780045 tx=25413227 date='2013-10-15T06:22:53Z' progress=0.020575 cache=861.0MiB(6673102txo)
2025-09-03T04:57:52Z UpdateTip: new best=0000000000000010ad25618b500740bc70e7001327cf68f8588bc0e30575aa4e height=263779 version=0x00000002 log2_work=72.780189 tx=25413261 date='2013-10-15T06:25:21Z' progress=0.020575 cache=861.0MiB(6673100txo)
2025-09-03T04:57:52Z UpdateTip: new best=000000000000000e280e2884b532ccafc444d65744da1b59990a3e6a8ef31e4a height=263780 version=0x00000002 log2_work=72.780334 tx=25413381 date='2013-10-15T06:29:14Z' progress=0.020575 cache=861.0MiB(6673158txo)
2025-09-03T04:57:52Z UpdateTip: new best=00000000000000159d35ee643a1eb895981c4ac6ca005aae6130cebde8340060 height=263781 version=0x00000002 log2_work=72.780479 tx=25413468 date='2013-10-15T06:30:52Z' progress=0.020575 cache=861.0MiB(6673113txo)
2025-09-03T04:57:52Z UpdateTip: new best=000000000000000830d9fd91e01af936019d1b8a506d2622586c7bea9dc0af5e height=263782 version=0x00000002 log2_work=72.780623 tx=25413827 date='2013-10-15T06:43:57Z' progress=0.020575 cache=861.0MiB(6673235txo)
2025-09-03T04:57:52Z UpdateTip: new best=0000000000000011a6926caeda6c6badb3a239b9bbf743b0d18bc696ceb8a5b0 height=263783 version=0x00000002 log2_work=72.780768 tx=25414033 date='2013-10-15T06:47:55Z' progress=0.020576 cache=861.0MiB(6673322txo)
2025-09-03T04:57:52Z UpdateTip: new best=000000000000000f89341b1b1bcc5e67bd9efe46880de86b797bae6f919f5159 height=263784 version=0x00000002 log2_work=72.780912 tx=25414175 date='2013-10-15T06:54:55Z' progress=0.020576 cache=861.0MiB(6673422txo)
2025-09-03T04:57:52Z UpdateTip: new best=0000000000000002a0cb11162c3f5874cd04416464cf5436fa39e515e8e668c9 height=263785 version=0x00000002 log2_work=72.781057 tx=25414306 date='2013-10-15T06:59:28Z' progress=0.020576 cache=861.0MiB(6673508txo)

So I reboot the machine since I have to restart in their web gui.
Never seen that before, but running it in docker containers might make sense to some people but It does not look like sound technology.

about 30 minutes later:

3T21:39:22Z' progress=0.032917 cache=1419.7MiB(11532964txo)
2025-09-03T05:28:47Z Fatal LevelDB error: Corruption: block checksum mismatch: /data/bitcoin/indexes/txindex/000782.ldb
2025-09-03T05:28:47Z You can use -debug=leveldb to get more complete diagnostic messages
2025-09-03T05:28:47Z
************************
EXCEPTION: 15dbwrapper_error
Fatal LevelDB error: Corruption: block checksum mismatch: /data/bitcoin/indexes/txindex/000782.ldb
bitcoin in scheduler
************************
EXCEPTION: 15dbwrapper_error
Fatal LevelDB error: Corruption: block checksum mismatch: /data/bitcoin/indexes/txindex/000782.ldb
bitcoin in scheduler
terminate called after throwing an instance of 'dbwrapper_error'
what():  Fatal LevelDB error: Corruption: block checksum mismatch: /data/bitcoin/indexes/txindex/000782.ldb

I would trim it to 20 GB if I wanted to run it but it seems that it likes to crash. I don’t know if I could rely on it running a pool unattended. Definitely wouldn’t want to have a wallet attached to it.

tried bitcoin knots: failed:

5-09-03T05:51:39Z opencon thread start
2025-09-03T05:51:39Z msghand thread start
2025-09-03T05:51:39Z [error] A fatal internal error occurred, see debug.log for details: Corrupt block found indicating potential hardware failure.
2025-09-03T05:51:39Z [error] ConnectTip: ConnectBlock 00000000000000d4153c949ae09088b16b772ef5ec4d71493592d90404cc1f55 failed, bad-txnmrklroot, hashMerkleRoot mismatch
2025-09-03T05:51:39Z Shutdown: In progress...
Error: A fatal internal error occurred, see debug.log for details: Corrupt block found indicating potential hardware failure.
2025-09-03T05:51:39Z opencon thread exit
2025-09-03T05:51:39Z [error] A fatal internal error occurred, see debug.log for details: Failed to connect best block (bad-txnmrklroot, hashMerkleRoot mismatch).
2025-09-03T05:51:39Z dnsseed thread exit
2025-09-03T05:51:39Z addcon thread start
2025-09-03T05:51:39Z addcon thread exit
Error: A fatal internal error occurred, see debug.log for details: Failed to connect best block (bad-txnmrklroot, hashMerkleRoot mismatch).
2025-09-03T05:51:39Z Loading 0 mempool transactions from file...
2025-09-03T05:51:39Z Imported mempool transactions from file: 0 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast
2025-09-03T05:51:39Z initload thread exit
2025-09-03T05:51:39Z txindex thread start
2025-09-03T05:51:39Z txindex is enabled at height 218041
2025-09-03T05:51:39Z txindex thread exit
2025-09-03T05:51:39Z basic block filter index thread start
2025-09-03T05:51:39Z basic block filter index is enabled at height 218041
2025-09-03T05:51:39Z basic block filter index thread exit
2025-09-03T05:51:39Z net thread exit
2025-09-03T05:51:39Z msghand thread exit
2025-09-03T05:51:39Z DumpAnchors: Flush 0 outbound block-relay-only peer addresses to anchors.dat started
2025-09-03T05:51:39Z DumpAnchors: Flush 0 outbound block-relay-only peer addresses to anchors.dat completed (0.00s)
2025-09-03T05:51:39Z scheduler thread exit
2025-09-03T05:51:39Z Flushed fee estimates to fee_estimates.dat.
2025-09-03T05:51:40Z Shutdown: done

I would rethink it. I will try putting a different pool on a linux install and run apache guacamole

Apologies for missing your comment, have you got this sorted out?

My Rasp Pi is 8gb Ram my MBP is 32GB Ram.
In my Rasp Pi i have the T7 plugged in, umbrel installed on the T7.
Since it was taking so long I used my MPB to download the blockchain files onto a separate SSD from bitcoin core installed directly on my mac.
Then i plugged the separate SSD into the Rasp pi and copied the files into the bitcoin app on umbrel via SSH. They don’t let you use their interface to transfer files, but you can still transfer them with terminal commands.

Basically I just had Chat GPT pulled up next to me to walk me through every command until we got it figured out together.

I found out I had a bad stick of ram. That is why mine was crashing. But increasing the cache size speeds up the syncing process. I mine synced within 2 days using 32 GB of ram with a cache size of 24 GB.

it used to sync fine, and now it doesn’t and it is OS related. Doing IBD on other available node OS is much faster, which is sad at this point for thos who desire to stay with umbrel

They need to do the trixie update. I posted a guide to it so others that have modern hardware can run Umbrel and its much faster. Even though there is certain limitations with docker containers compared to like an Ubuntu Server install and setting up a node that way.

I started a github so you can download and apply patches and enhancements I come up with:

But with the limitation in docker, if its not modified, the bandwidth is 500MB/sec which I would think that would be enough. The Linux single thread limitation is 1.5GB/sec unless modified

Hi!

I have not sorted out my Umbrel/Rpi node yet. The speed of the download reduced to 10 blocks an hour.

I have instead bought a mini pc and installed Start9 OS on it. It’s been syncing for almost a week and is at about 75%. However it is slowing down considerably to about 80-100 blocks an hour. So, today I switched out the 8gb RAM on the pc and installed a 16gb stick. So far it is looking faster already. I just calculated it at 3,600 blocks an hour. I have the dbcache set at 12,000.

I guess the problem really just comes down to RAM. 8GB is just not enough for a IBD these days. The last 15% of blockchain is the heaviest and takes 90% of the sync time.

I feel like the Raspberry pi 5 is just not able to handle the download. After the IBD, it’s probably good enough though.

1 Like

it used to be much faster with lower spec Pi so it is 100% a bloated software problem.

it could be memory allocation and what kind of media Umbrel is loaded on.
What kind of media the Umbrel OS is loaded on?
Because SD cards are not suitable for an OS install to begin with.

But since the PC install is different from the raspberry PI,
What do you get when you execute:

free -m

at the terminal?
Because it might be a swap file issue.
I have ran Umbrel on a 4GB PC before, but I had to increase the swap because I had a lot of programs loaded on it.

I just installed Start9 on a 2014 Mac Mini with 2tb SSD and 8gb Ram.
Hoping this works out OK.
How is your IBD going on the Start9 with 16gb ram?
I can’t upgrade the Mac Mini

My node is finally synced!

I think the 16 GB RAM was a really important factor. I’m not sure if switching from Umbrel to Start9 OS made a difference.

I started on September 14 with the 8 GB of RAM and ran that for almost a week. Then it slowed down a lot when syncing blocks from around 800k and higher.

I installed the 16 GB of RAM and the IBD lasted about eight more days.

I know NOTHING about computers, but I would recommend getting 16 GB of RAM at a minimum.

My Umbrel/RPi5 (8bg) is pretty well stalled out. I’m shutting it down.

1 Like

I ended up not using Start9 on the mac mini due to hardware compatibility issues.

I reinstalled MacOS Monterey which is the latest I can use on my 2014 Mac

I started IBD on Tuesday 30th and it completed today so about 5 days.

I think something must be broken with the Umbrel Bitcoin app,

1 Like

Well there really is nothing different on the versions of bitcoin in docker what umbrel uses vs start9 other than port numbers. Umbrel don’t have a swap file and the other does. Their debain OS is even outdated besides not having a swap partition or file which is a standard affair in Linux to set up. It takes less than 3 days with a 16 gb swap, three weeks without one and that is even if you use direct connected to nodes instead of using tor, which is very slow.

The same Syncing issue here. RPI 4 8GB RAM, all runing on SSD. OS reboot helps for a bit, its syncing fine for a bit then it gets stuck again. No swap.

I am having the same issue, plus in the last 3 days I am seeing two knots icons, what can it be?

Using an NVME drive gives better results. SSD or HardDrives are really slow when it comes to validate the blockchain.

I have a node and I attached a NVME drive and it was really fast

I am using a 2.5” samsung ssd, it is really fast not as a nvme but the bottleneck I think it is my rpi4 even with 8GB of ram.

I increased cache size to 2GB and now it seems to be going faster

how far with the sync are you? It was running fast up until 50% of blockchain sync

45%:woozy_face: but already going very slow, yesterday I changed cache size to 4GB it seems 0,0000001% faster lol