<p>There are two things :</p>

<ul>
<li>Why are checkpoints needed in the first place,</li>
<li>Why do the checkpointed blocks need to adhere to the standards you are quoting (which is your question)</li>
</ul>

<p>I don't think checkpoints are required at all or useful in any way, there has been some debate around this, the fact remains that checkpoints are still present in the Satoshi implementation.</p>

<p>I believe there is no specific reason why the checkpointed blocks must have "reasonable timestamps" or not contain "strange transactions". The only reason I can think of is to not confuse someone reviewing the checkpointed blocks. As you said, such a block would still be downloaded and properly validated. So I think it has more to do with cosmetics and clarity than with an actual technical constraint. </p>

<p>(Also note that "strange transactions" doesn't really mean much, it does not seem to be defined as a transaction that passes the <code>IsStandard</code> check)</p>

CC BY-SA 3.0
2013-02-02T20:25:30.343Z
"I don't think checkpoints are required at all or useful in any way," I actually disagree on this point, as my client grabs the blockchain quite a lot faster when getting blocks before a checkpoint.
Nick ODell
CC BY-SA 3.0
2013-02-02T21:18:07.160Z
AFAIK checkpoints are not used to improve performance of the initial chain download, and even if it did your client would still have to scan each single block and look at each single transaction in it in order to find transactions that are relevant to its wallet.
David
CC BY-SA 3.0
2013-02-02T21:29:54.420Z
True, but it doesn't need to verify the signatures. I don't know how significant that is performance-wise.
Nick ODell
CC BY-SA 3.0
2013-02-02T23:00:43.483Z
Verifying the signature takes a negligible amount of time, it's looking the inputs up that does. The initial download performance is I/O bound, not CPU bound.
David
CC BY-SA 3.0
2013-02-02T23:10:10.530Z
That makes sense. You mention that the `IsStandard` check fails on transactions in some checkpoints. Do you have any examples?
Nick ODell
CC BY-SA 3.0
2013-02-03T09:19:47.497Z
I never said that :)
David
CC BY-SA 3.0
2013-02-03T16:23:50.723Z
let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/7366/discussion-between-nick-odell-and-david)
Nick ODell
CC BY-SA 3.0
2013-02-02T16:34:09.780Z
2013-02-02T16:34:09.780Z
David
<p>In the source code of the standard client, <a href="https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp#L17" rel="nofollow"><code>checkpoints.cpp</code></a> has this comment:</p>

<pre><code>//
// What makes a good checkpoint block?
// + Is surrounded by blocks with reasonable timestamps
//   (no blocks before with a timestamp after, none after with
//    timestamp before)
// + Contains no strange transactions
//
</code></pre>

<p>Why should it matter? Presumably the client would have accepted it anyway if they were downloading it normally, and if you were to specify a later block, that would still force the client to download the strange block. I don't understand the point of this restriction.</p>

<bitcoin-core><checkpoints>
Why is it important for checkpoints to contain well-formed blocks?
Nick ODell
# Why is it important for checkpoints to contain well-formed blocks?

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

In the source code of the standard client, checkpoints.cpp has this comment:
//
// What makes a good checkpoint block?
// + Is surrounded by blocks with reasonable timestamps
//   (no blocks before with a timestamp after, none after with
//    timestamp before)
// + Contains no strange transactions
//

Why should it matter? Presumably the client would have accepted it anyway if they were downloading it normally, and if you were to specify a later block, that would still force the client to download the strange block. I don't understand the point of this restriction.

**Tags:** bitcoin-core, checkpoints


---

## 1 answers

### Answer by username_1 on 2013-02-02. Score: 1 | Accepted answer

There are two things :

* Why are checkpoints needed in the first place,
* Why do the checkpointed blocks need to adhere to the standards you are quoting (which is your question)

I don't think checkpoints are required at all or useful in any way, there has been some debate around this, the fact remains that checkpoints are still present in the Satoshi implementation.

I believe there is no specific reason why the checkpointed blocks must have "reasonable timestamps" or not contain "strange transactions". The only reason I can think of is to not confuse someone reviewing the checkpointed blocks. As you said, such a block would still be downloaded and properly validated. So I think it has more to do with cosmetics and clarity than with an actual technical constraint.

(Also note that "strange transactions" doesn't really mean much, it does not seem to be defined as a transaction that passes the `IsStandard` check)

> **Comments:**
> **username_0**: "I don't think checkpoints are required at all or useful in any way," I actually disagree on this point, as my client grabs the blockchain quite a lot faster when getting blocks before a checkpoint.  
> **username_1**: AFAIK checkpoints are not used to improve performance of the initial chain download, and even if it did your client would still have to scan each single block and look at each single transaction in it in order to find transactions that are relevant to its wallet.  
> **username_0**: True, but it doesn't need to verify the signatures. I don't know how significant that is performance-wise.  
> **username_1**: Verifying the signature takes a negligible amount of time, it's looking the inputs up that does. The initial download performance is I/O bound, not CPU bound.  
> **username_0**: That makes sense. You mention that the `IsStandard` check fails on transactions in some checkpoints. Do you have any examples?  
> **username_1**: I never said that :)  
> **username_0**: let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/7366/discussion-between-nick-odell-and-david)  

---

