<p>The distribution of wining nonces is skewed toward 0 because this is a <a href="http://en.wikipedia.org/wiki/Selection_bias" rel="nofollow noreferrer">selection effect</a>: most everyone starts searching for nonces starting at 0, so the lower nonces are found first, even though there may be also higher nonces that could produce a winning block:
<img src="https://i.sstatic.net/Hunmr.png" alt="winning nonce values distribution"></p>

<p>This illustrates very well that the distribution of nonces is uniform:
<img src="https://i.sstatic.net/4LIaG.png" alt="histogram of valid nonces and hashes"></p>

<p>source: <a href="https://en.bitcoin.it/wiki/Distribution_of_nonces_and_hashes" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Distribution_of_nonces_and_hashes</a></p>

<p>Thus, +1 in the miner loop is the simplest way of changing the nonce, and it works because the valid nonce distribution is uniform. ASICs often deal with nonces very differently. Also, ASICs can scan the entire nonce range very quickly, so it doesn't really matter where you start looking for a valid nonce.</p>

CC BY-SA 3.0
2015-04-10T19:13:57.820Z
Even in ASIC world, keeping in mind that they can scan the whole interval that fast, wouldn't it be faster to use random or another algorithm?
Alex D
CC BY-SA 3.0
2015-04-11T02:20:21.547Z
@AlexD You can't get simpler than nonce++. ☺ Anything more than that (e.g., a pseudo-"random [number generator] or another algorithm") would just slow things down. People have explored [SAT solving as an alternative to brute force bitcoin mining](https://jheusser.github.io/2013/02/03/satcoin.html), but brute force is still faster.
Geremia
CC BY-SA 3.0
2015-04-12T05:29:28.640Z
I didn't mention any random so far :) pseudo random is the way to nowhere in brutforce attacks :) but I'm pretty sure there's a better way of brut-forcing things in more efficient way! :)
Alex D
CC BY-SA 3.0
2015-04-13T17:40:43.053Z
@AlexD If anyone discovers a better way, Bitcoin will have to adopt a different proof-of-work method.
Geremia
CC BY-SA 4.0
2021-03-08T06:58:23.500Z
I used to think that for a given block a valid nonce would eventually be found by +1 until success - is it actually the case that sometimes no nonce is found and the miner then has to abandon the block and try a different collection of transactions?
Prince M
CC BY-SA 4.0
2021-03-08T21:34:26.330Z
@PrinceM Yes, that could occur.
Geremia
CC BY-SA 4.0
2021-03-09T00:01:59.543Z
Why is the number of possible nonces finite? Why cant you just keep incrementing until one is found? Is this a "rule" or part of protocol? Or is it just faster?
Prince M
CC BY-SA 4.0
2021-03-09T16:57:36.923Z
@PrinceM "_Why is the number of possible nonces finite?_" The [nonce](https://en.bitcoin.it/wiki/Nonce) field in a Bitcoin block is a 32-bit (4-byte) number, so there are 2³² ≈ 4.3 billion possible numbers that it can represent. ASICs are so fast  that they can scan the entire nonce range (do ~4.3 billion hashes) almost instantly. That's why [extraNonce](https://bitcoin.stackexchange.com/q/5048/4334) is useful for finding a "winning" block.
Geremia
CC BY-SA 4.0
2021-03-09T21:31:37.367Z
@Geremia interesting, so there may be a nonce that makes that block work, it just doesn’t necessarily “fit” into the block. Got it!
Prince M
CC BY-SA 3.0
2015-04-10T06:05:46.453Z
2015-04-10T06:05:46.453Z
Geremia
<p>If you use four threads and split the range over the four threads, that means each thread finishes its range and starts a new one four times as often. That's clearly a losing proposition over giving each thread its own full range.</p>

CC BY-SA 3.0
2015-04-12T05:23:03.320Z
I wish I could do '-1' on you. your answer doesn't make any sense in terms my question. Please read it again. every thread is doing the same like: +1 at the bottom; next step would be -1 at the top. would that increase the entropy?
Alex D
CC BY-SA 3.0
2015-04-12T16:58:14.943Z
@AlexD I don't understand what you're saying, I guess. Since every nonce has the same chance, all that matters is how many nonces per second you can try. What would the benefit to this complexity be?
David Schwartz
CC BY-SA 3.0
2015-04-10T06:57:20.550Z
2015-04-10T06:57:20.550Z
David Schwartz
<p>I recently started to pay attention to what's going on at crypto-markets and, being developer for a long time, decided to take a look at the software we have out there in public access.</p>

<p>So I have a question to all crypto-guru here:
As it seems from Bitcoin protocol specification, bitcoin will accept <em>ANY</em> nonce that satisfies target (block) bits condition. Every single miner I've seen made public is using sequential loop over nonce1 and nonce2.
actual question: why do people implement +1 for the nonce in every thread, instead, let's say, having 2 thread one is going +1 from the beginning; second one is counting -1 from the end of nonces interval?</p>

<p>In my humble opinion, it would be faster if you're running several threads on the same interval...or, in the perfect world, split the entire interval in N subintervals leaving every thread do its own piece. From the mathematical point of view it seems like we gonna get higher probability of hitting 'golden nonce' using this approach, as opposed to +1 over the entire interval. Am I wrong here?</p>

<p>having all that said, I've downloaded the blockchain and ran couple of tests to see nonce distribution in uint32_t interval. results didn't surprise me...I've got pretty much uniform nonce distribution like:
odd nonce: 49.997
even nonce: 50.003</p>

<p>split uint32_t into 1024 identical intervals and see how many nonces from existing blockchain are sitting in every interval. results are the same: uniform distribution.</p>

<p>again, why is it +1 in the miner loop? even though, (+3), (-2) would have yielded (in theory) better chances (faster) finding golden nonce vs others doing (+1).  </p>

CC BY-SA 3.0
2015-04-10T04:13:39.800Z
Why would that be faster than giving every thread its own block header to mine?
Nick ODell
CC BY-SA 3.0
2015-04-10T08:19:47.163Z
Which is quicker to guess a PIN?: randomly guessing or starting at 0000 all the way to 9999?
Wizard Of Ozzie
CC BY-SA 3.0
2015-04-10T18:52:02.110Z
depends on your luck. but in theory, if you're using uniform random, you will most likely find a PIN faster. give it a try. simple software app will show it to you. Keeping in mind that you need to find new PINs over and over again, random gives you some advantages
Alex D
CC BY-SA 3.0
2015-04-10T19:16:05.353Z
@NickODell, try it yourself: run cpuminer with 64 threads. thread speed will go down, but amount of accepted nonces will go up over limited amount of time.
Alex D
CC BY-SA 3.0
2015-04-11T17:48:43.963Z
I think you're confused, thinking all miners are computing the same thing therefore doing +2 might give you headway. Every miner is running on a different random piece of work. The next point you need to know is that the PoW algorithm is progress free: every single number has the same chance, it doesn't matter if you start at the beginning or the end or middle. It doesn't matter whether you do +1 or +2 or +random. So everyone picks the simplest.
Jannes
CC BY-SA 3.0
2015-04-11T23:25:55.473Z
@Jannes, thanks for your input! that makes sense
Alex D
CC BY-SA 3.0
2015-04-12T05:14:24.270Z
PoW is not an answer. it is giving you intervals. the pool, the task givers, they don't care if you can do it faster. if you can, they'll adjust your bits/diff... which is, in my opinion again, a red flag to the 'fuzzy-logic' high-speed approach, if I may say that :)
Alex D
CC BY-SA 3.0
2015-04-12T05:17:54.770Z
sorry for the confusion, I meant 'green flag' for the fuzzy logic and red for the brutforce/rainbow kinda thing
Alex D
<mining-theory><nonce>
Bitcoin (and other crypto-coins) nonce loop
Alex D
# Bitcoin (and other crypto-coins) nonce loop

(Asked by: username_0 on 2015-04-10)

I recently started to pay attention to what's going on at crypto-markets and, being developer for a long time, decided to take a look at the software we have out there in public access.

So I have a question to all crypto-guru here:
As it seems from Bitcoin protocol specification, bitcoin will accept *ANY* nonce that satisfies target (block) bits condition. Every single miner I've seen made public is using sequential loop over nonce1 and nonce2.
actual question: why do people implement +1 for the nonce in every thread, instead, let's say, having 2 thread one is going +1 from the beginning; second one is counting -1 from the end of nonces interval?

In my humble opinion, it would be faster if you're running several threads on the same interval...or, in the perfect world, split the entire interval in N subintervals leaving every thread do its own piece. From the mathematical point of view it seems like we gonna get higher probability of hitting 'golden nonce' using this approach, as opposed to +1 over the entire interval. Am I wrong here?

having all that said, I've downloaded the blockchain and ran couple of tests to see nonce distribution in uint32\_t interval. results didn't surprise me...I've got pretty much uniform nonce distribution like:
odd nonce: 49.997
even nonce: 50.003

split uint32\_t into 1024 identical intervals and see how many nonces from existing blockchain are sitting in every interval. results are the same: uniform distribution.

again, why is it +1 in the miner loop? even though, (+3), (-2) would have yielded (in theory) better chances (faster) finding golden nonce vs others doing (+1).

**Tags:** mining-theory, nonce

> **Comments:**
> **username_1**: Why would that be faster than giving every thread its own block header to mine?  
> **username_2**: Which is quicker to guess a PIN?: randomly guessing or starting at 0000 all the way to 9999?  
> **username_0**: depends on your luck. but in theory, if you're using uniform random, you will most likely find a PIN faster. give it a try. simple software app will show it to you. Keeping in mind that you need to find new PINs over and over again, random gives you some advantages  
> **username_0**: @username_1, try it yourself: run cpuminer with 64 threads. thread speed will go down, but amount of accepted nonces will go up over limited amount of time.  
> **username_3**: I think you're confused, thinking all miners are computing the same thing therefore doing +2 might give you headway. Every miner is running on a different random piece of work. The next point you need to know is that the PoW algorithm is progress free: every single number has the same chance, it doesn't matter if you start at the beginning or the end or middle. It doesn't matter whether you do +1 or +2 or +random. So everyone picks the simplest.  
> **username_0**: @username_3, thanks for your input! that makes sense  
> **username_0**: PoW is not an answer. it is giving you intervals. the pool, the task givers, they don't care if you can do it faster. if you can, they'll adjust your bits/diff... which is, in my opinion again, a red flag to the 'fuzzy-logic' high-speed approach, if I may say that :)  
> **username_0**: sorry for the confusion, I meant 'green flag' for the fuzzy logic and red for the brutforce/rainbow kinda thing  

---

## 2 answers

### Answer by username_4 on 2015-04-10. Score: 1 | Accepted answer

The distribution of wining nonces is skewed toward 0 because this is a [selection effect](http://en.wikipedia.org/wiki/Selection_bias): most everyone starts searching for nonces starting at 0, so the lower nonces are found first, even though there may be also higher nonces that could produce a winning block:
![winning nonce values distribution](https://i.sstatic.net/Hunmr.png)

This illustrates very well that the distribution of nonces is uniform:
![histogram of valid nonces and hashes](https://i.sstatic.net/4LIaG.png)

source: <https://en.bitcoin.it/wiki/Distribution_of_nonces_and_hashes>

Thus, +1 in the miner loop is the simplest way of changing the nonce, and it works because the valid nonce distribution is uniform. ASICs often deal with nonces very differently. Also, ASICs can scan the entire nonce range very quickly, so it doesn't really matter where you start looking for a valid nonce.

> **Comments:**
> **username_0**: Even in ASIC world, keeping in mind that they can scan the whole interval that fast, wouldn't it be faster to use random or another algorithm?  
> **username_4**: @username_0 You can't get simpler than nonce++. ☺ Anything more than that (e.g., a pseudo-"random [number generator] or another algorithm") would just slow things down. People have explored [SAT solving as an alternative to brute force bitcoin mining](https://jheusser.github.io/2013/02/03/satcoin.html), but brute force is still faster.  
> **username_0**: I didn't mention any random so far :) pseudo random is the way to nowhere in brutforce attacks :) but I'm pretty sure there's a better way of brut-forcing things in more efficient way! :)  
> **username_4**: @username_0 If anyone discovers a better way, Bitcoin will have to adopt a different proof-of-work method.  
> **username_5**: I used to think that for a given block a valid nonce would eventually be found by +1 until success - is it actually the case that sometimes no nonce is found and the miner then has to abandon the block and try a different collection of transactions?  
> **username_4**: @username_5 Yes, that could occur.  
> **username_5**: Why is the number of possible nonces finite? Why cant you just keep incrementing until one is found? Is this a "rule" or part of protocol? Or is it just faster?  
> **username_4**: @username_5 "_Why is the number of possible nonces finite?_" The [nonce](https://en.bitcoin.it/wiki/Nonce) field in a Bitcoin block is a 32-bit (4-byte) number, so there are 2³² ≈ 4.3 billion possible numbers that it can represent. ASICs are so fast  that they can scan the entire nonce range (do ~4.3 billion hashes) almost instantly. That's why [extraNonce](https://bitcoin.stackexchange.com/q/5048/4334) is useful for finding a "winning" block.  
> **username_5**: @username_4 interesting, so there may be a nonce that makes that block work, it just doesn’t necessarily “fit” into the block. Got it!  

---

### Answer by username_6 on 2015-04-10. Score: 2

If you use four threads and split the range over the four threads, that means each thread finishes its range and starts a new one four times as often. That's clearly a losing proposition over giving each thread its own full range.

> **Comments:**
> **username_0**: I wish I could do '-1' on you. your answer doesn't make any sense in terms my question. Please read it again. every thread is doing the same like: +1 at the bottom; next step would be -1 at the top. would that increase the entropy?  
> **username_6**: @username_0 I don't understand what you're saying, I guess. Since every nonce has the same chance, all that matters is how many nonces per second you can try. What would the benefit to this complexity be?  

---

