# Why check for multiple nonces despite finding a golden nonce?

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

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

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?

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.

• This doesn't address his question at all. You seem to be answering something totally irrelevant. Jul 12, 2017 at 7:54
• 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. Jul 12, 2017 at 8:33
• This looks like the right answer to me. Jul 12, 2017 at 16:44
• 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. Jul 13, 2017 at 18:08