Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 5332. (Read 9723748 times)

+// Copyright (c) 2012-2013 PPCoin developers
 +// Copyright (c) 2013 Primecoin developers
 +// Distributed under conditional MIT/X11 software license,
 +// see the accompanying file COPYING
 +//
 +// The synchronized checkpoint system is first developed by Sunny King for
 +// ppcoin network in 2012, giving cryptocurrency developers a tool to gain
 +// additional network protection against 51% attack.
 +//
 +// Primecoin also adopts this security mechanism, and the enforcement of
 +// checkpoints is explicitly granted by user, thus granting only temporary
 +// consensual central control to developer at the threats of 51% attack.
 +//
 +// Concepts
 +//
 +// 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.
 +//

Hirocoin: Automatic Checkpointing
 master-0.8.6   v0.8.6.3 
…
 0.8.6.2
commit dd5b8bec94b0694b365a4dabe5eeb9b78d025b6d 1 parent 1688b00
HiroSatou HiroSatou authored on Mar 13