This could apply to any block, but I was checking this one out found by Slushpool.

I've looked this up in Mastering Bitcoin and here on StackExchange, but the best I can get so far is: the coinbase tx is a script, where the first byte says "push three bytes on the stack", which turns out to be 9fa508 in hexadecimal. Reversing the byte order to 08a59f gives the block number (566687 decimal).

This is where I get stuck. The book says the next few bytes are used to encode the extra nonce.

Then it gets a bit more detailed: "Eight bytes of extra nonce, plus the 4 bytes of "standard" nonce allow miners to explore a total 2^96 (8 followed by 28 zeros) possibilities per second without having to modify the timestamp." p. 266 Chapter 10 in the latest edition of Mastering Bitcoin.

I can't find any code examples to try and find the nonce for a block using the extra nonce, rather than the usual examples that go to a maximum 32-bit unsigned integer as the nonce.

Is it a concatenation of nonce + extranonce, simply 41678782744206783853? (With 4167878274 the nonce, then the additional 8 bytes interpreted as a large little-endian integer?)

I've also seen it's apparently a push of a timestamp then another push of N bytes for the extranonce, but it's getting hard to find anything to actually test.

I can't just write something like this in Python:

 header = ( struct.pack("<L", version_) + prev_block.decode('hex')[::-1] +
      merkle_root.decode('hex')[::-1] + struct.pack("<LLQ", timetamp_, bits, nonce))

The nonce is way too big in this case to pack with Q of course.

What is the correct way to validate recent blocks interpreting the nonce and extra nonce? Subtracting a little from the given nonce, so a loop only goes for say a few thousand times, adding +1 up to the nonce, then finding a block hash lower than the target doesn't seem to work with the extra nonce, although it does with older blocks that have a nonce that fits within an unsigned 32-bit integer.

The real nonce a much larger number, isn't it? If it is, where is it, and how is it put together with the apparent nonce given on blockchain explorers so that a simple script can validate a recent Bitcoin block?




The nonce for the block remains unchanged. Since the extra nonce is part of the coinbase transaction, it modifies the merkle root, which is part of the block header. Thus, for each extra nonce, you get a unique merkle root, which then allows you to try the full range of regular nonces with that merkle root.

You do not need to concatenate or otherwise mix the two nonces in any form - the extra nonce's purpose is simply to alter the merkle root.

To validate a block with an extra nonce, you don't need to do anything special. Just build the transaction merkle tree, verify the merkle root matches the root in the block header, then hash the header and check it agains the target. It's the same process for blocks with and without the extra nonce.

  • Thank you Raghav, that was very useful. Now I can appreciate the books and other things I find. I did find a big problem once I examined all the block values again after reading your answer. I still had the version in the header set to 2, instead of 0x20800000. Now the script works as expected. Thanks again. – James Young Mar 13 at 0:19

Your Answer

