<p><em>Difficulty</em> is not the same as <em>target hash</em> (target in short).</p>

<p>They are inversely related, so minimal possible difficulty (of 1) gives <em>maximal target</em>, by definition given as (<a href="https://en.bitcoin.it/wiki/Target" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Target</a>): </p>

<blockquote>
  <p>0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF</p>
  
  <p>Because Bitcoin stores the target as a floating-point type, this is
  truncated:</p>
  
  <p>0x00000000FFFF0000000000000000000000000000000000000000000000000000</p>
</blockquote>

<p>The current difficulty is calculated as <em>maximal target</em> divided by the current target. For example (<a href="https://en.bitcoin.it/wiki/Difficulty" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Difficulty</a>):</p>

<blockquote>
  <p>0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
  0x00000000000404CB000000000000000000000000000000000000000000000000 
  = 16307.420938523983</p>
</blockquote>

<p>So in your example the Difficulty = 1,347,001,430,558.57 would give the current target of:</p>

<blockquote>
  <p>current_target = 
  0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
  1,347,001,430,558.57</p>
</blockquote>

<p>If you calculate this (take care as one number is hexadecimal and other decimal), the comparison should give that this current_target is higher than the mined hash of: </p>

<blockquote>
  <p>0x000000000000000000cf3620d570d08d1799a1cafbbfae512fdba2124665eca0</p>
</blockquote>

<p>EDIT: Pen and paper calculation gives me that the current target is around:</p>

<blockquote>
  <p>0x000000000000000000FFFF000000000000000000000000000000000000000000</p>
</blockquote>

<p>How I got this. 1,347,001,430,558.57 is around 1.225 * (16^10). As the target is in base 16, this means that dividing by 1 * (16^10) is like shifting the digits 10 places to the right. To get precise result after digits shifting I should divide by 1.225, but I ignored this in this pen and paper calculation.</p>

<p>EDIT2: To be even more precise I take 16/1.225 is around 13 (<em>D</em> in hex), so the target is around:</p>

<blockquote>
  <p>0x000000000000000000D000000000000000000000000000000000000000000000</p>
</blockquote>

CC BY-SA 4.0
2018-06-24T09:58:32.667Z
Why does `0x00000000FFFF0000000000000000000000000000000000000000000000000000` represent the truncated floating-point type version of `0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF`?
Paul Razvan Berg
CC BY-SA 3.0
2017-11-30T11:15:07.480Z
2017-11-30T11:31:31.060Z
2017-11-30T11:31:31.060Z
croraf
<p>In the validation of a block it is said that a miner has a valid block if the transactions can be tracked in the chain and the hash of the block header is less than the difficulty. I am having a hard time seeing the relationship in real world blocks that are being solved.</p>

<p>For Example from <a href="https://blockchain.info/block/000000000000000000cf3620d570d08d1799a1cafbbfae512fdba2124665eca0" rel="nofollow noreferrer">Block#496785</a> :</p>

<p>Difficulty("target") = 1,347,001,430,558.57
or in hex
000000000000000000000000000000000000000000000000000001399F8AB21E</p>

<p>Mined Hash = 000000000000000000cf3620d570d08d1799a1cafbbfae512fdba2124665eca0</p>

<p>so it seems to me the hash is now greater than the difficulty so an invalid block but this is obviously not the case.</p>

<p>I have heard also that the difficulty is related to the number of leading zeros after the maximum target in which case may make sense where 1399F8AB21E is a 11 byte number and the hash after the default 8 byte leading target contains 10 bytes which is less than the difficulty 11 bytes of zeros.</p>

<p>so</p>

<pre><code>00000000 0000000000 cf3620d570d08d1799a1cafbbfae512fdba2124665eca0
8 bytes  difficulty             some value
</code></pre>

<p>Is this correct? How does this work?</p>

<blockchain><block><validation>
Difficulty to Hash Validation Correlation
StoneAgeCoder
# Difficulty to Hash Validation Correlation

(Asked by: username_0 on 2017-11-30)

In the validation of a block it is said that a miner has a valid block if the transactions can be tracked in the chain and the hash of the block header is less than the difficulty. I am having a hard time seeing the relationship in real world blocks that are being solved.

For Example from [Block#496785](https://blockchain.info/block/000000000000000000cf3620d570d08d1799a1cafbbfae512fdba2124665eca0) :

Difficulty("target") = 1,347,001,430,558.57
or in hex
000000000000000000000000000000000000000000000000000001399F8AB21E

Mined Hash = 000000000000000000cf3620d570d08d1799a1cafbbfae512fdba2124665eca0

so it seems to me the hash is now greater than the difficulty so an invalid block but this is obviously not the case.

I have heard also that the difficulty is related to the number of leading zeros after the maximum target in which case may make sense where 1399F8AB21E is a 11 byte number and the hash after the default 8 byte leading target contains 10 bytes which is less than the difficulty 11 bytes of zeros.

so

```
00000000 0000000000 cf3620d570d08d1799a1cafbbfae512fdba2124665eca0
8 bytes  difficulty             some value

```

Is this correct? How does this work?

**Tags:** blockchain, block, validation


---

## 1 answers

### Answer by username_1 on 2017-11-30. Score: 1 | Accepted answer

*Difficulty* is not the same as *target hash* (target in short).

They are inversely related, so minimal possible difficulty (of 1) gives *maximal target*, by definition given as (<https://en.bitcoin.it/wiki/Target>):

> 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
>
> Because Bitcoin stores the target as a floating-point type, this is
> truncated:
>
> 0x00000000FFFF0000000000000000000000000000000000000000000000000000

The current difficulty is calculated as *maximal target* divided by the current target. For example (<https://en.bitcoin.it/wiki/Difficulty>):

> 0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
> 0x00000000000404CB000000000000000000000000000000000000000000000000
> = 16307.420938523983

So in your example the Difficulty = 1,347,001,430,558.57 would give the current target of:

> current\_target =
> 0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
> 1,347,001,430,558.57

If you calculate this (take care as one number is hexadecimal and other decimal), the comparison should give that this current\_target is higher than the mined hash of:

> 0x000000000000000000cf3620d570d08d1799a1cafbbfae512fdba2124665eca0

EDIT: Pen and paper calculation gives me that the current target is around:

> 0x000000000000000000FFFF000000000000000000000000000000000000000000

How I got this. 1,347,001,430,558.57 is around 1.225 \* (16^10). As the target is in base 16, this means that dividing by 1 \* (16^10) is like shifting the digits 10 places to the right. To get precise result after digits shifting I should divide by 1.225, but I ignored this in this pen and paper calculation.

EDIT2: To be even more precise I take 16/1.225 is around 13 (*D* in hex), so the target is around:

> 0x000000000000000000D000000000000000000000000000000000000000000000

> **Comments:**
> **username_2**: Why does `0x00000000FFFF0000000000000000000000000000000000000000000000000000` represent the truncated floating-point type version of `0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF`?  

---

