# Nonce size - Will it always be big enough?

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?

• 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. Oct 28, 2011 at 14:28

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.

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.

• 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? Oct 28, 2011 at 7:08
• 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. Oct 28, 2011 at 9:44
• @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. Oct 28, 2011 at 17:57
• 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? Aug 11, 2021 at 11:46

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.

• The Coinbase value can be used to insert a small string, such as described here: bitcoin.stackexchange.com/a/26/516 Jun 19, 2012 at 19:00
• but you would need to re-calculate the Merkle root if you change the coinbase tx? Or it doesn't change its hash? Feb 22, 2021 at 14:12