Quote from: gorkem2020 on September 08, 2018, 02:56:00 PM

1-) I'm looking at block 540494, its nonce is 2097181953 its hash is 00000000000000000024ada2........

so it starts with 18 leading zeros..

that means a miner starts from 0 calculates its hash with the nonce=0 IF no valid result, THEN increments nonce by 1. now nonce=1, and keep doing this until a hash is found with 18 leading zeros. Because current difficulty requires them to find a hash with 18 leading zeros, right?

Yes, and no. Yes, a miner started from 0 and incremented the nonce until they found a hash that met the proof of work requirements. No, the difficulty does not require them to find a hash with 18 leading zeroes.

The leading zeroes thing is just a simplification of how the proof of work check actually works. What actually happens is that there is some target value that is a 256 bit integer. Block hashes are interpreted as a 256 bit integer. So all that happens is that the block hash (interpreted as a 256 bit integer) is compared to the target value. The block hash must then be less than or equal to the target value. Because the target value is "small" (small in terms of the 256 bit number space), it will have many leading zeroes. But the zeroes themselves do not actually matter, all that matters is the value.

Quote from: gorkem2020 on September 08, 2018, 02:56:00 PM

Sub-question: I know difficulty changes every 2 weeks, it is now 7,019,199,231,177 but who decides how many leading zeros should be in the valid hash? is it something to do with "target difficulty" rather than the "difficulty number" itself? Are these 2 different difficulty parameters that define the difficulty?

There is only one parameter that matters: the target value. The difficulty is just the inverse of the target divided by the maximum target value.

The difficulty readjustment is really a target readjustment. The target changes every 2016 blocks, which is approximately two weeks. It does not actually change every two weeks since it may take shorter or longer than 2 weeks to find 2016 blocks. The target is just scaled proportionally to the amount of time it took to mine 2016 blocks and the amount of time it should take to mine 2016 blocks (2 weeks). Of course there must have been a starting point for the target, and that is the maximum target value (so difficulty is the lowest) which is defined in the consensus rules. The maximum target value was used in the genesis block so that is the starting point for target adjustment.

Quote from: gorkem2020 on September 08, 2018, 02:56:00 PM

So for this particular example (block 540494) the nonce is 2097181953

that means a miner tried every single nonce from 0 to 2,097,181,953, and calculated hash 2,097,181,953 (lets say 2 billions) times in total and found the valid result which is the hash starting with 18 zeros. (00000000000000000024ada2........)

Now what I dont understand is that an ASIC machine can hash 12 trillion times PER SECOND. and our nonce is 2,097,181,953. so that means winning miner spent only fraction of a second to calculate 2 billions hashes. But it cant be true because block time is 10 minutes, right? so what is wrong here?? What am I doing wrong with this calculation?

My understanding is like the following;

* Miner have a list of transactions and all the properties (headers I believe) to calculate the hash of the block.

* Miner calculates hashes for all the nonces between 0 and the current difficulty (it is now 7,019,199,231,177)

* IF miner finds a hash with at least 18 leading zeros (can be more than 18 zeros, right? since even if it has 20 leading zeros, it is still proof of the work.) that miner gets the reward.

* IF miner cant find a nonce between 0 - 7,019,199,231,177 then miner picks different set of transactions (since calculations with the current list of transactions wont be resulting valid hash.. So miner adds couple more transactions into the block and starts the whole process all over again with the new list of transactions.. hoping to find a valid hash with the nonce between 0 and 7,019,199,231,177 and with the new set of transactions.

That is close. Miners don't usually re-select transactions after every set of nonces is exhausted. Usually they will change something within the block they already have. Specifically, they will set some value in their coinbase transaction that is known as the extra nonce. This extra nonce is then incremented every time the nonce runs out so that the merkle root is different and thus the nonces can be tried again. Furthermore, miners may change things like the block timestamp and block version number in order to get different candidate blocks.

Quote from: gorkem2020 on September 08, 2018, 02:56:00 PM

* Miner have a list of transactions and all the properties (headers I believe) to calculate the hash of the block.

Transactions are just transactions. There are no transaction headers. The block contains the transactions themselves and then the hash of all of the transactions is included in the merkle root which is in the block header.

Quote from: gorkem2020 on September 08, 2018, 02:56:00 PM

* Miner calculates hashes for all the nonces between 0 and the current difficulty (it is now 7,019,199,231,177)

No, the nonce is a 32 bit integer. It can only have the 32 bit integer values. It does not change with the difficulty.

Quote from: gorkem2020 on September 08, 2018, 02:56:00 PM

* IF miner finds a hash with at least 18 leading zeros (can be more than 18 zeros, right? since even if it has 20 leading zeros, it is still proof of the work.) that miner gets the reward.

A block hash is valid so long as it is less than or equal to the current target. So one with more leading zeroes is inherently less than, thus it will still be accepted.