<blockquote>
<p>Not understanding the math behind it in-depth, the best answer I can come up with is that the protocol requires that the proof of work hash (hash of nonce and block data) should be equal to or lower than the difficulty target. Hence, you can interpret it as having to contain a certain number of leading 0s.</p>
</blockquote>
<p>This is exactly what it is. The actual calculation has nothing to do with leading 0s. It's entirely just a comparison of integers, which has the effect of producing leading 0s.</p>

CC BY-SA 4.0
2021-08-08T22:45:58.617Z
I think the explanation with "number of zeroes" has a historical reason: hashcash, the original PoW system, had a "difficulty" that was actually the number of zero bits up front in the hash. Bitcoin's proof of work is based on it, but generalized to a big integer comparison.
Pieter Wuille
CC BY-SA 4.0
2021-08-08T22:59:05.957Z
@andrew-chow thank you for your answer. Say if difficulty target was 0F in hexadecimal. Then the PoW hash could be anything between 00 to 0E. In this case the number of leading 0s required is 1, but that is not sufficient. The second number needs to be between 0 and E inclusive. Is this correct?
septerr
CC BY-SA 4.0
2021-08-09T00:59:53.877Z
Correct. Even the earliest instances of the code pay no attention to the number of leading 0s and really have the requirement of being smaller than a given target.

Here's a code snippet of how hash target was adjusted (it was effectively multiplied by the ratio of actual time taken over the time desired by satoshi) -- https://github.com/bitcoin/bitcoin/blob/4405b78d6059e536c36974088a8ed4d9f0f29898/main.cpp#L716.

Here's a code snippet where the comparison was actually made -- https://github.com/bitcoin/bitcoin/blob/4405b78d6059e536c36974088a8ed4d9f0f29898/main.cpp#L2345
Randy
CC BY-SA 4.0
2021-08-08T20:43:48.437Z
2021-08-08T20:43:48.437Z
Ava Chow
<p>I do a sort of bitcoin 101 presentation for folks where I work. In one of the recent sessions, someone asked why the proof of work difficulty requires a minimum number of leading 0s. Why not 1s or something else?</p>
<p>Not understanding the math behind it in-depth, the best answer I can come up with is that the protocol requires that the proof of work hash (hash of nonce and block data) should be equal to or lower than the difficulty target. Hence, you can interpret it as having to contain a certain number of leading 0s.</p>
<p>Is there a better explanation?</p>
<p>Thanks!</p>

<difficulty>
Bitcoin difficulty - why leading 0s?
septerr
# Bitcoin difficulty - why leading 0s?

(Asked by: username_0 on 2021-08-08)

I do a sort of bitcoin 101 presentation for folks where I work. In one of the recent sessions, someone asked why the proof of work difficulty requires a minimum number of leading 0s. Why not 1s or something else?

Not understanding the math behind it in-depth, the best answer I can come up with is that the protocol requires that the proof of work hash (hash of nonce and block data) should be equal to or lower than the difficulty target. Hence, you can interpret it as having to contain a certain number of leading 0s.

Is there a better explanation?

Thanks!

**Tags:** difficulty


---

## 1 answers

### Answer by username_1 on 2021-08-08. Score: 7 | Accepted answer

> Not understanding the math behind it in-depth, the best answer I can come up with is that the protocol requires that the proof of work hash (hash of nonce and block data) should be equal to or lower than the difficulty target. Hence, you can interpret it as having to contain a certain number of leading 0s.

This is exactly what it is. The actual calculation has nothing to do with leading 0s. It's entirely just a comparison of integers, which has the effect of producing leading 0s.

> **Comments:**
> **username_2**: I think the explanation with "number of zeroes" has a historical reason: hashcash, the original PoW system, had a "difficulty" that was actually the number of zero bits up front in the hash. Bitcoin's proof of work is based on it, but generalized to a big integer comparison.  
> **username_0**: @andrew-username_1 thank you for your answer. Say if difficulty target was 0F in hexadecimal. Then the PoW hash could be anything between 00 to 0E. In this case the number of leading 0s required is 1, but that is not sufficient. The second number needs to be between 0 and E inclusive. Is this correct?  
> **username_3**: Correct. Even the earliest instances of the code pay no attention to the number of leading 0s and really have the requirement of being smaller than a given target.  Here's a code snippet of how hash target was adjusted (it was effectively multiplied by the ratio of actual time taken over the time desired by satoshi) -- https://github.com/bitcoin/bitcoin/blob/4405b78d6059e536c36974088a8ed4d9f0f29898/main.cpp#L716.  Here's a code snippet where the comparison was actually made -- https://github.com/bitcoin/bitcoin/blob/4405b78d6059e536c36974088a8ed4d9f0f29898/main.cpp#L2345  

---

