<p>As you noted, the logarithmic scale skews it right, because the number of nonces within <code>log(10, nonce) &gt; 9</code> is 3 times larger than <code>log(10, nonce) &lt; 9</code></p>

<p>The other factor that might skew the nonces on your chart is that a pattern in the nonces on the blockchain doesn't necessarily mean that it's caused by a problem in the mining algorithm. As a trivial example, imagine if I wrote a mining program that never searched odd nonces. This wouldn't affect its mining power, but a person looking at the output might conclude that odd nonces never produced blocks.</p>

<p>As a more realistic example, mining clients spend more time searching low ranges of nonces than high ranges of nonces, simply because they start at 0, and reset every block. This effect becomes less pronounced over time as hashpower per mining client increases.</p>

CC BY-SA 3.0
2015-03-11T22:19:09.047Z
reminds me of this question here: "[Looking for nonces of even numbers](https://bitcoin.stackexchange.com/q/24650/4334)"
Geremia
CC BY-SA 3.0
2015-03-11T22:13:25.583Z
2016-11-06T02:43:55.607Z
2016-11-06T02:43:55.607Z
Nick ODell
<p>Whatever non-uniformity you see in the distribution of found nonces is because due to the fact that not every nonce has the same chance of being <strong>tried</strong>. Every tried hash, however, has exactly the same chance of winning.</p>

<p>Switching to a new proposed block is cheap. For example, if a 3GH/s mining chip increases the timestamp or modifies the extranonce every second, it will only ever find nonces in the range 0-3000000000.</p>

<p>If not every <em>tried</em> hash has the same chance of winning, SHA256 would be utterly broken.</p>

CC BY-SA 3.0
2016-11-07T23:02:17.190Z
2016-11-07T23:02:17.190Z
Pieter Wuille
<p>It's not unevenly distributed. The reason it appears that way in the graphs above is because the x-axis is plotted in logarithmic units. Here's what it looks like in linear units:</p>

<p><a href="https://i.sstatic.net/Hf2Bz.png" rel="noreferrer"><img src="https://i.sstatic.net/Hf2Bz.png" alt="Nonces vs. Hashes (semi-log-y plot)"></a></p>

CC BY-SA 3.0
2015-03-11T21:58:31.653Z
2015-03-11T22:08:28.713Z
2015-03-11T22:08:28.713Z
Geremia
<p>I set out to test <a href="https://bitcoin.stackexchange.com/questions/24650/looking-for-nonces-of-even-numbers/24893#comment29991_24898">the claim</a>: "<strong>Every nonce has an equal chance of winning.</strong>"</p>

<h1>Time Evolution</h1>

<p>So, I plotted, with gnuplot, the nonce values vs. hashes for all the valid blocks in the blockchain:<br><a href="https://i.sstatic.net/Dx4GP.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Dx4GP.png" alt="Nonces vs. Hashes"></a><br><a href="https://i.imgur.com/3LkacLD.gif" rel="nofollow noreferrer"><img src="https://i.imgur.com/3LkacLD.gif" alt="Nonces vs. Hashes (cummulative)"></a><br><a href="https://i.imgur.com/W08tgUr.gif" rel="nofollow noreferrer"><img src="https://i.imgur.com/W08tgUr.gif" alt="Nonces vs. Hashes (1,000 blocks shown at a time)"></a><br><sup>(Also, in the last plot, you can really visualize the change in the difficulty and even see where the difficulty was decreased.)</sup></p>

<h1>Histograms</h1>

<p>It makes sense that the nonces found are skewed toward 0 because this is a <a href="https://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:
<a href="https://i.sstatic.net/Hunmr.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Hunmr.png" alt="nonces histogram"></a></p>

<p>Why are the hashes distributed this way, though?:
<a href="https://i.sstatic.net/7MClK.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/7MClK.png" alt="hashes distribution"></a></p>

<p>2-D histogram of hashes and nonces (logarithmic color scale):
<a href="https://i.sstatic.net/4LIaG.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/4LIaG.png" alt="2-D histogram of hashes and nonces"></a></p>

CC BY-SA 3.0
2015-03-11T22:15:46.080Z
@Cryptognome Yes, silly me, I thought there were the same numbers of integers between equal intervals on a log graph…, viz., e.g.: log(100) - log(10) = log(1000) - log(100), but 100 - 10 < 1000 - 100.
Geremia
CC BY-SA 3.0
2015-03-12T01:37:03.467Z
Why is so much of this question struck out? If it's incorrect, just remove it. Striking it out makes it harder to read, and I can't even tell what the question is anymore.
Chris Hayes
CC BY-SA 3.0
2015-03-12T11:45:53.453Z
I think the problem is that the initial question made no sense, as it was based on a false understanding of the presented graphs. However, as Chris already said: The question should either be edited to fit the answers it got, or deleted if it is not deemed useful. As it is I'd vote on "not useful".
Murch
CC BY-SA 3.0
2015-03-13T06:01:03.820Z
Even if the graphs were correct, it wouldn't prove that nonces had an unequal chance of winning. If you look at the numbers on winning lottery tickets, 7 will be over-represented. But it's not because 7 comes up more as a winner, it's because people play 7 more. If, for example, many miners try nonces sequentially from zero and stop when they find a share, you'll see a lower incidence of higher nonces.
David Schwartz
CC BY-SA 3.0
2015-03-14T02:05:11.127Z
@DavidSchwartz But these graphs are of winning nonces (nonces that produce a block), not all nonces tried.
Geremia
CC BY-SA 3.0
2015-03-14T19:38:36.067Z
@Geremia Exactly. A chart of numbers on winning lottery tickets would show lots more 7's even though 7 is no more likely to win than any other number.
David Schwartz
<hash><sha256><proof-of-work><nonce>
Does every nonce really have an equal chance of winning?
Geremia
# Does every nonce really have an equal chance of winning?

(Asked by: username_0 on 2015-03-11)

I set out to test [the claim](https://bitcoin.stackexchange.com/questions/24650/looking-for-nonces-of-even-numbers/24893#comment29991_24898): "**Every nonce has an equal chance of winning.**"

# Time Evolution

So, I plotted, with gnuplot, the nonce values vs. hashes for all the valid blocks in the blockchain:  
[![Nonces vs. Hashes](https://i.sstatic.net/Dx4GP.png)](https://i.sstatic.net/Dx4GP.png)  
[![Nonces vs. Hashes (cummulative)](https://i.imgur.com/3LkacLD.gif)](https://i.imgur.com/3LkacLD.gif)  
[![Nonces vs. Hashes (1,000 blocks shown at a time)](https://i.imgur.com/W08tgUr.gif)](https://i.imgur.com/W08tgUr.gif)  
(Also, in the last plot, you can really visualize the change in the difficulty and even see where the difficulty was decreased.)

# Histograms

It makes sense that the nonces found are skewed toward 0 because this is a [selection effect](https://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:
[![nonces histogram](https://i.sstatic.net/Hunmr.png)](https://i.sstatic.net/Hunmr.png)

Why are the hashes distributed this way, though?:
[![hashes distribution](https://i.sstatic.net/7MClK.png)](https://i.sstatic.net/7MClK.png)

2-D histogram of hashes and nonces (logarithmic color scale):
[![2-D histogram of hashes and nonces](https://i.sstatic.net/4LIaG.png)](https://i.sstatic.net/4LIaG.png)

**Tags:** hash, sha256, proof-of-work, nonce

> **Comments:**
> **username_0**: @Cryptognome Yes, silly me, I thought there were the same numbers of integers between equal intervals on a log graph…, viz., e.g.: log(100) - log(10) = log(1000) - log(100), but 100 - 10 < 1000 - 100.  
> **username_1**: Why is so much of this question struck out? If it's incorrect, just remove it. Striking it out makes it harder to read, and I can't even tell what the question is anymore.  
> **username_2**: I think the problem is that the initial question made no sense, as it was based on a false understanding of the presented graphs. However, as username_1 already said: The question should either be edited to fit the answers it got, or deleted if it is not deemed useful. As it is I'd vote on "not useful".  
> **username_3**: Even if the graphs were correct, it wouldn't prove that nonces had an unequal chance of winning. If you look at the numbers on winning lottery tickets, 7 will be over-represented. But it's not because 7 comes up more as a winner, it's because people play 7 more. If, for example, many miners try nonces sequentially from zero and stop when they find a share, you'll see a lower incidence of higher nonces.  
> **username_0**: @username_3 But these graphs are of winning nonces (nonces that produce a block), not all nonces tried.  
> **username_3**: @username_0 Exactly. A chart of numbers on winning lottery tickets would show lots more 7's even though 7 is no more likely to win than any other number.  

---

## 3 answers

### Answer by username_0 on 2015-03-11. Score: 6 | Accepted answer

It's not unevenly distributed. The reason it appears that way in the graphs above is because the x-axis is plotted in logarithmic units. Here's what it looks like in linear units:

[![Nonces vs. Hashes (semi-log-y plot)](https://i.sstatic.net/Hf2Bz.png)](https://i.sstatic.net/Hf2Bz.png)


---

### Answer by username_4 on 2015-03-11. Score: 5

As you noted, the logarithmic scale skews it right, because the number of nonces within `log(10, nonce) > 9` is 3 times larger than `log(10, nonce) < 9`

The other factor that might skew the nonces on your chart is that a pattern in the nonces on the blockchain doesn't necessarily mean that it's caused by a problem in the mining algorithm. As a trivial example, imagine if I wrote a mining program that never searched odd nonces. This wouldn't affect its mining power, but a person looking at the output might conclude that odd nonces never produced blocks.

As a more realistic example, mining clients spend more time searching low ranges of nonces than high ranges of nonces, simply because they start at 0, and reset every block. This effect becomes less pronounced over time as hashpower per mining client increases.

> **Comments:**
> **username_0**: reminds me of this question here: "[Looking for nonces of even numbers](https://bitcoin.stackexchange.com/q/24650/4334)"  

---

### Answer by username_5 on 2016-11-07. Score: 2

Whatever non-uniformity you see in the distribution of found nonces is because due to the fact that not every nonce has the same chance of being **tried**. Every tried hash, however, has exactly the same chance of winning.

Switching to a new proposed block is cheap. For example, if a 3GH/s mining chip increases the timestamp or modifies the extranonce every second, it will only ever find nonces in the range 0-3000000000.

If not every *tried* hash has the same chance of winning, SHA256 would be utterly broken.


---

