<p>They didn't. Nonce is still 4 bytes <a href="https://bitcoin.org/en/developer-reference#block-headers" rel="nofollow">[1]</a>. Miners don't have to wait when they run out of nonces. Miners just adjust another nonce (the <a href="https://bitcoin.stackexchange.com/q/36455/4334">extraNonce</a>) in the first transaction (i.e., in <code>scriptSig</code> of the coinbase transaction <a href="https://en.bitcoin.it/wiki/Transaction#Generation" rel="nofollow">[2]</a>). That gives them another ~4 billion tries for the first nonce.</p>

CC BY-SA 3.0
2016-07-19T00:06:19.817Z
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
CC BY-SA 3.0
2016-07-19T00:51:05.127Z
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
CC BY-SA 3.0
2016-07-18T22:45:52.680Z
2016-07-19T00:55:54.063Z
2016-07-19T00:55:54.063Z
Alin Tomescu
<p>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.</p>

<p>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?</p>

<p><strong>Edit:</strong> 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?</p>

<mining-theory><nonce>
Why did they have to expand the nonce value range?
temporary_user_name
# Why did they have to expand the nonce value range?

(Asked by: username_0 on 2016-07-18)

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?

**Tags:** mining-theory, nonce


---

## 1 answers

### Answer by username_1 on 2016-07-18. Score: 1 | Accepted answer

They didn't. Nonce is still 4 bytes [[1]](https://bitcoin.org/en/developer-reference#block-headers). Miners don't have to wait when they run out of nonces. Miners just adjust another nonce (the [extraNonce](https://bitcoin.stackexchange.com/q/36455/4334)) in the first transaction (i.e., in `scriptSig` of the coinbase transaction [[2]](https://en.bitcoin.it/wiki/Transaction#Generation)). That gives them another ~4 billion tries for the first nonce.

> **Comments:**
> **username_0**: 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?  
> **username_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).  

---

