Checkpoints seem like a crucial part of the security & validation apparatus in Bitcoin. Is there a written policy in place, among the developers defining the maximum interval between checkpoints?

What happens when the Bitcoin client becomes mature and releases are fewer and farther between. Has some other mechanism for checkpoint-like functionality been proposed?

2 Answers 2


Checkpoints serve two purposes:

  • They hardcode a historic part of the chain
  • They allow us to disable a check (expensive signature checking) in that historic part.

I personally dislike the first part, as it requires users to trust the software they're downloading contains the right checkpoints. Of course, they're already trusting the code anyway in much more substantial ways, but just requiring some piece of data to be updated frequently in a trusted way, to keep up with the block chain validation performance feels wrong to me. Of course, we can't have the second part without the first. Or can we?

There is a proposed idea, which isn't is implemented, to modify the synchronization mechanism to consist of two steps:

  • In a first step, only headers are downloaded and verified, in much the same way as blocks are now downloaded and verified. This will result in the client knowing the best valid chain of blocks, except it won't know whether the transactions in it are valid.
  • In a second step, the actual blocks along this chain are downloaded and verified. Such a mechanism has several advantages, including being able to distribute the synchronization over several nodes, and not risking downloading side chains (sometimes called orphans).

In addition, it could have a rule "Do not validate signature checks if a block has N blocks on top of it". Since the client already knows there is a valid chain before doing the full transaction validation, there is no need for checkpoints to prevent getting a wrong chain.

Of course, this will have to be thought about a lot before implementing it, but I believe it will allow us to not rely on checkpoints anymore.

EDIT: Benefits of checkpoints can be realized in better ways like assumevalid .

Recent versions(>= 0.14) of bitcoin core come with option -assumevalid <safe-block> . This gives the benefit of skipping signature validation upto the safe-block without hardcoding the history. If another heavier chain is seen which does not contain the safe block, the bitcoin software will correctly reorg to the other chain. More Info: What are the trust assumptions in --assumed-valid in bitcoin core 0.14?

  • Has "Do not validate signature checks if a block has N blocks on top of it" been enabled since then?
    – Murch
    Aug 19, 2015 at 18:12
  • Thought the question targets alternatives to hard coded checkpoints, that would be a concept of creating regular dynamic checkpoints. Feb 26, 2022 at 9:35

AFAIK they are not crucial at all.

They are simply one more safety check, but without them the blockchain should work well enough anyway...

  • They seem quite important in mitigating a massive >51% CPU attack funded by a large corporate or government entity. I think that scenario is not beyond the realm of imagination, as BitCoin grows in size and influence. Particularly given that the cost of mounting such an attack may be only in the 10's of millions of dollars.
    – gosmond
    Feb 22, 2013 at 0:32
  • @gosmond what are you talking about? Of course such an attack is not possible...
    – o0'.
    Feb 22, 2013 at 10:50
  • @gosmond and despite that, the checkpoints still wouldn't solve that problem.
    – o0'.
    Feb 22, 2013 at 18:15
  • 1
    If checkpoints ever prevent a large reorganization, they would 1) prove that the PoW consensus mechanism has utterly failed 2) cause a fork in the networj between those who have that checkpoint and don't. May 5, 2015 at 7:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.