<p>Might be that there's a lot more transactions in later blocks. </p>

CC BY-SA 3.0
2013-04-18T23:04:51.627Z
I considered that, but I think it's not that. New blocks are also coming in faster than the ones before (the very early sparse blocks not taken into account).
It calmed down now, but blocks are added really slow.
Maybe it was just imagination or coïncidence
Steven Roose
CC BY-SA 3.0
2013-04-18T23:01:12.003Z
2013-04-18T23:01:12.003Z
Shamoon
<p>Up until the last checkpoint, your client knows that all transactions are properly signed. After the last checkpoint, your client has to validate each input to each transaction by matching it against the corresponding output and executing the script, typically involving an ECDSA verify.</p>

CC BY-SA 3.0
2013-04-21T18:24:31.850Z
And how are these checkpoints defined?
Steven Roose
CC BY-SA 3.0
2013-04-21T18:34:15.557Z
They're included in the source code. Whoever provided you the source code vouches that all blocks prior to the last checkpoint contain only valid transactions.
David Schwartz
CC BY-SA 3.0
2016-03-20T19:45:36.183Z
Is that what this is? : ```2016-03-20 17:49:12 Pre-allocating up to position 0x1000000 in blk00437.dat
2016-03-20 17:49:19 Pre-allocating up to position 0x2000000 in blk00437.dat
2016-03-20 17:49:22 Pre-allocating up to position 0x3000000 in blk00437.dat
2016-03-20 17:49:24 Pre-allocating up to position 0x4000000 in blk00437.dat
2016-03-20 17:49:25 Pre-allocating up to position 0x5000000 in blk00437.dat```
Anthony
CC BY-SA 3.0
2013-04-19T11:59:42.007Z
2013-04-19T11:59:42.007Z
David Schwartz
<p>I deleted my block chain and I'm currently syncing again. Just as I did last time, I noticed that from a certain point, my CPU usage raises to almost 100% and stays so for much longer than the usual peaks before this.</p>

<p>I think it's around the last 5000 blocks.</p>

<p>It also sometimes just stops, I don't know if that is for saving resources or something else, but sometimes it just stops (both CPU and network traffic go to nearly nothing) and almost no new blocks are added.</p>

<p>Is there a reason for this different behavior while syncing the last 5000 blocks?</p>

CC BY-SA 3.0
2016-03-20T19:44:42.513Z
Did you find out more about this? I'm experiencing the same thing
Anthony
<blockchain><bitcoind><synchronization>
Why is syncing the last 5000 blocks so much more CPU-intensive?
Steven Roose
# Why is syncing the last 5000 blocks so much more CPU-intensive?

(Asked by: username_0 on 2013-04-18)

I deleted my block chain and I'm currently syncing again. Just as I did last time, I noticed that from a certain point, my CPU usage raises to almost 100% and stays so for much longer than the usual peaks before this.

I think it's around the last 5000 blocks.

It also sometimes just stops, I don't know if that is for saving resources or something else, but sometimes it just stops (both CPU and network traffic go to nearly nothing) and almost no new blocks are added.

Is there a reason for this different behavior while syncing the last 5000 blocks?

**Tags:** blockchain, bitcoind, synchronization

> **Comments:**
> **username_1**: Did you find out more about this? I'm experiencing the same thing  

---

## 2 answers

### Answer by username_3 on 2013-04-19. Score: 5 | Accepted answer

Up until the last checkpoint, your client knows that all transactions are properly signed. After the last checkpoint, your client has to validate each input to each transaction by matching it against the corresponding output and executing the script, typically involving an ECDSA verify.

> **Comments:**
> **username_0**: And how are these checkpoints defined?  
> **username_3**: They're included in the source code. Whoever provided you the source code vouches that all blocks prior to the last checkpoint contain only valid transactions.  
> **username_1**: Is that what this is? : ```2016-03-20 17:49:12 Pre-allocating up to position 0x1000000 in blk00437.dat 2016-03-20 17:49:19 Pre-allocating up to position 0x2000000 in blk00437.dat 2016-03-20 17:49:22 Pre-allocating up to position 0x3000000 in blk00437.dat 2016-03-20 17:49:24 Pre-allocating up to position 0x4000000 in blk00437.dat 2016-03-20 17:49:25 Pre-allocating up to position 0x5000000 in blk00437.dat```  

---

### Answer by username_2 on 2013-04-18. Score: 0

Might be that there's a lot more transactions in later blocks.

> **Comments:**
> **username_0**: I considered that, but I think it's not that. New blocks are also coming in faster than the ones before (the very early sparse blocks not taken into account). It calmed down now, but blocks are added really slow. Maybe it was just imagination or coïncidence  

---

