Why do we inverse the hash of the blockheader?

Question

Let's pick this example blockheader-hashing in Python:

from hashlib import sha256
import hashlib
header = "0000002066720b99e07d284bd4fe67ff8c49a5db1dd8514fcdab610000000000000000007829844f4c3a41a537b3131ca992643eaa9d093b2383e4cdc060ad7dc548118751eb505ac1910018de19b302".decode('hex')
print sha256(sha256(header).digest()).digest()[::-1].encode('hex')
// result is 00000000000000000020cf2bdc6563fb25c424af588d5fb7223461e72715e4a9

I know that it's part of the protocol and otherwise, a block will not be accepted, but:

1. Why do we not accept a hash that ends with all those zeros? Is it because it's easier for a program to calculate if hash < expected_hash?
2. But in this case, I don't understand why do we do not simply accept a hash sha256(sha256(header).digest()).digest().encode('hex') that is lower than the expected hash? The probability to get that should be as high as the inversed one.

So what's the reason of inversing it?

Answer 1

1. Why do we not accept a hash that ends with all those zeros? Is it because it's easier for a program to calculate if hash < expected_hash?

Counting the number of leading or trailing zeroes does not give a lot of granularity. If represented as a hex number, then there are only 64 possible target values if you are counting just the number of zeroes. If in binary, that is 256 possible values. Furthermore, counting the number of zeroes means that you can only change the difficulty by some power of 2 (in binary, the difficulty has to be doubled or halved). There are thus not many values for the target and this loss of granularity is bad.

Conversely, comparing the value means that there are (in theory) 2^256 possible values for the difficulty. This is much more granular, and these values are integers. Instead of having to change the difficulty by multiplying, the difficulty can be changed with addition and subtraction. By having more values, the difficulty will be less likely to be too hard or too easy.

2. But in this case, I don't understand why do we do not simply accept a hash sha256(sha256(header).digest()).digest().encode('hex') that is lower than the expected hash? The probability to get that should be as high as the inversed one.

It is actually just like you said. The reversing of the hash is only for how the bytes are actually represented. They are stored as bytes and interpreted as a little endian 256 bit integer. The comparison is still an integer comparison and the data representation is irrelevant (they could just as easily be stored and represented as big endian integers). But when they are displayed, they are displayed as big endian values in hexadecimal because humans are accustomed to big endian. The reason for little endian is likely because the x86 architecture uses little endian for storing integers.