<p>AFAIK they are not crucial at all.</p>

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

CC BY-SA 3.0
2013-02-22T00:32:38.313Z
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
CC BY-SA 3.0
2013-02-22T10:50:30.487Z
@gosmond what are you talking about? Of course such an attack is not possible...
o0'.
CC BY-SA 3.0
2013-02-22T12:56:32.157Z
http://bitcoin.stackexchange.com/questions/4998/how-much-would-it-cost-for-a-government-to-undermine-bitcoins?rq=1
gosmond
CC BY-SA 3.0
2013-02-22T18:15:37.623Z
@gosmond and despite that, the checkpoints still wouldn't solve that problem.
o0'.
CC BY-SA 3.0
2015-05-05T07:09:36.260Z
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.
Pieter Wuille
CC BY-SA 3.0
2013-02-21T10:43:58.040Z
2013-02-21T10:43:58.040Z
o0'.
<p>Checkpoints serve two purposes:</p>
<ul>
<li>They hardcode a historic part of the chain</li>
<li>They allow us to disable a check (expensive signature checking) in that historic part.</li>
</ul>
<p>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?</p>
<p>There is a <s>proposed</s> idea, which <s>isn't</s> is implemented, to modify the synchronization mechanism to consist of two steps:</p>
<ul>
<li>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.</li>
<li>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).</li>
</ul>
<p>In addition, it could have a rule &quot;Do not validate signature checks if a block has N blocks on top of it&quot;. 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.</p>
<p>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.</p>
<p>EDIT:
Benefits of checkpoints can be realized in better ways like <code>assumevalid</code> .</p>
<p>Recent versions(&gt;= 0.14) of bitcoin core come with option <code>-assumevalid &lt;safe-block&gt;</code> . 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: <a href="https://bitcoin.stackexchange.com/questions/59940/what-are-the-trust-assumptions-in-assumed-valid-in-bitcoin-core-0-14">What are the trust assumptions in --assumed-valid in bitcoin core 0.14?</a></p>

CC BY-SA 3.0
2015-08-19T18:12:39.023Z
Has "Do not validate signature checks if a block has N blocks on top of it" been enabled since then?
Murch
CC BY-SA 4.0
2022-02-26T09:35:28.860Z
Thought the question targets alternatives to hard coded checkpoints, that would be a concept of creating regular dynamic checkpoints.
Sam Ginrich
CC BY-SA 4.0
2013-02-21T11:02:10.767Z
2023-03-10T14:20:55.803Z
2023-03-10T14:20:55.803Z
Pieter Wuille
<p>Checkpoints seem like a crucial part of the security &amp; validation apparatus in Bitcoin. Is there a written policy in place, among the developers defining the maximum interval between checkpoints?</p>

<p>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?</p>

<blockchain><security><bitcoin-core><verification><checkpoints>
What alternatives are there to hardcoding checkpoints into the Bitcoin client?
gosmond
# What alternatives are there to hardcoding checkpoints into the Bitcoin client?

(Asked by: username_0 on 2013-02-21)

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?

**Tags:** blockchain, security, bitcoin-core, verification, checkpoints


---

## 2 answers

### Answer by username_2 on 2013-02-21. Score: 9 | Accepted answer

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`  . 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?](https://bitcoin.stackexchange.com/questions/59940/what-are-the-trust-assumptions-in-assumed-valid-in-bitcoin-core-0-14)

> **Comments:**
> **username_3**: Has "Do not validate signature checks if a block has N blocks on top of it" been enabled since then?  
> **username_4**: Thought the question targets alternatives to hard coded checkpoints, that would be a concept of creating regular dynamic checkpoints.  

---

### Answer by username_1 on 2013-02-21. Score: 1

AFAIK they are not crucial at all.

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

> **Comments:**
> **username_0**: 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.  
> **username_1**: @username_0 what are you talking about? Of course such an attack is not possible...  
> **username_0**: http://bitcoin.stackexchange.com/questions/4998/how-much-would-it-cost-for-a-government-to-undermine-bitcoins?rq=1  
> **username_1**: @username_0 and despite that, the checkpoints still wouldn't solve that problem.  
> **username_2**: 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.  

---

