<p>IIRC, it validates the best chain of headers it got, and see if this chain is indeed the best chain its peers know about. So, you won't validate blocks entirely (like, all transaction), but only the PoW performed for all headers up to now, and this is very fast.</p>

CC BY-SA 4.0
2022-06-11T18:26:05.507Z
You mean it just calculate the hash of the block to check whether it is satisfied the difficulty or not?
Amir reza Riahi
CC BY-SA 4.0
2022-06-12T16:45:02.980Z
Yes, see if PoW is valid and sanity check (is something corrupted or so?).
Davidson Souza
CC BY-SA 4.0
2022-06-11T17:08:41.557Z
2022-06-11T17:08:41.557Z
Davidson Souza
<p>If you want to validate every block, you should try setting
assumevalid=0 in bitcoin config file.</p>
<pre><code>-assumevalid=&lt;hex&gt;
</code></pre>
<p>If this block is in the chain, assume that it and its ancestors are valid, and potentially skip their script verification (0 to verify all, default: 00000000000000000009c97098b5295f7e5f183ac811fb5d1534040adb93cabd, testnet: 0000000000000004877fa2d36316398528de4f347df2f8a96f76613a298ce060, signet: 000000d1a0e224fa4679d2fb2187ba55431c284fa1b74cbc8cfda866fd4d2c09)</p>

CC BY-SA 4.0
2023-03-28T10:22:21.807Z
2023-03-29T18:48:58.607Z
2023-03-29T18:48:58.607Z
11100100
<p>When running bitcoind, it starts downloading the blockchain and validate every block in a row. It stores the blockchain in the <code>~/.bitcoin/blocks</code> directory. And when we break daemon and restart it, starts downloading from the last block it downloaded from the previous execution and not from the first block again. This was something I understood from logs.</p>
<pre><code>2022-06-11T16:51:56Z dnsseed thread start
2022-06-11T16:51:56Z addcon thread start
2022-06-11T16:51:56Z init message: Done loading
2022-06-11T16:51:56Z opencon thread start
2022-06-11T16:51:56Z msghand thread start
2022-06-11T16:51:56Z Waiting 300 seconds before querying DNS seeds.
2022-06-11T16:51:57Z New outbound peer connected: version: 70016, blocks=740373, peer=0 (outbound-full-relay)
2022-06-11T16:51:58Z Synchronizing blockheaders, height: 740373 (~100.00%)
2022-06-11T16:51:59Z UpdateTip: new best=0000000000000533f02f775db4176ec57012c76c6dc56fa3debf5f307da3d758 height=139238 version=0x00000001 log2_work=65.854192 tx=1188914 date='2011-08-02T05:59:57Z' progress=0.001607 cache=0.0MiB(308txo)
2022-06-11T16:51:59Z UpdateTip: new best=0000000000000264f2835263bdfcae0a8a4185b781fa980d0eae3e88ee4effa9 height=139239 version=0x00000001 log2_work=65.854368 tx=1189040 date='2011-08-02T06:01:53Z' progress=0.001607 cache=0.1MiB(621txo)
2022-06-11T16:51:59Z UpdateTip: new best=00000000000008ae748a17911f5d56ac7e5ede06586d98d7d6aa83ce8bda5237 height=139240 version=0x00000001 log2_work=65.854543 tx=1189100 date='2011-08-02T06:11:42Z' progress=0.001607 cache=0.1MiB(793txo)
</code></pre>
<p>As shown in logs above, it's downloading from height 139238. But beside downloading, does it validate the downloaded blocks again? The thing I noticed while running the program step by step using <code>gdb</code>, was that it calls the <code>GetBlockProof</code> from the first block.</p>
<pre><code>(gdb) break GetBlockProof
Breakpoint 1 at 0x31be40: file chain.cpp, line 126.
(gdb) run
Starting program: /usr/local/bin/bitcoind 
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.31-2.fc32.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library &quot;/lib64/libthread_db.so.1&quot;.
2022-06-11T16:58:20Z Bitcoin Core version v23.0 (release build)
2022-06-11T16:58:20Z Assuming ancestors of block 000000000000000000052d314a259755ca65944e68df6b12a067ea8f1f5a7091 have valid signatures.

...

Thread 1 &quot;bitcoind&quot; hit Breakpoint 1, GetBlockProof (block=...) at chain.cpp:126
126 {
Missing separate debuginfos, use: dnf debuginfo-install libevent-2.1.8-8.fc32.x86_64 libgcc-10.3.1-1.fc32.x86_64 openssl-libs-1.1.1d-7.fc32.x86_64 zlib-1.2.11-21.fc32.x86_64
(gdb) p block.nHeight 
$1 = 0
(gdb) continue 
Continuing.

Thread 1 &quot;bitcoind&quot; hit Breakpoint 1, GetBlockProof (block=...) at chain.cpp:126
126 {
(gdb) p block.nHeight 
$2 = 1
(gdb) continue 
Continuing.

Thread 1 &quot;bitcoind&quot; hit Breakpoint 1, GetBlockProof (block=...) at chain.cpp:126
126 {
(gdb) p block.nHeight 
$3 = 2
(gdb) 

</code></pre>
<p>Is this true that is starts validating blocks from the genesis block? Or my conclusion is wrong? And if no, why the <code>GetBlockProof</code> is called from the first block?</p>

<bitcoin-core><bitcoind><bitcoin-core-development><source-code><debugging>
Does bitcoind validate every block for every time it starts?
Amir reza Riahi
# Does bitcoind validate every block for every time it starts?

(Asked by: username_0 on 2022-06-11)

When running bitcoind, it starts downloading the blockchain and validate every block in a row. It stores the blockchain in the `~/.bitcoin/blocks` directory. And when we break daemon and restart it, starts downloading from the last block it downloaded from the previous execution and not from the first block again. This was something I understood from logs.

```
2022-06-11T16:51:56Z dnsseed thread start
2022-06-11T16:51:56Z addcon thread start
2022-06-11T16:51:56Z init message: Done loading
2022-06-11T16:51:56Z opencon thread start
2022-06-11T16:51:56Z msghand thread start
2022-06-11T16:51:56Z Waiting 300 seconds before querying DNS seeds.
2022-06-11T16:51:57Z New outbound peer connected: version: 70016, blocks=740373, peer=0 (outbound-full-relay)
2022-06-11T16:51:58Z Synchronizing blockheaders, height: 740373 (~100.00%)
2022-06-11T16:51:59Z UpdateTip: new best=0000000000000533f02f775db4176ec57012c76c6dc56fa3debf5f307da3d758 height=139238 version=0x00000001 log2_work=65.854192 tx=1188914 date='2011-08-02T05:59:57Z' progress=0.001607 cache=0.0MiB(308txo)
2022-06-11T16:51:59Z UpdateTip: new best=0000000000000264f2835263bdfcae0a8a4185b781fa980d0eae3e88ee4effa9 height=139239 version=0x00000001 log2_work=65.854368 tx=1189040 date='2011-08-02T06:01:53Z' progress=0.001607 cache=0.1MiB(621txo)
2022-06-11T16:51:59Z UpdateTip: new best=00000000000008ae748a17911f5d56ac7e5ede06586d98d7d6aa83ce8bda5237 height=139240 version=0x00000001 log2_work=65.854543 tx=1189100 date='2011-08-02T06:11:42Z' progress=0.001607 cache=0.1MiB(793txo)

```

As shown in logs above, it's downloading from height 139238. But beside downloading, does it validate the downloaded blocks again? The thing I noticed while running the program step by step using `gdb`, was that it calls the `GetBlockProof` from the first block.

```
(gdb) break GetBlockProof
Breakpoint 1 at 0x31be40: file chain.cpp, line 126.
(gdb) run
Starting program: /usr/local/bin/bitcoind 
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.31-2.fc32.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
2022-06-11T16:58:20Z Bitcoin Core version v23.0 (release build)
2022-06-11T16:58:20Z Assuming ancestors of block 000000000000000000052d314a259755ca65944e68df6b12a067ea8f1f5a7091 have valid signatures.

...

Thread 1 "bitcoind" hit Breakpoint 1, GetBlockProof (block=...) at chain.cpp:126
126 {
Missing separate debuginfos, use: dnf debuginfo-install libevent-2.1.8-8.fc32.x86_64 libgcc-10.3.1-1.fc32.x86_64 openssl-libs-1.1.1d-7.fc32.x86_64 zlib-1.2.11-21.fc32.x86_64
(gdb) p block.nHeight 
$1 = 0
(gdb) continue 
Continuing.

Thread 1 "bitcoind" hit Breakpoint 1, GetBlockProof (block=...) at chain.cpp:126
126 {
(gdb) p block.nHeight 
$2 = 1
(gdb) continue 
Continuing.

Thread 1 "bitcoind" hit Breakpoint 1, GetBlockProof (block=...) at chain.cpp:126
126 {
(gdb) p block.nHeight 
$3 = 2
(gdb) 

```

Is this true that is starts validating blocks from the genesis block? Or my conclusion is wrong? And if no, why the `GetBlockProof` is called from the first block?

**Tags:** bitcoin-core, bitcoind, bitcoin-core-development, source-code, debugging


---

## 2 answers

### Answer by username_1 on 2022-06-11. Score: 1 | Accepted answer

IIRC, it validates the best chain of headers it got, and see if this chain is indeed the best chain its peers know about. So, you won't validate blocks entirely (like, all transaction), but only the PoW performed for all headers up to now, and this is very fast.

> **Comments:**
> **username_0**: You mean it just calculate the hash of the block to check whether it is satisfied the difficulty or not?  
> **username_1**: Yes, see if PoW is valid and sanity check (is something corrupted or so?).  

---

### Answer by username_2 on 2023-03-28. Score: 0

If you want to validate every block, you should try setting
assumevalid=0 in bitcoin config file.

```
-assumevalid=<hex>

```

If this block is in the chain, assume that it and its ancestors are valid, and potentially skip their script verification (0 to verify all, default: 00000000000000000009c97098b5295f7e5f183ac811fb5d1534040adb93cabd, testnet: 0000000000000004877fa2d36316398528de4f347df2f8a96f76613a298ce060, signet: 000000d1a0e224fa4679d2fb2187ba55431c284fa1b74cbc8cfda866fd4d2c09)


---

