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 :-) 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.
    – Claris
    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 agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.