2

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?

temporary_user_name
  • 125
  • 6

1 Answers1

1

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.

Alin Tomescu
  • 1,327
  • 8
  • 29
  • 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 00:06
  • 1
    Oh, I see. The title was misleading for me. The timestamp in the header is another 32 bits (see https://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 00:51