4

My understanding is that the nonce in the header of an Ethereum block is an integer within a certain range (greater than 0).

However, when I look at the blocks through an online block explorer, such as etherscan, I see the nonce with values such as 0x885ddbbf0826351997.

In fact, if I look at blocks for the past year I can't find one that doesn't start with 0x88.

The Ethereum Yellow Paper stipulates that the nonce is a 64-bit hash enter image description here

However, with a hashing function, it would be unlikely to see so many values starting with 0x88.

Can anyone tell me how the nonce used in finding a valid hash for a block in Ethereum results in the nonce shown in the block header?

Improve this question
1
  • While I can't fully answer your question, I do observe that the block-header nonce reported by etherscan (as in your example) is 72 bits - it looks like the 0x88 has just been prepended to the 64 bit hash. Whether it's real or a "presentation issue", I can't say.
    – benjaminion
    Aug 17, 2017 at 13:15

2 Answers 2

Reset to default
3

My company runs a blockchain explorer.

Here is the information we have for that linked block.

I've had a look through the raw data and none of the nonces actually start with 0x88 (as returned from a JSON RPC call to a Parity (1.6.8) node)

It looks as though Etherscan is adding this. I am unsure why. It maybe something to do with how Etherscan have instrumented their node, or they may have simply added it in their output.

Improve this answer
3
  • Strange. etherchain.org and etherscan.io both show it with the 0x88 prefix, and couple of other explorers I tried don't (like yours). There's nothing in the Parity code that seems to be stripping it off when serving RPC requests, but the Geth code has lots of occurrences, especially in test cases where the nonce is just given as 0x88. Still no idea :-)
    – Richard Horrocks
    Aug 17, 2017 at 15:31
  • Infura also returns "nonce":"0x5ddbbf0826351997" for block 4168977.
    – Ismael ♦
    Aug 17, 2017 at 17:02
  • Yep, and to confirm I've tried against Geth 1.6.7 and get the same data (0x5ddbbf0826351997). I am completely bemused. Richard, do you have any links for these test cases?
    – Thomas Clowes
    Aug 17, 2017 at 18:25
0

A speculative answer, that I'd initially added as a comment. Happy to be corrected.

0x88 == 136, which is the size in bytes of an sha3 "block" (whereas for an sha256 "block" it would be 64 bytes == 0x40).

"0x88" seems to be scattered throughout the code, so it's likely this is a client-side prefix, rather than something added by chain explorers.

So... this is probably just a way to indicate the nonce has been hashed with sha3 rather than another hashing algorithm... (for backwards compatibility checks, etc.)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.