<p>You need to find any nonce, so that the block becomes valid. </p>

<p>It is of no regard, what algorithm you are using to chose a nonce, as long as the block meets or exceeds the difficulty target.</p>

CC BY-SA 3.0
2018-01-01T20:31:57.787Z
2018-01-01T20:31:57.787Z
nulldev
<p>Alternative algorithms used for choosing the next nonce to hash will not improve upon a simple integer increment. You will still be checking the same number of hashes per second.</p>

<p>An increment of two instead of one will not double the hash rate. The hashing rate will be equal in both cases.</p>

CC BY-SA 3.0
2018-01-01T21:43:43.663Z
I understand it doesn't really change the rate. But if the solution happens to be near the end of the range, you would reach it at twice the rate because you are only checking half of the numbers.
aitee
CC BY-SA 3.0
2018-01-01T23:28:28.750Z
@aitee Or you miss it entirely because you're only checking half the numbers.
David Z
CC BY-SA 3.0
2018-01-01T20:34:41.833Z
2018-01-01T20:34:41.833Z
Matthew Stannard
<blockquote>
  <p>Is it not possible to searching for only even nonces? Of course you risk the chance of missing the nonce, but you gain an effective 2x hash rate. </p>
</blockquote>

<p>Yes. It is of course possible. You are allowed to modify the whole mining software if the resulting block is a valid bitcoin-block. But you don't gain a 2x hash rate. It doesn't make any difference wheather you try all numbers between 0 and 29 or you try all even numbers between 0 and 59 because they are still only 30 numbers.</p>

<blockquote>
  <p>What if you search downwards for a nonce?</p>
</blockquote>

<p>As I said: You could do that. But it doesn't make any difference in average. The normal case: The difficulty is very high. So you need to try <strong>all</strong> the nonce-numbers (0-4.294.967.296). If no one else mined the block, you can change the timestamp or modifiy the coinbase-text and try all the nonces again and again because the hashes will be completly different then.</p>

<blockquote>
  <p>Skipping (even, odd, every third, etc).</p>
</blockquote>

<p>There is no advantage. It's actually <strong>a little disadvantage</strong> because you need to calculate <code>nonce++</code> 2 times instead of 1 time or you need to do the if statement <code>if(nonce%30==0)</code> or whatever instead of doing nothing. So you would waste energie, time and mining power instead of hashing a block.</p>

CC BY-SA 3.0
2018-01-01T23:24:25.363Z
Regarding your last paragraph: jumping by two can be implemented by `nonce += 2`. This would typically turn into a single instruction, in fact the same one used to implement `nonce++` except with 1 replaced by 2. So in that particular case, there is no disadvantage in execution time. Of course an if statement would take extra time but that's a rather inefficient way to do it.
David Z
CC BY-SA 3.0
2018-01-01T20:51:30.253Z
2018-01-01T20:51:30.253Z
hardfork
<p>A 2X rate with a 50% chance of missing a winning nonce is no advantage at all. Incrementing the nonce is the easiest mechanism of choosing the next nonce to try, so you try the most nonces per second that way. That's all that matters.</p>

<p>Perhaps you are under the mistaken impression that everyone is trying to mine the same block. That is not so. If you are a solo miner, you are the only one trying to mine a block that pays you the block reward. Nobody else is trying to mine the same block you are, so all that matters is how many tries you are able to accomplish. You aren't racing anyone else. If someone else finds a block, you don't care if they found it before you did or after you did (except in very rare instances where you both find a block at very close to the same time), you found a block either way.</p>

CC BY-SA 3.0
2018-01-01T21:41:10.000Z
I see, so a solution in a mining pool instance is just as rare as a solution found solo mining? For some reason I was under the impression that there was some partitioning within a mining pool.
aitee
CC BY-SA 3.0
2018-01-01T22:12:03.340Z
@aitee Mining pools intentionally give you easier problems to solve so they can measure your hash rate. But finding a block is the same.
David Schwartz
CC BY-SA 3.0
2018-01-01T22:39:16.037Z
Do you know of any information/documentation that contrasts pool mining with solo mining (from a technical perspective)?
aitee
CC BY-SA 3.0
2018-01-02T10:58:48.983Z
You should see the [Stratum protocol specification](https://en.bitcoin.it/wiki/Stratum_mining_protocol). This is the protocol used for communication between miners and pools. Althougth the protocol is not entirely specified anywhere, you may find some usefull information. You could also review the code some open-source pools (for example the [UNOMP node merged pool](https://github.com/UNOMP/node-merged-pool)).
Jules Lamur
CC BY-SA 3.0
2018-01-01T20:50:25.220Z
2018-01-01T20:50:25.220Z
David Schwartz
<p>As a solo miner, you have the disadvantage of a minuscule hash rate compared to mining pools. Is it not possible to searching for only even nonces? Of course you risk the chance of missing the nonce, but you gain an effective 2x hash rate. </p>

<p>I wonder how this or other nonce searching methods might impacts your chance on average.</p>

<ul>
<li>What if you search downwards for a nonce?</li>
<li>Skipping (even, odd, every third, etc).</li>
</ul>

<mining-theory><solo-mining><nonce>
Why search for a nonce linearly (+1) vs searching only even or odd nonces?
aitee
# Why search for a nonce linearly (+1) vs searching only even or odd nonces?

(Asked by: username_0 on 2018-01-01)

As a solo miner, you have the disadvantage of a minuscule hash rate compared to mining pools. Is it not possible to searching for only even nonces? Of course you risk the chance of missing the nonce, but you gain an effective 2x hash rate.

I wonder how this or other nonce searching methods might impacts your chance on average.

* What if you search downwards for a nonce?
* Skipping (even, odd, every third, etc).

**Tags:** mining-theory, solo-mining, nonce


---

## 4 answers

### Answer by username_5 on 2018-01-01. Score: 14 | Accepted answer

A 2X rate with a 50% chance of missing a winning nonce is no advantage at all. Incrementing the nonce is the easiest mechanism of choosing the next nonce to try, so you try the most nonces per second that way. That's all that matters.

Perhaps you are under the mistaken impression that everyone is trying to mine the same block. That is not so. If you are a solo miner, you are the only one trying to mine a block that pays you the block reward. Nobody else is trying to mine the same block you are, so all that matters is how many tries you are able to accomplish. You aren't racing anyone else. If someone else finds a block, you don't care if they found it before you did or after you did (except in very rare instances where you both find a block at very close to the same time), you found a block either way.

> **Comments:**
> **username_0**: I see, so a solution in a mining pool instance is just as rare as a solution found solo mining? For some reason I was under the impression that there was some partitioning within a mining pool.  
> **username_5**: @username_0 Mining pools intentionally give you easier problems to solve so they can measure your hash rate. But finding a block is the same.  
> **username_0**: Do you know of any information/documentation that contrasts pool mining with solo mining (from a technical perspective)?  
> **username_6**: You should see the [Stratum protocol specification](https://en.bitcoin.it/wiki/Stratum_mining_protocol). This is the protocol used for communication between miners and pools. Althougth the protocol is not entirely specified anywhere, you may find some usefull information. You could also review the code some open-source pools (for example the [UNOMP node merged pool](https://github.com/UNOMP/node-merged-pool)).  

---

### Answer by username_1 on 2018-01-01. Score: 2

You need to find any nonce, so that the block becomes valid.

It is of no regard, what algorithm you are using to chose a nonce, as long as the block meets or exceeds the difficulty target.


---

### Answer by username_2 on 2018-01-01. Score: 2

Alternative algorithms used for choosing the next nonce to hash will not improve upon a simple integer increment. You will still be checking the same number of hashes per second.

An increment of two instead of one will not double the hash rate. The hashing rate will be equal in both cases.

> **Comments:**
> **username_0**: I understand it doesn't really change the rate. But if the solution happens to be near the end of the range, you would reach it at twice the rate because you are only checking half of the numbers.  
> **username_3**: @username_0 Or you miss it entirely because you're only checking half the numbers.  

---

### Answer by username_4 on 2018-01-01. Score: 1

> Is it not possible to searching for only even nonces? Of course you risk the chance of missing the nonce, but you gain an effective 2x hash rate.

Yes. It is of course possible. You are allowed to modify the whole mining software if the resulting block is a valid bitcoin-block. But you don't gain a 2x hash rate. It doesn't make any difference wheather you try all numbers between 0 and 29 or you try all even numbers between 0 and 59 because they are still only 30 numbers.

> What if you search downwards for a nonce?

As I said: You could do that. But it doesn't make any difference in average. The normal case: The difficulty is very high. So you need to try **all** the nonce-numbers (0-4.294.967.296). If no one else mined the block, you can change the timestamp or modifiy the coinbase-text and try all the nonces again and again because the hashes will be completly different then.

> Skipping (even, odd, every third, etc).

There is no advantage. It's actually **a little disadvantage** because you need to calculate `nonce++` 2 times instead of 1 time or you need to do the if statement `if(nonce%30==0)` or whatever instead of doing nothing. So you would waste energie, time and mining power instead of hashing a block.

> **Comments:**
> **username_3**: Regarding your last paragraph: jumping by two can be implemented by `nonce += 2`. This would typically turn into a single instruction, in fact the same one used to implement `nonce++` except with 1 replaced by 2. So in that particular case, there is no disadvantage in execution time. Of course an if statement would take extra time but that's a rather inefficient way to do it.  

---

