user61188: 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 :
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?

user62184: 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


61188: <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>
 62184: <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>
