3

My understanding is that at a certain point, once hardware passed the 4 GH/s level, the 4 billion possible values for the nonce became insufficient in bitcoin mining, because a good rig could exhaust them all in less than a second, and then had to wait until the next second for the timestamp value to change and then try the next 4 billion.

The thing I don't get, though, is why they couldn't adjust the timestamp in increments of less than one second? What about milliseconds and nanoseconds? Why not adjust that input instead of the nonce range?

Edit: Is it that the timestamp has a fixed format that ends at seconds, and changing this would be more difficult / less efficient than simply appropriating space from the coinbase transaction?

2

They didn't. Nonce is still 4 bytes [1]. Miners don't have to wait when they run out of nonces. Miners just adjust another nonce (the extraNonce) in the first transaction (i.e., in scriptSig of the coinbase transaction [2]). That gives them another ~4 billion tries for the first nonce.

  • That's what I was referring to in my edit, that's the question: why is the extranonce preferable over using smaller subdivisions of time in the timestamp? Because the timestamp is of fixed size? – temporary_user_name Jul 19 '16 at 0:06
  • 1
    Oh, I see. The title was misleading for me. The timestamp in the header is another 32 bits (see bitcoin.org/en/developer-reference#block-headers again) stored in UNIX epoch time format (i.e., seconds since 1/1/1970; seconds, not milliseconds). However, "full nodes will not accept blocks with headers more than two hours in the future according to their clock" so there's only so many bits you can change in that timestamp (I think around \log_2{2 * 60 * 60} bits). – Alin Tomescu Jul 19 '16 at 0:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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