I managed to nuke my copy of the blockchain during development shenanigans. I didn't notice for a while as I had to close down the started-on-bootup Qt client in order to run the version I was developing. Basically, it just wouldn't synch, the log immediately started filling up with orphans and endless consensus disagreements.

I totally failed to persuade the client to read a copied-down blk0001.dat, even if renamed as bootstrap.dat. In the end, I simply ssh'd into my remote-host server, ran cd ~/.slimcoin; tar -zcf /tmp/slmblock.tar.gz blk* database, copied that and it worked, even going from the remote server's Ubuntu 14.04 to my laptop's 16.04. Seems to need the index, dunno why. It's a bit inelegant but what the hey.

So, if you're on an Ubuntu box, there's a solution, might even work on other distros. I've set up a cron job on the server to make a daily tar gzip dump.

https://minkiz.co/noodlings/slm/slm-datadir-blockfiles.tar.gz (655M)

I can't do much with Windows native (IIRC, wine-hosted is no good because the db files are still wrongly endian). OS X (again, IIRC) is okay using Linux bzips. I have created a zip file just in case: https://minkiz.co/noodlings/slm/slm-datadir-blockfiles.zip

There is, ofc, linearize, the preferred solution, which I'm working on. The trouble is that it's so slooooow (I mean days) that it's computationally infeasible on my local kit. So I shovelled it up to the server and let it run there but it just silently failed after some time. (I suppose I should check whether PyPy makes any difference).

Cheers

Graham

Edit: corrected archive compression & file extension