<p>You are correct that any client which sees two different forks can easily determine which one is longer.  But consider the following possibilities:</p>

<ul>
<li><p><strong>The node might never see the longer fork.</strong>  This can happen in case of a <a href="https://bitcoin.stackexchange.com/questions/tagged/sybil-attack">Sibyl attack</a>, where the attacker has control over the victim's Internet connection and arranges that the victim only connects to evil nodes.  These evil nodes will only send blocks that are part of the shorter, malicious fork, and the victim will assume that this fork is the "real" chain because there is nothing else to compare it to.   So the victim will believe the attacker's view of the transaction record, at least until they manage to get connected to an honest node.  Checkpoints ensure that such an attacker can only manipulate the victim's view of history as far back as the latest checkpoint, which at least puts some limit on the damage that can be caused.</p></li>
<li><p><strong>The longer fork might be the "evil" one.</strong>  This could happen in the case of a 51% attack, where an attacker who controls more hashing power than the rest of the network decides to fork the chain and "rewrite history" from some point in the past.  With their hash power majority, they can eventually make their fork longer than the "real" one.  A checkpoint ensures that they can only rewrite as far back as the checkpoint. </p></li>
</ul>

<p>In each case, this is a rather minimal restriction on the attack; the ability to rewrite history back to the last checkpoint is still devastating.  But it might help in reducing the chaos until the victim can connect to an honest node (in the Sibyl case) or until other protocol changes are adopted (in the 51% case).</p>

<p>See  also <a href="https://bitcoin.stackexchange.com/questions/40552/do-checkpoints-in-the-block-chain-help-to-avoid-a-51-attack-that-rewrites-the-e">Do checkpoints in the block chain help to avoid a 51% attack that rewrites the entire blockchain?</a></p>

<p>These apply to both full nodes and thin clients.</p>

<p>Also, as mentioned in the post you linked, if you know you don't need to worry about these attacks, then you can decide not to verify every last detail of the chain before the checkpoint, which will save computation and let you sync the blockchain faster.</p>

CC BY-SA 3.0
2017-08-02T19:26:34.960Z
I downvoted. Checkpoints absolutely don't help in case the longer fork is the evil one. In that case the correct solution is abandoning PoW, not trying to patch it up with checkpoints (which effective make the checkpoints authors the centralized party choosing the valid chain rather than PoW).
Pieter Wuille
CC BY-SA 3.0
2017-08-02T19:40:54.917Z
@PieterWuille: Yes, I didn't mean to imply that checkpoints would be any kind of a real fix in that case.  It is true, is it not, that checkpoints do keep the 51% attacker from rewriting history before the checkpoint?  But even without that ability, the attack can still be devastating.  I will try to rephrase.
Nate Eldredge
CC BY-SA 3.0
2017-08-02T20:28:48.800Z
@PieterWuille Well, I think we should help each other by correcting each other not punishing. It'd be great if you upvote him, as he put effort and time to provide the answer! Thanks :)
user153465
CC BY-SA 3.0
2017-08-02T20:31:52.810Z
@user153465 I don't intend to punish, but the goal of a Q&A site is to make the best questions and answers rise to the top. I will downvote things that I believe to be wrong or besides the point. I'm also honest about the reasons for doing so, and can change my vote if my concerns are addressed.
Pieter Wuille
CC BY-SA 3.0
2017-08-02T20:33:13.000Z
@user153465: I don't feel punished - upvotes and downvotes are simply a way for everyone to express their opinion as to how accurate and helpful an answer is.  I respect Pieter's opinion and appreciate that he gave an explanation.  If he feels differently about the post after my edit, he is free to change his vote, or not.  But on Stack Exchange we generally do not criticize each others' voting, nor ask for anyone to vote in a particular way.
Nate Eldredge
CC BY-SA 3.0
2017-08-02T15:34:51.383Z
2017-08-02T19:46:08.513Z
2017-08-02T19:46:08.513Z
Nate Eldredge
<p>I'm aware of this <a href="https://bitcoin.stackexchange.com/questions/1797/what-are-checkpoints">post</a> and this <a href="https://bitcointalk.org/index.php?topic=194078.0" rel="nofollow noreferrer">one</a>.</p>

<p>If it's used to prevent an attacker from forking old blocks (or chain), then a client can detect it because the fork length would be shorter than the length of the existing (correct) chain. </p>

<p><strong>Question</strong>: What exactly would happen if we don't use checkpoints?</p>

<p>Also, are they only for thin clients?</p>

<client><checkpoints>
What kind of attacks do exactly check-points prevent?
user153465
# What kind of attacks do exactly check-points prevent?

(Asked by: username_0 on 2017-08-02)

I'm aware of this [post](https://bitcoin.stackexchange.com/questions/1797/what-are-checkpoints) and this [one](https://bitcointalk.org/index.php?topic=194078.0).

If it's used to prevent an attacker from forking old blocks (or chain), then a client can detect it because the fork length would be shorter than the length of the existing (correct) chain.

**Question**: What exactly would happen if we don't use checkpoints?

Also, are they only for thin clients?

**Tags:** client, checkpoints


---

## 1 answers

### Answer by username_1 on 2017-08-02. Score: 2 | Accepted answer

You are correct that any client which sees two different forks can easily determine which one is longer. But consider the following possibilities:

* **The node might never see the longer fork.** This can happen in case of a [Sibyl attack](https://bitcoin.stackexchange.com/questions/tagged/sybil-attack), where the attacker has control over the victim's Internet connection and arranges that the victim only connects to evil nodes. These evil nodes will only send blocks that are part of the shorter, malicious fork, and the victim will assume that this fork is the "real" chain because there is nothing else to compare it to. So the victim will believe the attacker's view of the transaction record, at least until they manage to get connected to an honest node. Checkpoints ensure that such an attacker can only manipulate the victim's view of history as far back as the latest checkpoint, which at least puts some limit on the damage that can be caused.
* **The longer fork might be the "evil" one.** This could happen in the case of a 51% attack, where an attacker who controls more hashing power than the rest of the network decides to fork the chain and "rewrite history" from some point in the past. With their hash power majority, they can eventually make their fork longer than the "real" one. A checkpoint ensures that they can only rewrite as far back as the checkpoint.

In each case, this is a rather minimal restriction on the attack; the ability to rewrite history back to the last checkpoint is still devastating. But it might help in reducing the chaos until the victim can connect to an honest node (in the Sibyl case) or until other protocol changes are adopted (in the 51% case).

See also [Do checkpoints in the block chain help to avoid a 51% attack that rewrites the entire blockchain?](https://bitcoin.stackexchange.com/questions/40552/do-checkpoints-in-the-block-chain-help-to-avoid-a-51-attack-that-rewrites-the-e)

These apply to both full nodes and thin clients.

Also, as mentioned in the post you linked, if you know you don't need to worry about these attacks, then you can decide not to verify every last detail of the chain before the checkpoint, which will save computation and let you sync the blockchain faster.

> **Comments:**
> **username_2**: I downvoted. Checkpoints absolutely don't help in case the longer fork is the evil one. In that case the correct solution is abandoning PoW, not trying to patch it up with checkpoints (which effective make the checkpoints authors the centralized party choosing the valid chain rather than PoW).  
> **username_1**: @username_2: Yes, I didn't mean to imply that checkpoints would be any kind of a real fix in that case.  It is true, is it not, that checkpoints do keep the 51% attacker from rewriting history before the checkpoint?  But even without that ability, the attack can still be devastating.  I will try to rephrase.  
> **username_0**: @username_2 Well, I think we should help each other by correcting each other not punishing. It'd be great if you upvote him, as he put effort and time to provide the answer! Thanks :)  
> **username_2**: @username_0 I don't intend to punish, but the goal of a Q&A site is to make the best questions and answers rise to the top. I will downvote things that I believe to be wrong or besides the point. I'm also honest about the reasons for doing so, and can change my vote if my concerns are addressed.  
> **username_1**: @username_0: I don't feel punished - upvotes and downvotes are simply a way for everyone to express their opinion as to how accurate and helpful an answer is.  I respect username_2's opinion and appreciate that he gave an explanation.  If he feels differently about the post after my edit, he is free to change his vote, or not.  But on Stack Exchange we generally do not criticize each others' voting, nor ask for anyone to vote in a particular way.  

---

