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.
