Hi all , I am currently try to understand how decred hash function working. I have implemented blake256 function ,and passed the tests something like below: input: The quick brown fox jumps over the lazy dog output: 7576698ee9cad30173080678e5965916adbb11cb5245d386bf1ffda1cb26c9d7 and other testcase I found in dcrd blake256_test.go After test done , I got some logs from sgminer for share data. The input is 040000003f61a3f8799d9b4a2deb9b515a139e58dfe73fba11b2543fea000000000000003fa237ca535c35524bd906c78b5c628907113e6590094051ab860eafac4e9597e1948be503fdcede54b05273e6d68e7d992a2485d717c4818362478a3628804f0100bf1c9a43a62a05000a00e4a10000e786011aab460b6c01000000c0540200153100007d2b7259cc504d627800588a1301000000000000000000000000000000000000000000000000000004000000 and sgminer output the data hash is fc8c0641edecb95b56f52988bc8d468487935a4cd4035f53a4bc1f0a00000000 but I try to use this input with my blake function , I got the different hash which is d607a97660fa10d828d6c72065922315e377e21dedd583b04d782cd26a2e2fc8 did I do it wrong ? please help me , thx so much!
The hash output you are seeing is correct for that input. Cryptocurrencies almost always show their hashes "reversed", so if you were to compare it with what you would see coming out of the software for that same data, on block explorers, etc, you would notice they say "c82f2e6ad22c784db083d5ed1de277e31523926520c7d628d810fa6076a907d6" which is the same thing you have backwards. The reason the hash is different is because the miner is searching for a solution and thus it changes the nonce (and potentially extra nonce), and thus the hash printed is of that altered data as opposed to the shown input.
HI davecgh, thanks for you reply. I got the point from the first part. But from the second part, I am still a little bit confused. for this input data: 040000003f61a3f8799d9b4a2deb9b515a139e58dfe73fba11b2543fea000000000000003fa237ca535c35524bd906c78b5c628907113e6590094051ab860eafac4e9597e1948be503fdcede54b05273e6d68e7d992a2485d717c4818362478a3628804f0100bf1c9a43a62a05000a00e4a10000e786011aab460b6c01000000c0540200153100007d2b7259 cc504d62 7800588a13 010000 00000000000000000000000000000000000000000000000004000000 --------------------------- cc504d62 is the nonce selected by the miner 7800588a13 is the extranonce1 set from the pool 010000 is the value selected by the miner based on extranonce2_size,which is 3 I think this input should be the final data used by miner to generate the hash "blake256(data)" I posted before "fc8c0641edecb95b56f52988bc8d468487935a4cd4035f53a4bc1f0a00000000". but actually I failed to get this hash base on the data. so I wonder why this is not working , or am I missing some other data? Thanks again for your help.
The hash of the input data does not correspond to "fc8c0641edecb95b56f52988bc8d468487935a4cd4035f53a4bc1f0a00000000". That tells me that the submitted share is not the same as the posted input data. My comment was a guess based on that. I'd be willing to bet if you continuously increment that nonce you'll eventually find one that will cause the data to hash to "fc8c0641edecb95b56f52988bc8d468487935a4cd4035f53a4bc1f0a00000000" and that is the share that was submitted.
Hi davecgh, I found the problems the issue is the nonce endianess. If I change the nonce cc504d62 into 624d50cc, I got the hash. sgminer logs make me misunderstanding it was the final share data , no need to change. I will make a issue if the author can change the endianess. Thanks again, have a nice day!