Checkpoint Security Model
How BitcoBoost checkpoints work, who controls them, and what they can and cannot do.
Summary: BitcoBoost ships hard-coded checkpoints in the node source code (the same mechanism early Bitcoin used). They are not runtime signatures: they are block hashes compiled into the node, distributed through releases whose integrity is verifiable (public source, SHA256SUMS). A node rejects any fork that would rewrite history below the most recent checkpoint. Node operators can disable them.
What exactly is shipped
| Mechanism | A table of {height, block hash} pairs in src/kernel/chainparams.cpp (checkpointData), inherited from Bitcoin Core. Headers that fork the chain below the latest checkpoint are rejected (bad-fork-prior-to-checkpoint). |
|---|
| Current coverage | 48 checkpoints from the genesis block up the chain; the list is refreshed periodically as blocks accumulate confirmations, and each refresh ships with a rebuilt node. |
|---|
| What it protects against | Deep chain reorganisations below the last checkpoint — the main practical risk for a young Proof-of-Work network with modest hashrate (a temporary majority miner cannot rewrite checkpointed history on nodes that keep checkpoints enabled). |
|---|
| What it does NOT do | It does not protect blocks above the last checkpoint (normal PoW rules apply there — hence the recommended 20 confirmations for exchanges), it does not create coins, and it cannot move funds. A malicious checkpoint could at worst force a node onto a specific historical branch — and it would be publicly visible in the source diff. |
|---|
Governance — the honest answers
| Who decides the checkpoints? | The maintainer, Primaris Group S.r.l.s. They are proposed in the public repository like any other code change: every checkpoint is a visible diff in github.com/Bitcoboost/bitcoboost-core. |
|---|
| Is there a signing key that finalises history at runtime? | No. There is no network message that can add or change checkpoints on running nodes. The only way a checkpoint reaches a node is a new software version that the operator chooses to install. Integrity of the distribution = public source + SHA256SUMS on each release. |
|---|
| Can a compromised key finalise a malicious chain? | There is no runtime key to compromise. An attacker would need to publish a poisoned release and convince operators to install it — the same trust model as any software update, mitigated by public source and reproducible parameters. |
|---|
| Are checkpoints mandatory? | No. Any operator can run bitcoboostd -checkpoints=0 to disable them and validate purely by Proof-of-Work. Exchanges are free to do so. |
|---|
| Incident procedure | If a shipped checkpoint were ever found to conflict with the honest chain, a corrected release would be published immediately and announced on the website, the Bitcointalk thread and Telegram; operators could meanwhile disable checkpoints with -checkpoints=0. |
|---|
| Long-term direction | As independent hashrate grows, checkpoint refreshes will become less frequent and the network will rely on plain PoW depth, like mature chains. |
|---|
Verify it yourself
# the full checkpoint list is public:
https://github.com/Bitcoboost/bitcoboost-core/blob/main/src/kernel/chainparams.cpp
# compare a checkpoint hash against your own node:
bitcoboost-cli getblockhash 14000
