<p>Whether or not there is a solution depends on the contents of the block as well as the possible values of the nonce.</p>

<p>The transaction block can be altered if necessary which essentially means you get another 32 bits of nonce values to try. There is an additional component of a transaction block called the "coinbase" that can be altered without altering the actual transactions within the block. This has been in the past to <a href="https://bitcoin.stackexchange.com/a/26/516">insert short messages into the block chain</a>. </p>

CC BY-SA 4.0
2021-02-22T14:12:58.533Z
but you would need to re-calculate the Merkle root if you change the coinbase tx? Or it doesn't change its hash?
Jean Monet
CC BY-SA 3.0
2012-06-19T19:00:32.127Z
The Coinbase value can be used to insert a small string, such as described here: http://bitcoin.stackexchange.com/a/26/516
Highly Irregular
CC BY-SA 3.0
2011-10-28T02:41:46.180Z
2012-06-19T19:04:51.373Z
2017-04-13T12:47:36.707Z
Highly Irregular
<p>The difficulty is already to the point where it requires over a quadrillion hashes to solve a block. 2^32 is only 4 billion. Fewer than one in a billion times will there be <em>any</em> nonce that makes the block valid.</p>

<p>A miner simply has to try every possible nonce on a different block. He can vary the coinbase, the transaction set, and/or the block timestamp. Any change to any of these things results in a new chance for there to exist a valid nonce.</p>

<p>Often the best choice is to bump the timestamp, a practice called <a href="https://bitcoin.stackexchange.com/questions/1482/what-is-ntime-rolling-nonce-range-and-what-miners-support-it/1486#1486">NTime rolling</a>.</p>

<p>The block timestamp doesn't have to be exact anyway, so you can back the timestamp back, say, ten seconds before you start mining and then bump it up 20 times before giving up and getting a new block. At worst, your block timestamp will be off by a dozen seconds or so -- nobody cares about that.</p>

<p>After that, you probably want to get a new block because there might be some new transactions to include -- this not only improves the efficiency of the network as a whole but reduces the chances you'll miss out on a transaction fee.</p>

CC BY-SA 4.0
2021-08-11T11:46:48.117Z
Seems to me that the nonce should have been designed to be at least 64 bits not 32.  Surprised by the lack of foresight here.  Perhaps the block header could be redesigned?
andrewz
CC BY-SA 3.0
2011-10-28T07:08:24.083Z
By my calculations, a miner at 270Mhash/sec will run through 2^32 nonces in about 15 seconds! Are these techniques you speak of performed by the bitcoin server or the miner?
Highly Irregular
CC BY-SA 3.0
2011-10-28T09:44:53.077Z
Typically these changes are done by the Bitcoin node (eg mining pool server). The timestamp could potentially be changed by the miner but I don't think that's done. Changing the extraNonce in the generation transaction is harder, but I think requires only its Merkle branch and not the entire block. Adding new transactions definitely requires the node.
Meni Rosenfeld
CC BY-SA 3.0
2011-10-28T17:57:26.450Z
@MeniRosenfeld While tranditionally these changes were performed by the pool it is highly inefficient. The NTimeRolling option allows the miner to locally increment the timestamp.  The pool only needs to calculate new headers on block change, periodically for new transactions, or when NTime rolling expires.
DeathAndTaxes
CC BY-SA 3.0
2011-10-28T03:08:02.920Z
2011-10-28T03:08:02.920Z
2017-04-13T12:47:32.940Z
David Schwartz
<p>If I understand correctly, the block only has 4 bytes (32 bits) for the nonce.
Is it possible for the difficulty to become high enough that there are no nonce solutions?
If so, then what options does a miner have?</p>

CC BY-SA 3.0
2011-10-28T14:28:59.397Z
Since David already has a solid answer I will just make a trivia comment.  Even with a difficulty of 1 there is a 36.7% chance of not finding any valid hash in the entire nonce range (2^32).  At 1 million difficulty there is a 99.999905% that you will not find a solution in the entire nonce range.  Luckily any other change to block header allows you another 4 billion tries.
DeathAndTaxes
<hash><block-header><nonce>
Nonce size - Will it always be big enough?
Michael Pickens
# Nonce size - Will it always be big enough?

(Asked by: username_0 on 2011-10-28)

If I understand correctly, the block only has 4 bytes (32 bits) for the nonce.
Is it possible for the difficulty to become high enough that there are no nonce solutions?
If so, then what options does a miner have?

**Tags:** hash, block-header, nonce

> **Comments:**
> **username_1**: Since David already has a solid answer I will just make a trivia comment.  Even with a difficulty of 1 there is a 36.7% chance of not finding any valid hash in the entire nonce range (2^32).  At 1 million difficulty there is a 99.999905% that you will not find a solution in the entire nonce range.  Luckily any other change to block header allows you another 4 billion tries.  

---

## 2 answers

### Answer by username_4 on 2011-10-28. Score: 37 | Accepted answer

The difficulty is already to the point where it requires over a quadrillion hashes to solve a block. 2^32 is only 4 billion. Fewer than one in a billion times will there be *any* nonce that makes the block valid.

A miner simply has to try every possible nonce on a different block. He can vary the coinbase, the transaction set, and/or the block timestamp. Any change to any of these things results in a new chance for there to exist a valid nonce.

Often the best choice is to bump the timestamp, a practice called [NTime rolling](https://bitcoin.stackexchange.com/questions/1482/what-is-ntime-rolling-nonce-range-and-what-miners-support-it/1486#1486).

The block timestamp doesn't have to be exact anyway, so you can back the timestamp back, say, ten seconds before you start mining and then bump it up 20 times before giving up and getting a new block. At worst, your block timestamp will be off by a dozen seconds or so -- nobody cares about that.

After that, you probably want to get a new block because there might be some new transactions to include -- this not only improves the efficiency of the network as a whole but reduces the chances you'll miss out on a transaction fee.

> **Comments:**
> **username_2**: By my calculations, a miner at 270Mhash/sec will run through 2^32 nonces in about 15 seconds! Are these techniques you speak of performed by the bitcoin server or the miner?  
> **username_6**: Typically these changes are done by the Bitcoin node (eg mining pool server). The timestamp could potentially be changed by the miner but I don't think that's done. Changing the extraNonce in the generation transaction is harder, but I think requires only its Merkle branch and not the entire block. Adding new transactions definitely requires the node.  
> **username_1**: @MeniRosenfeld While tranditionally these changes were performed by the pool it is highly inefficient. The NTimeRolling option allows the miner to locally increment the timestamp.  The pool only needs to calculate new headers on block change, periodically for new transactions, or when NTime rolling expires.  
> **username_5**: Seems to me that the nonce should have been designed to be at least 64 bits not 32.  Surprised by the lack of foresight here.  Perhaps the block header could be redesigned?  

---

### Answer by username_2 on 2011-10-28. Score: 7

Whether or not there is a solution depends on the contents of the block as well as the possible values of the nonce.

The transaction block can be altered if necessary which essentially means you get another 32 bits of nonce values to try. There is an additional component of a transaction block called the "coinbase" that can be altered without altering the actual transactions within the block. This has been in the past to [insert short messages into the block chain](https://bitcoin.stackexchange.com/a/26/516).

> **Comments:**
> **username_2**: The Coinbase value can be used to insert a small string, such as described here: http://bitcoin.stackexchange.com/a/26/516  
> **username_3**: but you would need to re-calculate the Merkle root if you change the coinbase tx? Or it doesn't change its hash?  

---

