<p>For a given combination of</p>

<p>version(4b) + prevBlockHash(32b) + merkleHash(32b) + ctimestamp(4b) + ctarget(4b),</p>

<p>There is no guarantee that there will be a valid nonce. There usually isn't - the probability that there will be is 1 divided by the difficulty, which is currently 9 billion. So miners try different combinations, try the nonce range for each, until they find a valid solution.</p>

<p>a) The most general method is to change extraneous data in the generation transaction to change the Merkle root. Currently, to reduce communication overhead between the pool and miners, a method such as GBT is used, where the miner gets a block template and can fill in the generation transaction himself.</p>

<p>b) No; hashing, like much of the core cryptographic primitives, is kind of a "dark art" - there's little in the way of proof that it all works. Let's say you fix just the prevBlockHash, there is no proof that you can fill in the other details to obtain a valid hash. However, if hash functions behave more or less the way we think they do, it is extremely unlikely there will be no solution.</p>

CC BY-SA 3.0
2014-05-14T04:22:07.613Z
b) If it did happen, we could always go back a block (or more) and make a longer chain, assuming a longer chain exists (ie that we don't hit another unsolvable block). Of course this would reverse some transactions.
Tyler
CC BY-SA 3.0
2014-05-13T09:28:14.153Z
2014-05-13T09:40:32.933Z
2014-05-13T09:40:32.933Z
Meni Rosenfeld
<p>Given the current hashing powers, what do pools actually do in practice to find a block?</p>

<p>Ok, so here is my thinking, please correct me if I'm wrong anywhere:</p>

<ol>
<li>Here's the format of the block header, the thing which is actually hashed:</li>
</ol>

<blockquote>
  <p>version(4b) + prevBlockHash(32b) + merkleHash(32b) + ctimestamp(4b) +
  ctarget(4b) + nonce(4b);</p>
</blockquote>

<ol>
<li>So, canonically, what miners do is going through all the possible values of the last NONCE(4 bytes).</li>
<li>If we treat that as unsigned int, the range would be 0-4294967295.</li>
<li>Right now you can buy a 2Ghs miner for &lt; $100.</li>
<li>Given that you have something that can hash 2GHs(very cheap solution, I'm not even talking about THs systems that pools reportedly have), you could bruteforce through the range of 0:4294967295 in less than 3 seconds.</li>
</ol>

<p>So, the question is, what keeps mining in that ~10min period?</p>

<p>My suspicion is that its not that much of a problem to find a nonce anymore, its more a problem to find the proper block that will actually have a nonce.</p>

<p>If that is true: </p>

<p>a) what do miners do in practice, play around with the timestamp, or generate some transactions to change the merkle root?</p>

<p>b) is there any mathematical proof that such a block will ever be found? I mean, bitcoin not getting stuck, because of some unfortunate block having such a bad coincidence of bits that will endup blocking the result from getting enough zeros in the end to fit the target(I'm asking about mathematical proof that it is impossible).</p>

CC BY-SA 3.0
2014-05-13T07:30:29.863Z
related: [How do mining pools distribute work effectively?](http://bitcoin.stackexchange.com/q/12955/5406)
Murch
CC BY-SA 3.0
2014-05-13T15:21:54.417Z
The timestamp should change every second anyway, it's only when you get over 2^32 hash/sec that this becomes an issue. (the question is still perfectly valid, just with a >4.3GHs miner, not a 2GHs miner)
Tim S.
CC BY-SA 3.0
2014-05-13T20:13:56.613Z
Regarding (b), see [How come you know that a proof will be found so that the hash function will produce 000…xxx…?](https://bitcoin.stackexchange.com/questions/22978/how-come-you-know-that-a-proof-will-be-found-so-that-the-hash-function-will-prod)
Greg Hewgill
<mining-pools><protocol><mining-technical-details>
Given the current hashing powers, what do pools actually do in practice?
user15745
# Given the current hashing powers, what do pools actually do in practice?

(Asked by: username_0 on 2014-05-13)

Given the current hashing powers, what do pools actually do in practice to find a block?

Ok, so here is my thinking, please correct me if I'm wrong anywhere:

1. Here's the format of the block header, the thing which is actually hashed:

> version(4b) + prevBlockHash(32b) + merkleHash(32b) + ctimestamp(4b) +
> ctarget(4b) + nonce(4b);

1. So, canonically, what miners do is going through all the possible values of the last NONCE(4 bytes).
2. If we treat that as unsigned int, the range would be 0-4294967295.
3. Right now you can buy a 2Ghs miner for < $100.
4. Given that you have something that can hash 2GHs(very cheap solution, I'm not even talking about THs systems that pools reportedly have), you could bruteforce through the range of 0:4294967295 in less than 3 seconds.

So, the question is, what keeps mining in that ~10min period?

My suspicion is that its not that much of a problem to find a nonce anymore, its more a problem to find the proper block that will actually have a nonce.

If that is true:

a) what do miners do in practice, play around with the timestamp, or generate some transactions to change the merkle root?

b) is there any mathematical proof that such a block will ever be found? I mean, bitcoin not getting stuck, because of some unfortunate block having such a bad coincidence of bits that will endup blocking the result from getting enough zeros in the end to fit the target(I'm asking about mathematical proof that it is impossible).

**Tags:** mining-pools, protocol, mining-technical-details

> **Comments:**
> **username_1**: related: [How do mining pools distribute work effectively?](http://bitcoin.stackexchange.com/q/12955/5406)  
> **username_2**: The timestamp should change every second anyway, it's only when you get over 2^32 hash/sec that this becomes an issue. (the question is still perfectly valid, just with a >4.3GHs miner, not a 2GHs miner)  
> **username_3**: Regarding (b), see [How come you know that a proof will be found so that the hash function will produce 000…xxx…?](https://bitcoin.stackexchange.com/questions/22978/how-come-you-know-that-a-proof-will-be-found-so-that-the-hash-function-will-prod)  

---

## 1 answers

### Answer by username_4 on 2014-05-13. Score: 1 | Accepted answer

For a given combination of

version(4b) + prevBlockHash(32b) + merkleHash(32b) + ctimestamp(4b) + ctarget(4b),

There is no guarantee that there will be a valid nonce. There usually isn't - the probability that there will be is 1 divided by the difficulty, which is currently 9 billion. So miners try different combinations, try the nonce range for each, until they find a valid solution.

a) The most general method is to change extraneous data in the generation transaction to change the Merkle root. Currently, to reduce communication overhead between the pool and miners, a method such as GBT is used, where the miner gets a block template and can fill in the generation transaction himself.

b) No; hashing, like much of the core cryptographic primitives, is kind of a "dark art" - there's little in the way of proof that it all works. Let's say you fix just the prevBlockHash, there is no proof that you can fill in the other details to obtain a valid hash. However, if hash functions behave more or less the way we think they do, it is extremely unlikely there will be no solution.

> **Comments:**
> **username_5**: b) If it did happen, we could always go back a block (or more) and make a longer chain, assuming a longer chain exists (ie that we don't hit another unsolvable block). Of course this would reverse some transactions.  

---

