0

I am having trouble understanding something related to calculating difficulty. Target difficulty is described as 2^256 / difficulty .

The difficulty of the genesis block is notated as 0x0400 which is equal to 1024.

So if we take 2^256 (115792089237316195423570985008687907853269984665640564039457584007913129639936)

and divide by 1024 we get : 113078212145816597093331040047546785012958969400039613319782796882727665664

Then we have the block hash for the Ethereum genesis block: 0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3

If you convert this hexadecimal into decimal value it is: 96295644508963302359223866841007920022480890644992946816264522587871600414627

Immediately without a calculation you can tell that the value of the hash is greater than the value of the target difficulty. However the documents clearly state:

If the output of this algorithm is below the desired target, then the nonce is valid

So since we have an output value that is higher than the target, how is the hash on the genesis Ethereum block valid? Can someone please help me understand where I am going wrong here?

Poseidon
  • 99
  • 1
  • Where did you see 0x0400 exactly ? – hroussille May 04 '22 at 07:16
  • This is a value I keep seeing thrown around as the genesis block difficulty although finding an official source for it was impossible w the amount of bloat that comes up when I do a search for this topic. Its very possible this is an incorrect value, however if that's the case I would like to know how to verify the real value that was used to calculate the genesis block's target difficulty. – Poseidon May 04 '22 at 07:28
  • On etherscan https://etherscan.io/block/0 the genesis block difficulty is at 17,179,869,184 which is 0x400000000 in Hexadecimal. – hroussille May 04 '22 at 07:40
  • Ok. Just to follow my work again here: were going to take 2^256 and divide the result by 0x400000000 or 17,179,869,184 this results in: 6,739,986,666,787,659,948,666,753,771,754,907,668,409,286,105,635,143,120,275,902,562,304 compared to the int value of the hash: 96,295,644,508,963,302,359,223,866,841,007,920,022,480,890,644,992,946,816,264,522,587,871,600,414,627 the hash is still much larger. How can this hash: 0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3 be considered lower value than the target? – Poseidon May 04 '22 at 07:46
  • Ok so one possibility is that the number 0x400000000 aka 17,179,869,184 needs to have its reciprocal taken before calculating the difficulty. When accounting for this it looks correct, can someone verify if this is the case please? – Poseidon May 04 '22 at 08:08
  • You are comparing against the mix hash right ? it's different than the block hash. – hroussille May 04 '22 at 09:18
  • Even though it might be different for the genesis block, not sure about that :/ – hroussille May 04 '22 at 09:19
  • Where can I find the block hash then? I am wondering why it is not mentioned on the explorer as it seems like relevant data. – Poseidon May 04 '22 at 09:56
  • Anyone reading along, the reciprocal thing was a fake brute force solution, you do not need to take the reciprocal. – Poseidon May 04 '22 at 10:33
  • I don't think the mixHash is exposed on Etherscan, the check can be seen here https://github.com/ethereum/go-ethereum/blob/master/consensus/ethash/sealer.go#L167 and the actual computation is here : https://github.com/ethereum/go-ethereum/blob/8d84a701a5deee92853a50a0ff0ed1aa80aecc3a/consensus/ethash/algorithm.go#L338 – hroussille May 04 '22 at 10:55
  • The value that should be below the target is actually crypto.Keccak256(append(seed, digest...)) where seed is keccak512(blockHash, blockNonce) and digest is the mixHash. – hroussille May 04 '22 at 10:57
  • This answer has an explanation how difficulty is evaluated in an ethereum block https://ethereum.stackexchange.com/a/76900/ (it is not directly related to the block hash). – Ismael May 28 '22 at 21:59

0 Answers0