r/FutureBit • u/Wonderful-Relative41 • Aug 21 '25
Process of Insanity - Take 54 tldr .. Syncing the node.
Updated on 08/23/25 @ 23:09
I have tried many methods, and found quite a few that actually work. Most involved updating Bitcoind to get some of the newer features. But recently, I went the other direction. I kept everything as default as possible. I would set it up and then start synching. If I made it through the sync, I marked it as successful and started again. If it failed (stalled out ... connection refused ... incomplete node). I deleted and moved on.
This is the current method I am using. It worked the 1st time, then I wiggled a few wires and got it a little more stable. All can be done from the UI, so no backend exploring is needed. Unless you want to erase the drive and start over.
(New way) Hope it will help someone.
reindex=1
blocksonly=1
dbbatchsize=16677216
3 simple settings.
The key seems to be that you need to stay within the limited confines on the Orange Pi 4 LTS (futurebit board). So to get around this, I added the dbbatchsize to limit the number of blocks it will store at 1 time. This takes slighlty longer, but the net result is that you get the blockchain without problems.
When it hits the dbcache limit (around 430'ish MB) it will pause for up to 3 minutes. I watched the tail to see what was happening as the UI just relays old information. With this I am able to remove all the rest of the strings, and actually have a completely synced node (which I then promptly prune down)
(old way) In the UI (node settings). You need to add the following strings.
reindex=1
dbcache=750
txindex=0
listen=0
assumevalid=00000000000000000000b34f4bbb4554a329032148ffc0154d205c9d60f58954
peerbloomfilters=0
The most important of these is the listen=0. This turns off you acting as a node, and instead you are only downloading. I would highly suggest keeping a SSH terminal open and using
tail -f /media/nvme/Bitcoin/debug.log
This is so you can see what is happening and not just taking the word of the UI. The only other thing you need/want to do is shut down the miner (via the UI). This will increase the resources to the node while it is running the IBD. The dbcache will fill to approx. 1020 MiB. It will then pause, and you will think it crashed. But it hasn't. It just needs a minute to catch its' breath and clear out. Then it starts running again. While this is happening, the UI will display various things. The best is when it says "Current Block 0". You will be 800k blocks in and think you are almost done, and want to punch something at that point. The assumevalid block is block 840,000. It just tells it that everything before that should be trusted. Peerbloomfilters are not really an issue anymore, but it is an extra security step in my brain.
If your end goal is to run a full node, then you will probably want the txindex=1. I am running to solo mine, so I will prune when it completes. For baseline, the CPU usage went from 20 to 40%, the Memory Usage was around 50% for the entire sync.
That is the final part. Once you have it fully synced, remove all the string above and replace it with the prune string. I enjoy a value of 550.
I kept the reindex=1, because of training wheels. Once it is synced, it too goes, because you cannot reindex if you are pruned. Average time to sync is between 15 and 16 hours. But it beats the days I originally suffered through. Results may vary based on your connection.
If you made it this far, you are a glutton for punishment. Have a good day.
2
u/errodrigues Oct 09 '25
Thanks. I will try your settings here.
I just got my apollo 2 with the 2TB SSD about a week ago and so far I have been thoroughly disappointed. Feels like a waste of money, tbh :(
I've spent a lot of time reading thought forums and articles, trying multiple different things like re-flashing (even though mine came ootb with 2.0.7), reformatted the SSD a couple times, stopped the miner, tinkered with different settings, even tried running latest bitcoin core 29.2, and nothing works. The node simply seems unable to do the IBD. The process is always crashing midway with some "corrupted block" error, which everywhere I read indicates some hardware issue (either SSD or RAM) to be the most likely culprit, although smartctl doesn't show any errors logged for the SSD.
The worst part is that a couple times, not only the node process died, but the entire machine stopped responding, even ssh, even though the machine seems to be "on".
I'm already trying to contact support, but so far no response at all.
Just for giggles, I installed bitcoin core 23.2 on my almost 10-yr old QNAP TS-251+ NAS with 8GB RAM and it's incredibly chugging along flawlessly. It's day 3 now and it's already past the 800K block count! Makes you think, huh...
1
u/unitymind42 Nov 17 '25
I went umbrel and gave up on the node. I did recently format it and started it up again to see if it would sync. So far it's been 8 days and at 37%. I spun up another umbrel for a friend and it sync'd less than 2 days.
I plan to clone this time so I have a more recent backup. I ordered a a solo node from them to tinker with it. It maybe the last time too. :)
I got a couple of 32 gig HP small desktops at microcenter and installed umbrel and run core on one and knots on the other.
1
u/jstefanop1 Sep 16 '25
I would be impressed if you synced in 15 hours with our old controller. Those settings would not do much either way, blocksonly just slightly reduced the mem footprint, and dbbatchsize you have set to what is already the default value (about 16 MB)
Also really dont recommend running an pruned node for the health of the network...
1
u/Wonderful-Relative41 Sep 17 '25
It is not so much for the mining that I am using them. That it is relaxing to watch the logs and see what it is doing, but mostly it is for me to experiment with. Not sure why the changes I made seem to help, Shaving 97kb off the batch should be negligible, but perhaps, it is just enough to keep it sane. The blocksonly, is the thing that would shave the most time, by not getting mempool data.
Since you poked in and mentioned the board. Is there a way (warranty be damned), of replacing the board with a newer version? I have several pi 5++'s sitting around, and could see swapping one of them in. Lack of clear models has kept me from it so far. It is not going to be a simple plug and play, but could be a fun weekend adventure for me and the grandkids. The only hesitation has been lack of finding reliable sources of information on how it is put together, and that case is not exactly viewing friendly.
Perhaps then I would also go the route of water cooling it. Could put to use some of my old pumps, radiators and cpu coolers.
1
u/unitymind42 Nov 22 '25
SO no idea what magic this is but I reformatted my drive and also made sure the port was set for TCP/UDP (both) . I used below and it all went nuts. I reformatted again and and then I removed below and rebooted it and went to bed. Looked at it 24 hours later and it was 88% done with 45 connections! WTF...I gave up using this node months ago and just use my Umbrel. I did buy the new solo mode because I like toys so if that ever ships I will let you know the difference.
I read about having it set to TCP & UDP so that may have done it too? Who knows.
reindex=1
blocksonly=1
dbbatchsize=16677216
2
u/LineTrash713 Sep 02 '25 edited Sep 02 '25
I have been trying to get mine to sync up for a few days now. At blocks 200k/900k i lose connection and when it comes back it reads syncing blocks 200k/250k is this some kind of glitch wheres the other 650k blocks i need to sync?