<ol>
<li><p>Look at these numbers in binary.  A hex digit is 4 bits, so 7 in hex is 0111 binary, 3 is 0011, 1 is 0001.  You can see that 7 is the largest hex digit in which the most significant bit is 0; 3 is the largest hex digit in which the two most significant bits are 0; and so on.</p></li>
<li><p>Yes, you can get this same value by taking the log<sub>2</sub> of the hash value and subtracting from 256 (which is the total number of bits in the hash).  Note that the number of leading zero bits of the hash (including "fractional bits") is required to be less than or equal to the target difficulty, but in general is much more likely to be less.</p></li>
</ol>

CC BY-SA 3.0
2017-09-03T18:03:23.193Z
I sincerely, sincerely appreciate your response. Thanks a ton @Nate.
John Doe
CC BY-SA 3.0
2017-09-03T16:17:50.980Z
2017-09-03T16:17:50.980Z
Nate Eldredge
<p>Had been reading a post written by Adam Back a couple years back (no pun intended) with regards to calculating bitcoin difficulty in bits (so we could arrive to the number of hashes roughly needed before a solution to a block is found).</p>

<p>The equation being log<sub>2</sub>(difficulty)+32.</p>

<p>Link: <a href="https://bitcointalk.org/index.php?topic=192886.0" rel="nofollow noreferrer">https://bitcointalk.org/index.php?topic=192886.0</a></p>

<p>From his post I also understood we could also find the difficulty in bits via the block hash in hex, i.e. each leading zero * 4, then check the next hex char with the following rule: >7=+0bits, >3=+1bit, >1=+2bits, 1=+3bits.</p>

<p>Question being:</p>

<ol>
<li><p>What is the intuition to Adam's elaboration of >7=+0bits, >3=+1bit, >1=+2bits, 1=+3bits? Maybe there is something with regards to hex conversion that I need to catch up on?</p></li>
<li><p>With log<sub>2</sub>(difficulty)+32, we could arrive to a fractional bit (e.g. 54.8713). Would it be possible to derive the same fractional bit given the leading block hash values, or are we at best left with an approximation?</p></li>
</ol>

<p>Thanks in advance!</p>

<block-hash>
Leading zeros and numbers of hashes before arriving to solution
John Doe
# Leading zeros and numbers of hashes before arriving to solution

(Asked by: username_0 on 2017-09-03)

Had been reading a post written by Adam Back a couple years back (no pun intended) with regards to calculating bitcoin difficulty in bits (so we could arrive to the number of hashes roughly needed before a solution to a block is found).

The equation being log2(difficulty)+32.

Link: <https://bitcointalk.org/index.php?topic=192886.0>

From his post I also understood we could also find the difficulty in bits via the block hash in hex, i.e. each leading zero \* 4, then check the next hex char with the following rule: >7=+0bits, >3=+1bit, >1=+2bits, 1=+3bits.

Question being:

1. What is the intuition to Adam's elaboration of >7=+0bits, >3=+1bit, >1=+2bits, 1=+3bits? Maybe there is something with regards to hex conversion that I need to catch up on?
2. With log2(difficulty)+32, we could arrive to a fractional bit (e.g. 54.8713). Would it be possible to derive the same fractional bit given the leading block hash values, or are we at best left with an approximation?

Thanks in advance!

**Tags:** block-hash


---

## 1 answers

### Answer by username_1 on 2017-09-03. Score: 1 | Accepted answer

1. Look at these numbers in binary. A hex digit is 4 bits, so 7 in hex is 0111 binary, 3 is 0011, 1 is 0001. You can see that 7 is the largest hex digit in which the most significant bit is 0; 3 is the largest hex digit in which the two most significant bits are 0; and so on.
2. Yes, you can get this same value by taking the log2 of the hash value and subtracting from 256 (which is the total number of bits in the hash). Note that the number of leading zero bits of the hash (including "fractional bits") is required to be less than or equal to the target difficulty, but in general is much more likely to be less.

> **Comments:**
> **username_0**: I sincerely, sincerely appreciate your response. Thanks a ton @username_1.  

---

