<p>The issue is that you assume a majority attack is an attack that can be prevented. It is not. It is a fundamental breakdown of the security assumptions.</p>
<p>Proof of work (PoW)'s assumption is that the majority of the hashrate will cooperate and converge on a single chain, because it is most financially advantageous thing to do. When that is no longer the case, PoW is broken and we should just move to something else - not to try to fix it up.</p>
<p>You might think that adding checkpoints helps to improve this situation, but consider this:</p>
<ul>
<li><p>Either the checkpoints are created for old blocks (weeks or months old), in which case there is clearly nothing being prevented. A week-deep reorganization would utterly destroy the currency and the trust in it, and not be prevented by this.</p>
</li>
<li><p>Or the checkpoints are created for recent blocks (days or hours perhaps), in which case they may indeed affect what chain is accepted on the network during certain circumstances, but at the same time it is effectively replacing PoW based consensus with &quot;developers-decide&quot; consensus... something that doesn't need a complex peer to peer protocol at all, as effectively developers need to run systems to keep the system in check.</p>
</li>
</ul>
<p>So, either checkpoints have an effect - and change the security assumptions into an uninteresting one, or they don't - and they don't matter.</p>
<p>To answer your question: the primary reason for removing checkpoints is due to the confusion they create. They make people think they're part of the system's security model (like your question shows). That is not the case. It was introduced as a necessity for implementing an optimization (skipping script validation) and an unrelated denial-of-service attack (the disk of a new node being filled with low-difficulty blocks during synchronization). Since some changes in the P2P protocol (headers based synchronization) we no longer need checkpoints to do these things safely.</p>

CC BY-SA 4.0
2018-11-16T10:44:19.250Z
This answer misses the temporal aspect of attacks.  Most coins except Bitcoin can have 51%
user239558
CC BY-SA 4.0
2018-11-16T16:14:19.883Z
@user239558 Then they're broken.
Pieter Wuille
CC BY-SA 4.0
2019-05-26T00:25:19.077Z
There is one kind of majority attack that you didn't mention which checkpoints neatly solve. The construction of a longer but invalid chain. If an attacker constructs a chain with just one invalid transaction, then the rest of the chain forever on matches bitcoin consensus, checkpoints save new nodes from having to validate *both* chains all the way back to that invalid block. The attack is one that would disrupt new nodes - delaying them from entering the network, potentially by a long time. We can't assume Bitcoin will always have the most hashpower.
B T
CC BY-SA 4.0
2019-05-26T02:44:27.820Z
@B T I don't understand. If there is another majority chain (which I think inherently makes the minority one insecure, but ok), the fork will happen at the first block which is invalid to Bitcoin. That's at most one block that needs to be validated and rejected. Its successors won't even be downloaded.
Pieter Wuille
CC BY-SA 4.0
2019-05-26T15:19:03.720Z
You're right that another majority chain puts a minority chain at risk. I see your point there. However, you said "there's at most one block that needs to be validated" - but how do you know which block that is? I suppose .. you could ask other nodes for hints, which is likely to help you figure out where the split happens. I guess that sufficiently solves the problem. Thanks for following up! I'll have to do some thinking on that and probably revise my position.
B T
CC BY-SA 4.0
2019-05-26T16:27:46.593Z
You validate blocks one by one, from parent to child. If at any point you find an invalid block, you mark it plus all its descendants as invalid. If you never notice the block causing the fork simply means you have not seen the fork.
Pieter Wuille
CC BY-SA 4.0
2022-07-06T07:09:48.347Z
"When that is no longer the case, PoW is broken and we should just move to something else". I think the function of PoW would be **degraded**, not broken. Being forced to choose between two alternative chains (or a small number of them) with a significant amount of PoW still allows for a more effective convergence to consensus than having no honest signal at all to coordinate.
Fernando N.
CC BY-SA 4.0
2018-05-31T02:58:41.017Z
2022-01-15T18:58:01.937Z
2022-01-15T18:58:01.937Z
Pieter Wuille
<p>I've read that checkpoints in Bitcoin were removed because they were not preventing any meaningful attack.</p>

<p>Why should a regular checkpoint not prevent majority attacks? For instance, if a checkpoint is made every N blocks and (for example) 3/4 of the hash power agrees, would this not be possible to be used as a mechanism to create a permanent confirmation of the transactions before the checkpoint? Assuming, of course, that clients would check for those checkpoints and enforce them to be included in the valid chain.</p>

CC BY-SA 4.0
2018-05-30T23:13:03.427Z
If N is large then it doesn't help much, because majority attacks can be very damaging even if they only roll back a few blocks.  If N is small then whoever sets the checkpoints has disproportionate power in determining which is the "right" branch of the blockchain, violating the goal of decentralization.
Nate Eldredge
CC BY-SA 4.0
2018-05-31T09:21:06.243Z
Can't the right branch of the blockchain be the one with the more PoW at the time of the checkpoint?
confused00
CC BY-SA 4.0
2018-05-31T10:53:22.503Z
@confused00 Yes, that is what it would be if N was six blocks. In the case of a network split (say someone cut the undersea cables to New Zealand) then when the network rejoins how should this be resolved?
Willtech
<attack><majority-attack><checkpoints>
Why does Bitcoin no longer have checkpoints?
Anon
# Why does Bitcoin no longer have checkpoints?

(Asked by: username_0 on 2018-05-30)

I've read that checkpoints in Bitcoin were removed because they were not preventing any meaningful attack.

Why should a regular checkpoint not prevent majority attacks? For instance, if a checkpoint is made every N blocks and (for example) 3/4 of the hash power agrees, would this not be possible to be used as a mechanism to create a permanent confirmation of the transactions before the checkpoint? Assuming, of course, that clients would check for those checkpoints and enforce them to be included in the valid chain.

**Tags:** attack, majority-attack, checkpoints

> **Comments:**
> **username_1**: If N is large then it doesn't help much, because majority attacks can be very damaging even if they only roll back a few blocks.  If N is small then whoever sets the checkpoints has disproportionate power in determining which is the "right" branch of the blockchain, violating the goal of decentralization.  
> **username_2**: Can't the right branch of the blockchain be the one with the more PoW at the time of the checkpoint?  
> **username_3**: @username_2 Yes, that is what it would be if N was six blocks. In the case of a network split (say someone cut the undersea cables to New Zealand) then when the network rejoins how should this be resolved?  

---

## 1 answers

### Answer by username_4 on 2018-05-31. Score: 25

The issue is that you assume a majority attack is an attack that can be prevented. It is not. It is a fundamental breakdown of the security assumptions.

Proof of work (PoW)'s assumption is that the majority of the hashrate will cooperate and converge on a single chain, because it is most financially advantageous thing to do. When that is no longer the case, PoW is broken and we should just move to something else - not to try to fix it up.

You might think that adding checkpoints helps to improve this situation, but consider this:

* Either the checkpoints are created for old blocks (weeks or months old), in which case there is clearly nothing being prevented. A week-deep reorganization would utterly destroy the currency and the trust in it, and not be prevented by this.
* Or the checkpoints are created for recent blocks (days or hours perhaps), in which case they may indeed affect what chain is accepted on the network during certain circumstances, but at the same time it is effectively replacing PoW based consensus with "developers-decide" consensus... something that doesn't need a complex peer to peer protocol at all, as effectively developers need to run systems to keep the system in check.

So, either checkpoints have an effect - and change the security assumptions into an uninteresting one, or they don't - and they don't matter.

To answer your question: the primary reason for removing checkpoints is due to the confusion they create. They make people think they're part of the system's security model (like your question shows). That is not the case. It was introduced as a necessity for implementing an optimization (skipping script validation) and an unrelated denial-of-service attack (the disk of a new node being filled with low-difficulty blocks during synchronization). Since some changes in the P2P protocol (headers based synchronization) we no longer need checkpoints to do these things safely.

> **Comments:**
> **username_5**: This answer misses the temporal aspect of attacks.  Most coins except Bitcoin can have 51%  
> **username_4**: @username_5 Then they're broken.  
> **username_6**: There is one kind of majority attack that you didn't mention which checkpoints neatly solve. The construction of a longer but invalid chain. If an attacker constructs a chain with just one invalid transaction, then the rest of the chain forever on matches bitcoin consensus, checkpoints save new nodes from having to validate *both* chains all the way back to that invalid block. The attack is one that would disrupt new nodes - delaying them from entering the network, potentially by a long time. We can't assume Bitcoin will always have the most hashpower.  
> **username_4**: @username_6 I don't understand. If there is another majority chain (which I think inherently makes the minority one insecure, but ok), the fork will happen at the first block which is invalid to Bitcoin. That's at most one block that needs to be validated and rejected. Its successors won't even be downloaded.  
> **username_6**: You're right that another majority chain puts a minority chain at risk. I see your point there. However, you said "there's at most one block that needs to be validated" - but how do you know which block that is? I suppose .. you could ask other nodes for hints, which is likely to help you figure out where the split happens. I guess that sufficiently solves the problem. Thanks for following up! I'll have to do some thinking on that and probably revise my position.  
> **username_4**: You validate blocks one by one, from parent to child. If at any point you find an invalid block, you mark it plus all its descendants as invalid. If you never notice the block causing the fork simply means you have not seen the fork.  
> **username_7**: "When that is no longer the case, PoW is broken and we should just move to something else". I think the function of PoW would be **degraded**, not broken. Being forced to choose between two alternative chains (or a small number of them) with a significant amount of PoW still allows for a more effective convergence to consensus than having no honest signal at all to coordinate.  

---

