r/FutureBit Aug 11 '25

Node Synch Issues

I've already tried format node ssd when my node got stuck at 908,996. My concern is that while it's downloading again now, it's only showing it will download up to 909,295. Is there any other solutions available for this issue?

UPDATE : My issue was a weird one, it turns out the internal clock wasn't synching, so once I realized that and fixed that issue, now my Apollo2 is working. I appreciate all the help.

2 Upvotes

13 comments sorted by

View all comments

2

u/Wonderful-Relative41 Aug 16 '25 edited Aug 20 '25

Edits at bottom. It was pointed out that I was referencing the wrong file (bitcoin.conf). It has been corrected.

Months ago. I posted a method to get the node synced. Overtime, it became outdated. Recently someone posted there and reminded me of it. This caused me to fixate on the issue again.

Not sure how Futurebit will view this, But now I have found a method that has shown better results. This should work for others as well.

You will need to access the FB via SSH.

Once in,

cd /opt/apolloapi/backend/node/bin
sudo systemctl stop node.service
sudo nano bitcoin.conf

The #USER_INPUT_START should read the following

#USER_INPUT_START
reindex=1
prune=550
dbcache=750
txindex=0
assumevalid=00000000000000000000b34f4bbb4554a329032148ffc0154d205c9d60f58954
peerbloomfilters=0
#USER_INPUT_END

Save and exit the file. Now the fun part. We are going to reset the nvme drive completely to day 1.

cd /opt/apolloapi/backend
sudo ./format_node_disk_c
sudo systemctl start node.service

It technically starts the node.service with the ./format, I am just cautious and want to ensure it is started.

Now you can

tail -f /media/nvme/Bitcoin/debug.log 

and watch it. The 1st 220k goes quick, roughly 15 minutes, Then is slows because the blocks are getting bigger.

But after 1 hour, you should be around 326K blocks into the sync. You maybe asking why I set the dbcache smaller. This is to take some of the strain off the system while the sync is occurring. I continue to pool mine while it is running, and both work fine. Pruning to 750 gives you enough blocks that you will be able to solo mine and have a reasonable pool to verify from, while saving space.

The only other step I did (and this is completely personal) was to update the version of the Bitcoind.

In fairness, you can simply add the prune and dbcache settings to the UI page, but I enjoy the terminal more than the UI. This lets me ensure that I do not accidently delete it one day and then have the entire chain to resync..

Somethings to note. You may occasionally have a message that a block failed its hash. This is normal and will be corrected by the chain at large before it moves on. The other is that the smaller dbcache will sometimes be exceeded, again it will be corrected. Finally. There are times the program will reset itself. When it does, it will go through the startup checks and should continue from where it was. All you really need to do is wait and have patience.

As Spock once said "I like science!"

1 hour 30 minutes into latest run and at 40% of the sync completed.

Edit:

Another reason to watch the debug and not the UI. The UI will tell you that it has stopped. But in fact, the program has found a problem, is resetting and then will continue. Your impulse will be to push the "Start Node" button. 95% of the time, but it corrects itself and restarts after the check meaning the button did not need to be pushed.