<p>The difficulty is actually represented by the target threshold encoded in the <code>nBits</code> value in the block header. Where difficulty represents the human readable representation ("how often do we need to try to find a solution"), the target threshold defines the prefix a block must undershoot in order to be valid. This means that the 256-bit block hash interpreted as a number must be lower than the target threshold.
Although, <code>nBits</code> is only a 4-byte value, it is a compressed representation of a 256-bit (32-byte) number. The first byte defines the exponent, the remaining three bytes give a 24-bit mantissa for the target.</p>

<p>While this leaves most of the 32 byte in the target threshold to be just composed of zeroes, the difficulty can adjust in a much more granular fashion than just adding leading zeros.</p>

<p>David Harding has elaborated the full details in <a href="https://bitcoin.stackexchange.com/a/36228/5406">How is the target section of a block header calculated?</a>.</p>

CC BY-SA 4.0
2020-01-27T07:37:12.433Z
Ok I understand that nBits is actually the difficulty target, which is part of the header. I still don't understand what this has to do with the header hash leading zeroes: I assume a full node takes the header, double sha256s it and gets a header hash that it compares to the nBits to see if it's right. Correct? My question is how are those leading zeroes more granular for finding the right hash of the header? I think I'm missing something here..
zndtoshi
CC BY-SA 4.0
2020-01-27T19:12:51.197Z
Replacing a leading one with a leading zero doubles the difficulty, while lowering a 24-bit prefix by one count only increases the difficulty by a factor of 1.00000006.
Murch
CC BY-SA 4.0
2020-01-27T19:21:19.900Z
@zndtoshi I think your confusion stems from the common (but wrong) saying that PoW is about "the number of leading zeroes". It is not, at all. The PoW rule is that the block hash, when interpreted as a number, must be below the target. `nBits` is a compact encoding of the target.
Pieter Wuille
CC BY-SA 4.0
2020-01-29T07:26:01.910Z
Ok. So the target is given by nBits (which is very granular and that's perfect). But if this is true, why do you need zeroes in front of the header hash? Wouldn't you just take the nBits target and verify the header hash is correct?
Or are the hash header leading zeros exponentially increasing difficulty?
zndtoshi
CC BY-SA 4.0
2020-01-29T15:36:06.690Z
I'm not sure I understand the question. The target is so low that for a header hash to undershoot it, there are a number of leading zeroes. If you always represent your numbers with 9 digits, but have to pick one below two thousand, you'll always have five leading zeroes. But it's still a difference whether you have hit below 2000 or below 1999.
Murch
CC BY-SA 4.0
2020-01-27T06:23:12.003Z
2020-01-27T19:07:11.567Z
2020-01-27T19:07:11.567Z
Murch
<p>As a complement to @Murch's answer, I'd like to cite an example from <a href="http://rosenbaum.se/book/grokking-bitcoin-7.html#_forcing_honest_lucky_numbers" rel="nofollow noreferrer">Grokking Bitcoin</a>:</p>

<blockquote>
  <p>The target is written in the block header as 4 bytes, <code>ABCD</code>; the
  32-byte target is calculated as <code>BCD</code> × 2^(8*(A-3)). That’s <code>BCD</code> with
  <code>A-3</code> zero bytes after it. It’s this awkward because we must be able
  to express a wide range of targets, 1–2^256, with only 32 bits. The
  target in Qi’s [a character in the book] block is written as
  <code>1c926eb9</code>, meaning <code>926eb9</code> with 25 zero bytes after (<code>1c–3 = 19</code>,
  hex code for 25).</p>
</blockquote>

CC BY-SA 4.0
2020-02-26T12:33:31.630Z
2020-02-26T12:33:31.630Z
Kalle Rosenbaum
<p>Difficulty adjusts by very granular percentages to target for 10 minutes blocks. But adding another zero at the end of the chain of zeroes from the header hash requirement for a valid block would increase the difficulty exponential. So how does the Alogrithm target so precisely the right difficuly only through the use of "zeroes"?</p>

CC BY-SA 4.0
2020-01-27T16:36:12.740Z
The number of leading zeroes is never, at any point, ever, taken into account.
FrownyFrog
<hash><difficulty><block><difficulty-retargetting>
Bitcoin Difficulty granularity
zndtoshi
# Bitcoin Difficulty granularity

(Asked by: username_0 on 2020-01-27)

Difficulty adjusts by very granular percentages to target for 10 minutes blocks. But adding another zero at the end of the chain of zeroes from the header hash requirement for a valid block would increase the difficulty exponential. So how does the Alogrithm target so precisely the right difficuly only through the use of "zeroes"?

**Tags:** hash, difficulty, block, difficulty-retargetting

> **Comments:**
> **username_1**: The number of leading zeroes is never, at any point, ever, taken into account.  

---

## 2 answers

### Answer by username_2 on 2020-01-27. Score: 3

The difficulty is actually represented by the target threshold encoded in the `nBits` value in the block header. Where difficulty represents the human readable representation ("how often do we need to try to find a solution"), the target threshold defines the prefix a block must undershoot in order to be valid. This means that the 256-bit block hash interpreted as a number must be lower than the target threshold.
Although, `nBits` is only a 4-byte value, it is a compressed representation of a 256-bit (32-byte) number. The first byte defines the exponent, the remaining three bytes give a 24-bit mantissa for the target.

While this leaves most of the 32 byte in the target threshold to be just composed of zeroes, the difficulty can adjust in a much more granular fashion than just adding leading zeros.

David Harding has elaborated the full details in [How is the target section of a block header calculated?](https://bitcoin.stackexchange.com/a/36228/5406).

> **Comments:**
> **username_0**: Ok I understand that nBits is actually the difficulty target, which is part of the header. I still don't understand what this has to do with the header hash leading zeroes: I assume a full node takes the header, double sha256s it and gets a header hash that it compares to the nBits to see if it's right. Correct? My question is how are those leading zeroes more granular for finding the right hash of the header? I think I'm missing something here..  
> **username_2**: Replacing a leading one with a leading zero doubles the difficulty, while lowering a 24-bit prefix by one count only increases the difficulty by a factor of 1.00000006.  
> **username_3**: @username_0 I think your confusion stems from the common (but wrong) saying that PoW is about "the number of leading zeroes". It is not, at all. The PoW rule is that the block hash, when interpreted as a number, must be below the target. `nBits` is a compact encoding of the target.  
> **username_0**: Ok. So the target is given by nBits (which is very granular and that's perfect). But if this is true, why do you need zeroes in front of the header hash? Wouldn't you just take the nBits target and verify the header hash is correct? Or are the hash header leading zeros exponentially increasing difficulty?  
> **username_2**: I'm not sure I understand the question. The target is so low that for a header hash to undershoot it, there are a number of leading zeroes. If you always represent your numbers with 9 digits, but have to pick one below two thousand, you'll always have five leading zeroes. But it's still a difference whether you have hit below 2000 or below 1999.  

---

### Answer by username_4 on 2020-02-26. Score: 1

As a complement to @username_2's answer, I'd like to cite an example from [Grokking Bitcoin](http://username_4.se/book/grokking-bitcoin-7.html#_forcing_honest_lucky_numbers):

> The target is written in the block header as 4 bytes, `ABCD`; the
> 32-byte target is calculated as `BCD` × 2^(8\*(A-3)). That’s `BCD` with
> `A-3` zero bytes after it. It’s this awkward because we must be able
> to express a wide range of targets, 1–2^256, with only 32 bits. The
> target in Qi’s [a character in the book] block is written as
> `1c926eb9`, meaning `926eb9` with 25 zero bytes after (`1c–3 = 19`,
> hex code for 25).


---

