When I researched for the answer on What happens in detail, when Bitcoin Core verifies a block during synchronization?, I noticed something:
According to the Wiki-Entry on Protocol rules 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?

  1. 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
  2. Check that nBits value matches the difficulty rules
  3. 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?

  • 3
    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 Nov 7 '15 at 14:58
  • That seems a likely explanation. :) – Murch Nov 7 '15 at 14:59
  • 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. – Anonymous Nov 8 '15 at 5:05
  • Good point. The wiki page hasn't been edited since May 2014, it may well be outdated. – Murch Nov 8 '15 at 9:45

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.