Topic: Are checkpoint servers a bad thing for a coin? (Read 1483 times)

We had plenty of discussions about this in the Peercoin community. The reason that PPC has still centralized checkpoints is that the main developer Sunny King is still seeing disabling checkpoints as a risk - other members had other opinions, and NXT is proving that a PoS coin can work without checkpoints.

The reasoning of the pro-checkpoint faction is: When only a few nodes participate in the PoS process (minting/forging) then there is a potential risk of a "PoS 51% attack". So disabling checkpointing is good when you have a high percentage of coins participating in the PoS process, but for brand new coins it can be a risk. I don't remember which coin it was, but in 2013 or 2014 there was a successful attack on a PoS coin.

The problem is obviously that if the checkpoint key is hacked, an attacker could do what he wants with the blockchain, and a malicious developer could do the same. So it is a potential single point of failure.

I already said I see the point about centralization, but no one has explained why all the top ranked POS coins use it but the newbie coins do not.

How and why would checkpoint servers be good for a decentralized crypto coin?

I thought having a checkpoint server for a POS coin was important, but I mentioned it in an altcoin thread since they had a recent fork and did not have a checkpoint server and I got this response.



How and why could a checkpoint server do more harm than good? I am just curious about the details of this.

In the network there can be a privileged node known as 'checkpoint master'.
// This node can send out checkpoint messages signed by the checkpoint master
// key. Each checkpoint is a block hash, representing a block on the blockchain
// that the network should reach consensus on.
//
// Besides verifying signatures of checkpoint messages, each node also verifies
// the consistency of the checkpoints. If a conflicting checkpoint is received,
// it means either the checkpoint master key is compromised, or there is an
// operator mistake. In this situation the node would discard the conflicting
// checkpoint message and display a warning message. This precaution controls
// the damage to network caused by operator mistake or compromised key.
//
// Operations
//
// Checkpoint master key can be established by using the 'makekeypair' command
// The public key in source code should then be updated and private key kept
// in a safe place.
//
// Any node can be turned into checkpoint master by setting the 'checkpointkey'
// configuration parameter with the private key of the checkpoint master key.
// Operator should exercise caution such that at any moment there is at most
// one node operating as checkpoint master. When switching master node, the
// recommended procedure is to shutdown the master node and restart as
// regular node, note down the current checkpoint by 'getcheckpoint', then
// compare to the checkpoint at the new node to be upgraded to master node.
// When the checkpoint on both nodes match then it is safe to switch the new
// node to checkpoint master.
//
// The configuration parameter 'checkpointdepth' specifies how many blocks
// should the checkpoints lag behind the latest block in auto checkpoint mode.
// A depth of 0 is the strongest auto checkpoint policy and offers the greatest
// protection against 51% attack. A negative depth means that the checkpoints
// should not be automatically generated by the checkpoint master, but instead
// be manually entered by operator via the 'sendcheckpoint' command. The manual
// mode is also the default mode (default value -1 for checkpointdepth).
//
// Command 'enforcecheckpoint' and configuration parameter 'checkpointenforce'
// are for the users to explicitly consent to enforce the checkpoints issued
// from checkpoint master. To enforce checkpoint, user needs to either issue
// command 'enforcecheckpoint true', or set configuration parameter
// checkpointenforce=1. The current enforcement setting can be queried via
// command 'getcheckpoint', where 'subscribemode' displays either 'enforce'
// or 'advisory'. The 'enforce' mode of subscribemode means checkpoints are
// enforced. The 'advisory' mode of subscribemode means checkpoints are not
// enforced but a warning message would be displayed if the node is on a
// different blockchain fork from the checkpoint, and this is the default mode.

are you sure there are checkpoint-servers?
this would imply that some nodes have more control than others?

if thats true i'd avoid them like a plague (well i dont know / like POS anyway)

...

{
Do these steps to setup a checkpoint server:
assuming you've already compiled, open your client. open the debug window(or from the command prompt/shell if using daemon)
type

you will get an output like this



save this in a text document.

close the client.

open your configuration file for your coin(if you haven't created one, now would be a great time to start.). paste in your privatekey in the following format

Code:

checkpointkey=

now save and exit, then restart the client.

now you must reflect this in the sourcecode, by adding your public key as the checkpoint master. without this, it will not work at all.
checkpoints.cpp
find this and add your public key( do not add your private key in the source, only in your conf file.

Code:

const std::string CSyncCheckpoint::strMasterPubKey =

there will be a public key already there. delete it, and put yours in its place. now save, and recompile the clients. congratulations, you are finished.
...

What type of security issues are you worried about that the checkpoint server would solve for you?

I see your point, I really do. But with this line of thinking, just having a dev with an official github repo would be centralization as well. When there is a fork, the dev makes the final call about which chain is valid and they hardcode a checkpoint, so it seems more secure to have auto checkpoints.

Checkpoint servers are a centralized point of failure and in my opinion are not needed in most cases. I have seen checkpoint servers orphan blocks that shouldn't have been orphaned and also seen them roll back chains that should not have been rolled back. The blockchain rules are enough to keep the chain secure.

i havent look it up (and probably wont because i dont like pos anyway), but its easy to see why people think its bad: centralization.

a dev should not control which chain is the best / longest. that something miners or (in case of pos) stakeholders decide.
if he runs special nodes there is no need for nodes in the first place. he could just run a webservice with the balances of his users: there isnt any difference then.

Yes, like I said most popular POS coins use it. Check the source on github if you don't believe me. It is usually near the bottom of checkpoints.cpp

A lot of new devs do not understand how to implement it so they just erase it and leave "" in its place.


I just don't understand how it could "do more harm than good". Aside from centralization maybe....but if thats the case why do so many coins use it?


edit: also, earlz always mentions it when he does a review of a new coin if it does not have one set properly.


Google:  earlz checkpoint pubkey bitcointalk


To see what I mean

are you sure there are checkpoint-servers?
this would imply that some nodes have more control than others?

if thats true i'd avoid them like a plague (well i dont know / like POS anyway)

In most POS altcoins, not in bitcoin there is this line in checkpoints.cpp

// ppcoin: sync-checkpoint master key
const std::string CSyncCheckpoint::strMasterPubKey ="you pubkey part of keypair goes here"

and then in the checkpoint servers  coin config you add checkpointkey=long-ass-privatekey-goes-here

With the actual keypair being replace in the sections after the = symbol

Most popular POS coins have this.

Checkpoint servers often do more harm than good.