<p>Finding a hash that is less than the target requires more work (not harder, there is nothing that makes hashing harder to do), i.e. more hashes. This is because there are more numbers with more digits (and thus larger) than there are with less digits. For example, there are 90 numbers with 2 digits, compared to only 10 with 1 digit. This is an exponential distribution. Because of this distribution, more work is required as the target is made smaller because you are significantly reducing the set of all possible valid hashes.</p>

CC BY-SA 3.0
2017-08-06T05:54:46.490Z
2017-08-06T05:54:46.490Z
Ava Chow
<p>A hash is 256 bits long, so there are 2^256 possible hashes in the hash space. But if you assert that the hash has to begin with a 0, that halves the number of hashes that are allowed (and thus doubles the average number of hashes you need to test), and if you say it must start with two 0's, that's now only quarter of the hash space that is valid. The difficulty of finding a valid hash thus grows exponentially with the number of 0's you require at the start. </p>

<p>But as you said, because the hashes are uniformly distributed, there is nothing unique about requiring the hash start with x number of 0's. Requiring the hash to start with x number of 1's would be the same, as would any specific sequence of 1's and 0's be. 0's are just a nice choice and make sense in practice, because like you said, you are then computing a hash less than a specific number. </p>

<p>Just to point out the terminology difference by the way, it's not targeting a specific hash, it's targeting a specific <strong>subset</strong> of the possible hashes. To find a specific hash would mean SHA-256 is broken, because you are basically reversing the hashing operation.</p>

CC BY-SA 3.0
2017-08-06T06:05:24.653Z
Thanks for the explanation. Realizing that there's a whole set of acceptable hash values for the problem as specified by the difficulty number clarified this for me. :)
CodeMangler
CC BY-SA 3.0
2017-08-06T05:54:27.940Z
2017-08-06T05:54:27.940Z
meshcollider
<p>Based on my rudimentary understanding of Bitcoins and altcoins, network difficulty is adjusted by asking the network to target a hash smaller than a specific number, which translates to calculating nonce for a hash with a certain number of zeros prefixed to it.</p>

<p>Since hash values are supposed to be uniformly distributed, I don't understand why targeting a hash value with a specific number of zeroes is any more easy/difficult than targeting any other hash (not the hash value of the content without nonce obviously). I think targeting any of the possible hash values, except what the content already hashes to, should be equally difficult. Why is that not the case?</p>

<p>It's very likely that my understanding of Bitcoin network difficulty itself is wrong, in which case, could you please explain that to me?</p>

CC BY-SA 3.0
2017-08-06T05:43:19.747Z
Why do you think it's harder to look for hashes with a certain number of leading `0`s than it is to find hashes that start with, say, `a7e741e671d7401bfd4`?
Geremia
CC BY-SA 3.0
2017-08-06T05:49:47.830Z
Actually, I don't think it should be any harder to look for hashes starting with a certain number of leading zeroes than it is to look for any other hash. But the Bitcoin/altcoin network difficulty settings seem to work that way. It's possible I'm misunderstanding how Bitcoin network difficulty works, which is why I asked this question.
CodeMangler
<bitcoin-core><altcoin><difficulty>
Why is it harder to compute nonce for a hash with a certain number zero prefixes than it is for any other hash?
CodeMangler
# Why is it harder to compute nonce for a hash with a certain number zero prefixes than it is for any other hash?

(Asked by: username_0 on 2017-08-06)

Based on my rudimentary understanding of Bitcoins and altcoins, network difficulty is adjusted by asking the network to target a hash smaller than a specific number, which translates to calculating nonce for a hash with a certain number of zeros prefixed to it.

Since hash values are supposed to be uniformly distributed, I don't understand why targeting a hash value with a specific number of zeroes is any more easy/difficult than targeting any other hash (not the hash value of the content without nonce obviously). I think targeting any of the possible hash values, except what the content already hashes to, should be equally difficult. Why is that not the case?

It's very likely that my understanding of Bitcoin network difficulty itself is wrong, in which case, could you please explain that to me?

**Tags:** bitcoin-core, altcoin, difficulty

> **Comments:**
> **username_1**: Why do you think it's harder to look for hashes with a certain number of leading `0`s than it is to find hashes that start with, say, `a7e741e671d7401bfd4`?  
> **username_0**: Actually, I don't think it should be any harder to look for hashes starting with a certain number of leading zeroes than it is to look for any other hash. But the Bitcoin/altcoin network difficulty settings seem to work that way. It's possible I'm misunderstanding how Bitcoin network difficulty works, which is why I asked this question.  

---

## 2 answers

### Answer by username_3 on 2017-08-06. Score: 14 | Accepted answer

A hash is 256 bits long, so there are 2^256 possible hashes in the hash space. But if you assert that the hash has to begin with a 0, that halves the number of hashes that are allowed (and thus doubles the average number of hashes you need to test), and if you say it must start with two 0's, that's now only quarter of the hash space that is valid. The difficulty of finding a valid hash thus grows exponentially with the number of 0's you require at the start.

But as you said, because the hashes are uniformly distributed, there is nothing unique about requiring the hash start with x number of 0's. Requiring the hash to start with x number of 1's would be the same, as would any specific sequence of 1's and 0's be. 0's are just a nice choice and make sense in practice, because like you said, you are then computing a hash less than a specific number.

Just to point out the terminology difference by the way, it's not targeting a specific hash, it's targeting a specific **subset** of the possible hashes. To find a specific hash would mean SHA-256 is broken, because you are basically reversing the hashing operation.

> **Comments:**
> **username_0**: Thanks for the explanation. Realizing that there's a whole set of acceptable hash values for the problem as specified by the difficulty number clarified this for me. :)  

---

### Answer by username_2 on 2017-08-06. Score: 5

Finding a hash that is less than the target requires more work (not harder, there is nothing that makes hashing harder to do), i.e. more hashes. This is because there are more numbers with more digits (and thus larger) than there are with less digits. For example, there are 90 numbers with 2 digits, compared to only 10 with 1 digit. This is an exponential distribution. Because of this distribution, more work is required as the target is made smaller because you are significantly reducing the set of all possible valid hashes.


---

