<p>There's a difference between what is called a "golden nonce" in the context of the source and a valid block header hash.</p>

<p>To reduce payout variance, miners group into pools and share their income proportionally to their hashpower. </p>

<p>To determine each miner's hashpower, pools use a share system: when you are mining and find a block header of high difficulty (with lots of heading zeroes) but not high enough to be above the current target, you send it to the pool. These difficult-but-not-enough headers are called "shares".</p>

<p>Since finding them is way more frequent than blocks (miners often send several of them per second), no matter how small your hashpower is, it will still be taken in account at payout time even if you're unlucky. The more shares you send, the more hashpower you have, the bigger the share of the pool's income you will get.</p>

<p>They are not broadcast to the bitcoin network, since they would be immediately rejected there and are of no value to anyone but the miner that found them and the pool software.</p>

CC BY-SA 3.0
2017-07-12T07:54:48.493Z
This doesn't address his question at all.  You seem to be answering something totally irrelevant.
Mr.Nobody
CC BY-SA 3.0
2017-07-12T08:33:43.627Z
The context of the question is a post about FPGA software. Source's OP is wondering why there's no stop condition when searching valid nonces. That's because the firmware is designed to run through all nonces in search of "difficulty 1 shares", not valid block headers since the FPGA has no notion of what is the current difficulty. As valid block headers _are_ difficulty 1 shares too, sending them to the pool server will trigger the broadcast of a block and the sending of new work to the FPGA.
alcio
CC BY-SA 3.0
2017-07-12T16:44:08.193Z
This looks like the right answer to me.
Pieter Wuille
CC BY-SA 3.0
2017-07-13T18:08:18.417Z
Me too.  The "best interest" part is about proving the amount of hash plower you are supplying to the pool, and not about finding the next block.
Jestin
CC BY-SA 3.0
2017-07-12T07:49:20.983Z
2017-07-12T18:19:22.643Z
2017-07-12T18:19:22.643Z
alcio
<p>I'm still new at trying to understand the entire idea surrounding the mining process.</p>
<p>I read the following:</p>
<blockquote>
<p>When mining, you are given a set of data to perform hashes on. As you
noted, this is done by manipulating the nonce and hashing each time
the nonce changes. What you really want to do is check all possible
nonces. Even if you've already found a &quot;golden nonce&quot; (one which gives
you a hash starting with 32 zeros), you need to keep searching for
more. There could be anywhere between 0 and 2^32 solutions to a given
block of work, so it is in your best interest to keep looking for
more. Hence, there are no stop conditions in the sense of when to stop
running your algorithm, other than having exhausted all possible
nonces (at which point, you would get more work).</p>
</blockquote>
<p><a href="https://bitcointalk.org/index.php?topic=75609.msg837556#msg837556" rel="nofollow noreferrer">Source</a></p>
<p>This confused me, because I thought that once you found a golden nonce, you can broadcast that to the network and move on. Why would you continue to check for more? Is it because if you let's say found 5 golden nonces and broadcasted all of them as you found them, you'd have a higher probability that the next block would be building off the one you found? Adding onto that, if many people find valid nonces to a block, how is the winner of the reward, and which gets included in the main chain, determined?</p>

<blockchain><block><hash><nonce>
Why check for multiple nonces despite finding a golden nonce?
rb612
# Why check for multiple nonces despite finding a golden nonce?

(Asked by: username_0 on 2017-07-12)

I'm still new at trying to understand the entire idea surrounding the mining process.

I read the following:

> When mining, you are given a set of data to perform hashes on. As you
> noted, this is done by manipulating the nonce and hashing each time
> the nonce changes. What you really want to do is check all possible
> nonces. Even if you've already found a "golden nonce" (one which gives
> you a hash starting with 32 zeros), you need to keep searching for
> more. There could be anywhere between 0 and 2^32 solutions to a given
> block of work, so it is in your best interest to keep looking for
> more. Hence, there are no stop conditions in the sense of when to stop
> running your algorithm, other than having exhausted all possible
> nonces (at which point, you would get more work).

[Source](https://bitcointalk.org/index.php?topic=75609.msg837556#msg837556)

This confused me, because I thought that once you found a golden nonce, you can broadcast that to the network and move on. Why would you continue to check for more? Is it because if you let's say found 5 golden nonces and broadcasted all of them as you found them, you'd have a higher probability that the next block would be building off the one you found? Adding onto that, if many people find valid nonces to a block, how is the winner of the reward, and which gets included in the main chain, determined?

**Tags:** blockchain, block, hash, nonce


---

## 1 answers

### Answer by username_1 on 2017-07-12. Score: 5 | Accepted answer

There's a difference between what is called a "golden nonce" in the context of the source and a valid block header hash.

To reduce payout variance, miners group into pools and share their income proportionally to their hashpower.

To determine each miner's hashpower, pools use a share system: when you are mining and find a block header of high difficulty (with lots of heading zeroes) but not high enough to be above the current target, you send it to the pool. These difficult-but-not-enough headers are called "shares".

Since finding them is way more frequent than blocks (miners often send several of them per second), no matter how small your hashpower is, it will still be taken in account at payout time even if you're unlucky. The more shares you send, the more hashpower you have, the bigger the share of the pool's income you will get.

They are not broadcast to the bitcoin network, since they would be immediately rejected there and are of no value to anyone but the miner that found them and the pool software.

> **Comments:**
> **username_2**: This doesn't address his question at all.  You seem to be answering something totally irrelevant.  
> **username_1**: The context of the question is a post about FPGA software. Source's OP is wondering why there's no stop condition when searching valid nonces. That's because the firmware is designed to run through all nonces in search of "difficulty 1 shares", not valid block headers since the FPGA has no notion of what is the current difficulty. As valid block headers _are_ difficulty 1 shares too, sending them to the pool server will trigger the broadcast of a block and the sending of new work to the FPGA.  
> **username_3**: This looks like the right answer to me.  
> **username_4**: Me too.  The "best interest" part is about proving the amount of hash plower you are supplying to the pool, and not about finding the next block.  

---

