<p>Increasing the nonce size would not increase or decrease the expected block time.  </p>

<p>The block time is maintained via the difficulty adjustment algorithm, which adjusts the network difficulty according to the apparent time it took for the last 2016 blocks to be found. How quickly blocks are found can thus be used to estimate how many hashes/second the network's miners are collectively performing. The limitation for how many hashes/second a miner can perform is hardware-based (ie. <em>"I own an ASIC miner that can do some amount of hashes per second"</em>), not nonce-based (ie. <em>"I'm running out of possible input values"</em>). </p>

<p>This is because if the nonce-space is exhausted, then the timestamp can be incremented, and the nonce-space can be searched through again. A miner can alter the transaction content of the block, or even just the coinbase transaction, and then the nonce-space can be searched through again. So while the nonce-space for a specific block template may be exhausted more quickly with a smaller nonce size, we can effectively 'increase the nonce' infinitely, by adjusting other input variables and then incrementing through the nonce-space again. </p>

<p>Since mining utilizes the SHA256 hash function, the number of input bytes that you can arbitrarily alter (ie increment as a nonce) will not affect your ability to generate a desirable output (ie, a valid block hash). So as long as you can alter <em>some</em> parts of the input arbitrarily, so as to not run out of possible input values, it seems to me that the bottleneck to finding a valid hash will be hardware-based, not algorithmic-based.</p>

CC BY-SA 4.0
2019-10-15T10:09:18.150Z
2019-10-15T10:09:18.150Z
chytrik
<p>If Bitcoin increases its nonce size from 32 bits to double or triple the size, how will it affect the speed of getting the right hash with the required number of zeros?</p>

<bitcoin-core><blockchain><hash><block-hash>
What would be the effect on the number of leading zeros hash generation if bitcoin increase its nonce size from 32 to 60 or 100 bits?
Oluwaseyi Jaiyeoba
# What would be the effect on the number of leading zeros hash generation if bitcoin increase its nonce size from 32 to 60 or 100 bits?

(Asked by: username_0 on 2019-10-15)

If Bitcoin increases its nonce size from 32 bits to double or triple the size, how will it affect the speed of getting the right hash with the required number of zeros?

**Tags:** bitcoin-core, blockchain, hash, block-hash


---

## 1 answers

### Answer by username_1 on 2019-10-15. Score: 1

Increasing the nonce size would not increase or decrease the expected block time.

The block time is maintained via the difficulty adjustment algorithm, which adjusts the network difficulty according to the apparent time it took for the last 2016 blocks to be found. How quickly blocks are found can thus be used to estimate how many hashes/second the network's miners are collectively performing. The limitation for how many hashes/second a miner can perform is hardware-based (ie. *"I own an ASIC miner that can do some amount of hashes per second"*), not nonce-based (ie. *"I'm running out of possible input values"*).

This is because if the nonce-space is exhausted, then the timestamp can be incremented, and the nonce-space can be searched through again. A miner can alter the transaction content of the block, or even just the coinbase transaction, and then the nonce-space can be searched through again. So while the nonce-space for a specific block template may be exhausted more quickly with a smaller nonce size, we can effectively 'increase the nonce' infinitely, by adjusting other input variables and then incrementing through the nonce-space again.

Since mining utilizes the SHA256 hash function, the number of input bytes that you can arbitrarily alter (ie increment as a nonce) will not affect your ability to generate a desirable output (ie, a valid block hash). So as long as you can alter *some* parts of the input arbitrarily, so as to not run out of possible input values, it seems to me that the bottleneck to finding a valid hash will be hardware-based, not algorithmic-based.


---

