<p>When I researched for the answer on <a href="https://bitcoin.stackexchange.com/q/40476/5406">What happens in detail, when Bitcoin Core verifies a block during synchronization?</a>, I noticed something:<br>
According to the <a href="https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages" rel="nofollow noreferrer">Wiki-Entry on Protocol rules</a> some of the transactions' traits are checked before all header data is verified.</p>

<p>Why do the following checks of difficulty statement and timestamp get performed only after transactions get looked at?</p>

<blockquote>
  <ol start="11">
  <li>Check if prev block (matching prev hash) is in main branch or side branches. If not, add this to orphan blocks, then query peer we got this from for 1st missing orphan block in prev chain; done with block</li>
  <li>Check that nBits value matches the difficulty rules</li>
  <li>Reject if timestamp is the median time of the last 11 blocks or before</li>
  </ol>
</blockquote>

<p>Wouldn't it be more efficient to check the relation to the main chain and timestamp first, and then check the legality of the transactions?</p>

CC BY-SA 3.0
2015-11-07T14:58:08.440Z
Seems like in the normal case, all this work has to be done anyway, so it really doesn't matter what order you do it in.  It's true that if the block header were invalid, you could skip checking the transactions, but this should be very rare since you normally only get a block from another node who has already verified it.  My guess is that this is just something that nobody bothered to optimize - but feel free to submit a pull request :-)
Nate Eldredge
CC BY-SA 3.0
2015-11-07T14:59:08.907Z
That seems a likely explanation. :)
Murch
CC BY-SA 3.0
2015-11-08T05:05:59.357Z
With that sort of wiki page it is almost certainly not correct too, the wiki is rotten to the point of complete uselessness in a lot of cases.
Claris
CC BY-SA 3.0
2015-11-08T09:45:28.733Z
Good point. The wiki page hasn't been edited since May 2014, it may well be outdated.
Murch
<protocol><block><bitcoin-core-development><verification><block-header>
Why do transactions get verified before it is clear that the block header is valid?
Murch
# Why do transactions get verified before it is clear that the block header is valid?

(Asked by: username_0 on 2015-11-07)

When I researched for the answer on [What happens in detail, when Bitcoin Core verifies a block during synchronization?](https://bitcoin.stackexchange.com/q/40476/5406), I noticed something:  
According to the [Wiki-Entry on Protocol rules](https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages) some of the transactions' traits are checked before all header data is verified.

Why do the following checks of difficulty statement and timestamp get performed only after transactions get looked at?

> 11. Check if prev block (matching prev hash) is in main branch or side branches. If not, add this to orphan blocks, then query peer we got this from for 1st missing orphan block in prev chain; done with block
> 12. Check that nBits value matches the difficulty rules
> 13. Reject if timestamp is the median time of the last 11 blocks or before

Wouldn't it be more efficient to check the relation to the main chain and timestamp first, and then check the legality of the transactions?

**Tags:** protocol, block, bitcoin-core-development, verification, block-header

> **Comments:**
> **username_1**: Seems like in the normal case, all this work has to be done anyway, so it really doesn't matter what order you do it in.  It's true that if the block header were invalid, you could skip checking the transactions, but this should be very rare since you normally only get a block from another node who has already verified it.  My guess is that this is just something that nobody bothered to optimize - but feel free to submit a pull request :-)  
> **username_0**: That seems a likely explanation. :)  
> **username_2**: With that sort of wiki page it is almost certainly not correct too, the wiki is rotten to the point of complete uselessness in a lot of cases.  
> **username_0**: Good point. The wiki page hasn't been edited since May 2014, it may well be outdated.  

---

## 0 answers

