Description
Issue and Steps to Reproduce
It takes only a fraction of a second to crash lightningd, but many hours to sync. I'd prefer if it at least attempt to save some of the sync state so that when it recovers, it can resume syncing at a less drastically long sync size.
I understand that one of the things you don't want with Lightning Network is a node using old state on a channel.
The hardball way to get around that is to do periodic saves of state, and then when restarting, load the state from a fresh perspective and sync from that periodic save point. The only items that need to be saved are those items that the node would recover upon a restart by scanning the blocks. One idea is to simply save every relevant transaction in the blockchain as the node runs, and then know the last fully saved transaction block, and upon restart, load all of those transactions instead of parsing full blocks; that is slower than saving a state and resuming from that state, but it might just be faster than going through full blocks and the code would be less intense. A hybrid approach of doing both would work, too. As implementation, both could be programmed, with attention paid to the journaling of transactions first, and get it running first, then keep saving state but not using it to resume, slowly implementing a background "what if" state checker that checks to see if saved state equals journaled transaction state recovery, just to test the idea. Ideas?
getinfo output
{ "id" : "031c527494f295220d26a1814c18e7db3f4f03203ce1a53a0b74b52ed570a3972a",
[
"version" : "v0.5.2-2016-11-21-2207-g31b9b6b", "blockheight" : 506218, "network" : "bitcoin" }