Centralized PoS Checkpointing

[r3rcloak]

The majority of PoS coins, including PeerCoin (on which Cloak is indirectly based) contain a centralized PoS checkpointing mechanism. This is essentially a centralized server that nodes connect to to determine the latest PoS sync checkpoint.

As far as I'm aware, this system is not currently setup, configured or running for Cloak. Centralized checkpointing relies on a public/private keypair (associated with the checkpoint server and with the pubkey included in the codebase) which is used to authenticate the checkpoints and determine they did indeed come from the trusted centralized server.

It needs to be determined if this centralized checkpointing mechanism is important for secuity, and if so, we will likely need to generate new keys and set-up a new centralized checkpointing server. PeerCoin is likely a good source for information on this subject and the PeerCoin wiki is an ideal starting point:

http://wiki.peercointalk.org/index.php?title=Main_Page

As an aside, decentralized checkpointing has been discussed in the PoS coin realm for some time, but I'm unaware of an deployed implementation.

[anorakthagreat]

Well, there's 3 types of checkpoints that I know of - hardened, centralized and elected, in the order of priority.

1. Hardened are the ones picked by social consensus or developers, those are just hardcoded into the clients - noone can override this without a hard-fork based on social consensus (aka all users agree)
2. Centralized are, expectedly, the ones set by a central entity or entities and broadcasted to the network as a definite truth. Oracles, if you wish. If multiple, these can make a closed vote decision among themselves or have an established trust/consensus to accept one "from the inner circle".
3. Elected are the latest idea of trustless checkpointing, where one-time checkpointing power is algorithmically given to an elected node, based on certain elements and properties of a node that define trust - online time, number of previous blocks minted, number of transactions, orphan count, block sign/flight time, etc (needs to be a complex index). This should work like a consensus peer-score system, but needs restrictive details like re-election rules, main-chain vs. fork checkpointing, depth (you shouldn't be allowed to checkpoint the current/last few blocks; consider reorg and checkpoint timing attacks). You can see this gets complex, but it's the most promising - haven't seen an implementation of this yet.

[r3rcloak]

Thanks Anorak. 'Elected' does sound promising for the future.

[r3rcloak]

"had a quick scan over the sync checkpoint code. it looks like it's a case of running a centralized daemon and giving it the private key via the [-checkpointkey] commandline arg.

so shouldn't be too hard to set up/configure once we generate a new sync checkpoint keypair. changing the key shouldn't cause any issues as far as I can see..."