0

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?

0

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

  • Why does 0x00000000FFFF0000000000000000000000000000000000000000000000000000 represent the truncated floating-point type version of 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF? – Paul Berg Jun 24 '18 at 9:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.