<p>Changing the timestamp is one way, but the more scalable method is to change the "extraNonce" field of the generation transaction, which changes the block header's Merkle root.</p>

CC BY-SA 3.0
2013-08-27T13:31:33.667Z
2013-08-27T13:31:33.667Z
Meni Rosenfeld
<p>The nonce field of a block header is 4 bytes, so the max nonce is: 4,294,967,295. That could be computed in a few seconds with a reasonable rig (solo mining) or much quicker on large pools. What happens at that point? I assume you'd change the timestamp and start over, but on extremely powerful pools, I'm sure it's feasible to compute all 4,294,967,295 nonces for every second of the timestamp, so what happens in that eventuality?</p>

CC BY-SA 3.0
2013-08-27T20:30:14.213Z
Remember that each transaction added to a block changes the block and thus all nonces previously used become untested for the new block yet again.
Stephen Gornick
<mining-pools><mining-technical-details><nonce>
What happens when the nonce field overflows?
Anonymous
# What happens when the nonce field overflows?

(Asked by: username_0 on 2013-08-27)

The nonce field of a block header is 4 bytes, so the max nonce is: 4,294,967,295. That could be computed in a few seconds with a reasonable rig (solo mining) or much quicker on large pools. What happens at that point? I assume you'd change the timestamp and start over, but on extremely powerful pools, I'm sure it's feasible to compute all 4,294,967,295 nonces for every second of the timestamp, so what happens in that eventuality?

**Tags:** mining-pools, mining-technical-details, nonce

> **Comments:**
> **username_1**: Remember that each transaction added to a block changes the block and thus all nonces previously used become untested for the new block yet again.  

---

## 1 answers

### Answer by username_2 on 2013-08-27. Score: 5 | Accepted answer

Changing the timestamp is one way, but the more scalable method is to change the "extraNonce" field of the generation transaction, which changes the block header's Merkle root.


---

