Here are my notes regarding recovering an abandoned Bitcoin node on my desktop.
First, I tried to restart my bitcoind node. Upon running my local version of bitcoind, I hit this error. I’m still not sure what caused it. Before attempting to debug, I figured I should upgrade my bitcoind.1
I chose the only sane option available, JFW's latest patch for his reference client. Upon running jfw’s install script on my Canto OS 6.10, I hit an error related to gcc’s linker. Jfw’s proposed i install glibc-static to fix the issue. So I ran
yum install glibc-static
Most of the CentOS 6.10 repository servers are offline, but yum managed to find one still laying around in the ruins of the sane software apocalypse.
I determined that there was something wrong with my .bitcoin directory, because I was able to run bitcoind by making a fresh directory (after backing up my old one.) Instead of trying to find out how my directory was corrupted, I decided to resync from the genesis. Since my home directory does not use the 4TB SSD that I plan to use for my node, I created the following symlink.
ln -s /mnt/mybigharddrive/.bitcoin ~/.bitcoin
I considered speeding up my resync by feeding my new node the backed up blocks using -eatblock. I vaguely remembered that I needed to use the blkcut tool to slice up my blk0xxx.dat2 files into individual files of blks that -eatblock can use. I tried to look up the documentation of blkcut by searching btcbase.org/log but I couldn’t find an article or anything explaining its use. There were links to a mailing list on the domain therealbitcoin.org, but the real bitcoin forgot to renew their domain lease and it has since been snatched. So I found the original posting here on thebitcoin.foundation’s archive of the mailing list.
Digging through chat logs, I saw that various people have gone through the process of cutting blocks and then feeding them into eatblocks. I couldn’t find a published script for this, even though people, such as mod6, mentioned they wrote their own. It’s not a difficult exercise, but I still opted to just resync from scratch.
Still, writing my own blkcut tool and the corresponding guide for feeding a node may be in the pipeline. I don’t think eatblock is the right way to go about speeding up a resync. Instead, my intuition is one should create a local web server that feeds bitcoind the perfect responses to its queries for blocks. This is way one can get a fast resync without changing the process from bitcoind's perspective.