A quick guide on `How the hash of Bitcoin block is calculated?`

[webtricks]

Few days ago, a member asked about this in Bitcoin Discussion here: Mining process - SHA256 - Probability. I thought it would be better if I create a new thread for the reply I posted for him so more people who don't know the process can read it.

So if you read various beginners' guide on Bitcoin and blockchain on internet then will you surely come across a topic on Proof of Work (PoW) algorithm. Almost of all of them describes PoW as a consensus algorithm where miners try to find a solution to a mathematical puzzle and the first one to get the solution mines the block! So this thread is all about what that 'Mathematical Puzzle' is because the solution of this mathematical puzzle is what known as the hash of the block.

Finding block hash is nothing but finding a value which is less than the target value. Target value is adjusted after every 2,016 blocks. Current target value (as on 22nd August) is:

0x000000000000000000109bac0000000000000000000000000000000000000000 (hexadecimal form)
or
1590739304116800001454600275103718494518067345886281728 (decimal/integer number)


Now in order to find the block hash, you as a miner need to find an integer value less than the above number. But this is not very simple because you need to include 6 values in your computation together known as Block Header:
> Version
> Hash of previous block
> Merkle Root
> Time of mining
> Bits (difficulty in compact form)
> Nonce (an incrementing number)

So the process of mining involves calculating double SHA-256 of these 6 values in such a way that result hexadecimal hash is less than the current target. The whole process is defined here: o_e_l_e_o's reply to this post. Now let's take an example of Block: 644,731 and try to verify the solution provided by the miner:



For block 644,731, we have:
Version = 20400000 (hexadecimal)
Hash of Previous Block = 000000000000000000083d157a8a2a589a74fc2f7b91245cb3a415c23d7cc79a
Merkle Root = 9453cfc708a1cc84f3f36c2bae68202b03ad2866bb02da511d7e603a4e9d1fd1
Time = 16:42:15 as per GMT
Bits = 386,964,396 (decimal)
Nonce = 2035916310 (decimal)



Converting everything in hexadecimal form (little-endian), we will have following value,

0x000040209ac77c3dc215a4b35c24917b2ffc749a582a8a7a153d08000000000000000000d11f9d4e3a607e1d51da02bb6628ad032b2068ae2b6cf3f384cca108c7cf539467f93f5fac9b1017169e5979

(text is colored to differentiate six parameters)



The final step involves performing SHA-256 hashing twice on the above value and the result will be:
811802676f41d6aff67ad767517c466c4c8d3b87c81009000000000000000000



Converting it in big-endian, we have:
0000000000000000000910c8873b8d4c6c467c5167d77af6afd6416f67021881 which will become block hash of the block.



Now you can compare,
Target Value = 0x000000000000000000109bac0000000000000000000000000000000000000000 or 1590739304116800001454600275103718494518067345886281728

Block Hash (644,731) = 0000000000000000000910c8873b8d4c6c467c5167d77af6afd6416f67021881 or 868308124812842907393685749016650546999869456114653313



Since 868308124812842907393685749016650546999869456114653313 is smaller than 1590739304116800001454600275103718494518067345886281728, it is accepted as a correct solution and will become the block hash.

[o_e_l_e_o]

Although you've given an example of a hashing the correct numbers to find the correct solution, you haven't really explained how miners end up finding those correct numbers.

The version, previous block hash, and bits, are essentially fixed numbers and cannot be changed by the miner.

The Merkle root is dependent on all the transactions in the block. If a miner was to change which transactions they are including (or even include the same transactions in a different order), then they would end up with a different (unpredictable) Merkle root.

The time does not have to be the current time, as you might expect. It can be any time between the median of the last 11 blocks, and 2 hours in to the future.

The nonce can be any 32 bit number.

The miner will hash the 6 numbers as you have described, and if the result does not meet the target, then they will increment the nonce by 1 and hash them again. They will repeat this process until they either solve the block, or they reach the limit of the nonce.

At this point, most miners will then increment the extraNonce field. This is part of the coinbase transaction of the block. By incrementing it, the Merkle root will change, allowing the nonce to be reset to 0 and the process to begin again.

[webtricks]

~snip~

Thanks for the input. I was double-minded on whether to include this information in the thread or not. But now I feel that thread would have made more sense if I included it. Nevertheless, I have included link to your reply at right place in the OP so the whole thread makes more sense now.

[odolvlobo]

...
Converting it in little-endian, we have:
0000000000000000000910c8873b8d4c6c467c5167d77af6afd6416f67021881 which will become block hash of the block.
...

Actually, you are converting it to big-endian.

"Big-endian" and "little-endian" describe the order of the digits (bytes to be more specific). Big-endian means that the high-order digits are followed by the low-order digits.

For example, we write one hundred twenty-three as 123, which is big-endian because the hundreds digit is first. That number written as little-endian is 321.

A hash is normally not considered big-endian or little-endian. But the algorithm is comparing it as a number, so it must be assumed to be stored one way or the other, and little-endian was chosen (presumably because the code was originally written for a little-endian CPU).

[webtricks]

...
Converting it in little-endian, we have:
0000000000000000000910c8873b8d4c6c467c5167d77af6afd6416f67021881 which will become block hash of the block.
...

Actually, you are converting it to big-endian.

"Big-endian" and "little-endian" describe the order of the digits (bytes to be more specific). Big-endian means that the high-order digits are followed by the low-order digits.

For example, we write one hundred twenty-three as 123, which is big-endian because the hundreds digit is first. That number written as little-endian is 321.

Ah, you're right! It's just a typo. Thanks for pointing that out.

Since everything is converted into little-endian before hashing so the result generated will also be in little-endian. However, it needed to be converted into big-endian to solve our purpose i.e. finding hexadecimal value lower than the target.

[odolvlobo]

...
Converting it in little-endian, we have:
0000000000000000000910c8873b8d4c6c467c5167d77af6afd6416f67021881 which will become block hash of the block.
...

Actually, you are converting it to big-endian.
"Big-endian" and "little-endian" describe the order of the digits (bytes to be more specific). Big-endian means that the high-order digits are followed by the low-order digits.
For example, we write one hundred twenty-three as 123, which is big-endian because the hundreds digit is first. That number written as little-endian is 321.

...
Since everything is converted into little-endian before hashing so the result generated will also be in little-endian.
...

The result of a hash function is neither big or little endian. However, when using a hash as a number, you must pick one or the other. Satoshi decided that it would be little endian because that is the normal format for his CPU.

[nc50lc]

The version, previous block hash, and bits, are essentially fixed numbers and cannot be changed by the miner.

Actually, the version can be changed without generating an invalid block.
That's what miners with "Overt ASICBOOST" has been exploiting to get an extra nonce without the need to recompute for a new merkle root.