Is it plausible to make clients checkpoint themselves regularly? This would require the checkpoints to be saved in some external file that is integrity-verifiable.
We had this discussion a little while ago.
If we provide a reasonably fast way of deploying run-time checkpoints, should the application verify them as being from us (the core team) or not?
If they're verifiably from us (on the app side) we're centralising "control". If they're not verified, then a malicious attacker could send his own checkpoints.
But if a malicious attacker has access to your .bitmonero / %APPDATA%/bitmonero folder, or he can convince you to put a file there, why bother with fake checkpoints? He can give you a fake p2pstate.bin or a fake blockchain.bin, so this is a nonsensical attack vector. Plus open checkpoints evaluated at runtime allow us to disappear off the face of the earth and a new group could still deliver checkpoints (ie. a reduction in centralisation).
Thus, flat-file checkpoints seem to answer the immediate need for on-demand checkpointing. There's still a bit of work to do to manage periodic updates, but we're almost there -
https://github.com/monero-project/bitmonero/pull/155With regards to rapidly delivering emergency checkpoints (which is, frankly, a different use-case) we're working on a solution for that too. We expect all of these to be temporary solutions that last for a few years only, after which we can remove them.
