<p>Update on this as of time of writing, just to clarify more specifically upon the other answer: dependence on checkpoints in the security model has been significantly reduced, they are only used in one very specific case now. That case is just to ignore forks from the chain early on, before the most recently seen checkpoint. When a node has seen a block it recognises as a checkpoint, any further blocks received below that height will be ignored.</p>

<p>You can see this here: <a href="https://github.com/bitcoin/bitcoin/blob/0dfc25f82a01d9fec26380d95915df31e1fe2c02/src/validation.cpp#L3107" rel="noreferrer">https://github.com/bitcoin/bitcoin/blob/0dfc25f82a01d9fec26380d95915df31e1fe2c02/src/validation.cpp#L3107</a></p>

<p>It is a long term goal of removing the checkpoints entirely, because they are a source of confusion over the security model and power the developers have. But currently the role they serve is to prevent low difficulty header flooding attacks, and there has been no alternative solution proposed yet (that I know of).</p>

CC BY-SA 3.0
2018-03-14T02:55:40.000Z
so every node maintains a list of checkpoints? who decides which blocks get added to the list of checkpoints?
fdzsfhaS
CC BY-SA 3.0
2018-03-14T05:55:43.853Z
@Auburn the list of checkpoints is hardcoded here: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L153-L167
No new checkpoints are ever added anymore, the last was added on Jul 16, 2014
meshcollider
CC BY-SA 4.0
2021-10-05T07:24:37.947Z
> there has been no alternative solution proposed yet (that I know of).

Sure there have been. E.g. increasing the minimum difficulty for any alternative chain. Or changing the logic used to fetch headers to be able to explorer a competing fork without saving it.
G. Maxwell
CC BY-SA 4.0
2023-02-01T22:33:14.300Z
2022 update: an alternative technique to prevent low difficulty header flooding that does not rely on checkpoints (only on the even weaker minchainwork value) has been merged: https://github.com/bitcoin/bitcoin/pull/25717
Pieter Wuille
CC BY-SA 3.0
2018-02-14T23:41:43.543Z
2018-02-14T23:41:43.543Z
meshcollider
<p>Bitcoin consensus algo is probabilistic (rather than deterministic) so in theory there is always the possibility of reversibility. The checkpoint  gets around that by setting how far back it with even consider looking for blocks to verify.</p>

CC BY-SA 4.0
2018-11-18T18:08:45.640Z
2018-11-18T18:08:45.640Z
user898617
<p>AIK there‘s one big use case so far for checkpoints and there‘s actually no golden path to achieve that otherwise.</p>
<p>Let‘s say one has a really really lot of computing power and intentionally or accidentally starts mining at a very low difficulty. Then all nodes were „forced by the rules of consensus“ to check that blocks for validity even there is praktically low to now chance they catch up the entire blockchain. On a time critical node that kind of behaviour could at least create disturbance.</p>
<p>Checkpoints are a tool against that. The node will only check higher blocks than the last checkpoint anf hence „focus on real (trans)actions on the net“.</p>

CC BY-SA 4.0
2023-02-01T21:20:51.700Z
This hasn't been the case since the introduction of headers-first synchronization in 2014 (https://github.com/bitcoin/bitcoin/pull/4468), which meant that blocks won't even be fully downloaded in case they're not on a chain of headers that leads to a tip with a promising amount of work. This did leave open a weaker version of that (header spam), but that has been addressed since the introduction of headers presync (https://github.com/bitcoin/bitcoin/pull/25717) last year.
Pieter Wuille
CC BY-SA 4.0
2023-02-03T00:08:38.943Z
Thanks for the deeper insights @PieterWuille it is hard to keep pace with the developments. I appreciate to get deeper understanding. 

Well, checkpoints are now obsolete. Are they already removed? The Go implementation btcsuite/btcd still supports it.
jagottsicher
CC BY-SA 4.0
2023-02-03T01:41:09.870Z
They're not removed no; there is little harm in leaving them around, but they'll likely be removed from Bitcoin Core at some point. I also don't think btcd has anything like Core's header presync logic, but whether particular software implements and/or keeps something like these checkpoints is their own decision.
Pieter Wuille
CC BY-SA 4.0
2023-01-31T23:44:41.370Z
2023-01-31T23:44:41.370Z
jagottsicher
<p>The checkpoints are hard coded into the standard client. The concept is, that the standard client will accept all transactions up to the checkpoint as valid and irreversible. If anyone tries to fork the blockchain starting from a block before the checkpoint, the client will not accept the fork. This makes those blocks "set in stone".</p>

CC BY-SA 3.0
2014-09-14T20:47:31.027Z
We really plan to get rid of checkpoints, or at least significantly reduce their power. They don't actually add any security (if they would actually affect the chain, the system is already broken).
Pieter Wuille
CC BY-SA 3.0
2015-05-31T21:05:11.500Z
@PieterWuille@ThePiachu: I didn't find any checkpoints hardcoded in main.cpp, checkpoints.h, checkpoints.cpp...Can you tell where the first checkpoint is placed?
Aliakbar Ahmadi
CC BY-SA 3.0
2015-06-01T21:04:35.733Z
They are chain-specific data, and have thus been moved to chainparams.cpp now.
Pieter Wuille
CC BY-SA 3.0
2017-08-02T10:21:32.513Z
@ThePiachu Thanks for the answer. But, the question is, in a case where there's no checkpoint,  why would client accept a chain shorter than what he already has?
user153465
CC BY-SA 3.0
2011-11-02T01:05:41.657Z
So a checkpoint is usually created everytime the client is updated?
nmat
CC BY-SA 3.0
2011-11-02T01:12:04.963Z
As far as I know, yes, but it is all in the hands of the developers.
ThePiachu
CC BY-SA 3.0
2012-08-21T22:02:27.857Z
Would there be any way to make this behavior official? Something like "If the block was published to the network over a year ago, it is set in stone" which does not rely on the developers? This seem to be one of the few places where Bitcoin developers have a lot of authority, and it seems they generally work to keep that authority minimal.
Daniel H
CC BY-SA 3.0
2012-08-22T07:02:53.970Z
@DanielH I don't see why some automatic algorithm couldn't be implemented that would be choosing suitable checkpoints during each code update. I guess you can propose such a feature on the forum or the github project page.
ThePiachu
CC BY-SA 3.0
2011-10-29T20:18:25.380Z
2011-10-29T20:18:25.380Z
ThePiachu
<p>I often read that checkpoints protect the network from a 51% attack because an attacker cannot reverse transactions made before the last checkpoint.</p>

<p>How exactly does this checkpoint mechanism work? And who creates the checkpoints?</p>

<blockchain><security><terminology><revert-transaction><checkpoints>
What are checkpoints?
nmat
# What are checkpoints?

(Asked by: username_0 on 2011-10-29)

I often read that checkpoints protect the network from a 51% attack because an attacker cannot reverse transactions made before the last checkpoint.

How exactly does this checkpoint mechanism work? And who creates the checkpoints?

**Tags:** blockchain, security, terminology, revert-transaction, checkpoints


---

## 4 answers

### Answer by username_7 on 2011-10-29. Score: 30 | Accepted answer

The checkpoints are hard coded into the standard client. The concept is, that the standard client will accept all transactions up to the checkpoint as valid and irreversible. If anyone tries to fork the blockchain starting from a block before the checkpoint, the client will not accept the fork. This makes those blocks "set in stone".

> **Comments:**
> **username_0**: So a checkpoint is usually created everytime the client is updated?  
> **username_7**: As far as I know, yes, but it is all in the hands of the developers.  
> **username_10**: Would there be any way to make this behavior official? Something like "If the block was published to the network over a year ago, it is set in stone" which does not rely on the developers? This seem to be one of the few places where Bitcoin developers have a lot of authority, and it seems they generally work to keep that authority minimal.  
> **username_7**: @username_10 I don't see why some automatic algorithm couldn't be implemented that would be choosing suitable checkpoints during each code update. I guess you can propose such a feature on the forum or the github project page.  
> **username_4**: We really plan to get rid of checkpoints, or at least significantly reduce their power. They don't actually add any security (if they would actually affect the chain, the system is already broken).  
> **username_8**: @username_4@username_7: I didn't find any checkpoints hardcoded in main.cpp, checkpoints.h, checkpoints.cpp...Can you tell where the first checkpoint is placed?  
> **username_4**: They are chain-specific data, and have thus been moved to chainparams.cpp now.  
> **username_9**: @username_7 Thanks for the answer. But, the question is, in a case where there's no checkpoint,  why would client accept a chain shorter than what he already has?  

---

### Answer by username_1 on 2018-02-14. Score: 9

Update on this as of time of writing, just to clarify more specifically upon the other answer: dependence on checkpoints in the security model has been significantly reduced, they are only used in one very specific case now. That case is just to ignore forks from the chain early on, before the most recently seen checkpoint. When a node has seen a block it recognises as a checkpoint, any further blocks received below that height will be ignored.

You can see this here: <https://github.com/bitcoin/bitcoin/blob/0dfc25f82a01d9fec26380d95915df31e1fe2c02/src/validation.cpp#L3107>

It is a long term goal of removing the checkpoints entirely, because they are a source of confusion over the security model and power the developers have. But currently the role they serve is to prevent low difficulty header flooding attacks, and there has been no alternative solution proposed yet (that I know of).

> **Comments:**
> **username_2**: so every node maintains a list of checkpoints? who decides which blocks get added to the list of checkpoints?  
> **username_1**: @Auburn the list of checkpoints is hardcoded here: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L153-L167 No new checkpoints are ever added anymore, the last was added on Jul 16, 2014  
> **username_3**: > there has been no alternative solution proposed yet (that I know of).  Sure there have been. E.g. increasing the minimum difficulty for any alternative chain. Or changing the logic used to fetch headers to be able to explorer a competing fork without saving it.  
> **username_4**: 2022 update: an alternative technique to prevent low difficulty header flooding that does not rely on checkpoints (only on the even weaker minchainwork value) has been merged: https://github.com/bitcoin/bitcoin/pull/25717  

---

### Answer by username_5 on 2018-11-18. Score: 0

Bitcoin consensus algo is probabilistic (rather than deterministic) so in theory there is always the possibility of reversibility. The checkpoint gets around that by setting how far back it with even consider looking for blocks to verify.


---

### Answer by username_6 on 2023-01-31. Score: 0

AIK there‘s one big use case so far for checkpoints and there‘s actually no golden path to achieve that otherwise.

Let‘s say one has a really really lot of computing power and intentionally or accidentally starts mining at a very low difficulty. Then all nodes were „forced by the rules of consensus“ to check that blocks for validity even there is praktically low to now chance they catch up the entire blockchain. On a time critical node that kind of behaviour could at least create disturbance.

Checkpoints are a tool against that. The node will only check higher blocks than the last checkpoint anf hence „focus on real (trans)actions on the net“.

> **Comments:**
> **username_4**: This hasn't been the case since the introduction of headers-first synchronization in 2014 (https://github.com/bitcoin/bitcoin/pull/4468), which meant that blocks won't even be fully downloaded in case they're not on a chain of headers that leads to a tip with a promising amount of work. This did leave open a weaker version of that (header spam), but that has been addressed since the introduction of headers presync (https://github.com/bitcoin/bitcoin/pull/25717) last year.  
> **username_6**: Thanks for the deeper insights @username_4 it is hard to keep pace with the developments. I appreciate to get deeper understanding.   Well, checkpoints are now obsolete. Are they already removed? The Go implementation btcsuite/btcd still supports it.  
> **username_4**: They're not removed no; there is little harm in leaving them around, but they'll likely be removed from Bitcoin Core at some point. I also don't think btcd has anything like Core's header presync logic, but whether particular software implements and/or keeps something like these checkpoints is their own decision.  

---

