Request to verify calculations for blake2b please

Hello,

I have been reading over this thread:

and have been working on my own implementation of a miner.

I have come to the point of actually calculating the hashes for the compiled units of work received from the stratum server. I have tested my calculation engine against the “classic” rfc7693 calculation and result for “abc.” Everything checks out. I have also compiled and done a few checks against this implementation:

Things check out there as well, until I get to calculating the full hash on the 144-byte work (represented by the 288-byte string). At that point things seem to diverge, and I was wondering whether someone would be willing to check my results.

As a start, I need to ask one question. Am I correct in understanding that what I am processing will be the 144 bytes once the string is converted from hex to a byte array (i.e. the string “04000000” would be the bytes 0x04, 0x00, 0x00, 0x00)? Or am I supposed to process the string directly converted to bytes, in which case the previous example would become 0x30, 0x34, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30? The second option wouldn’t seem likely to me as the specification calls for a 144 byte work segment, and that would produce a 288 byte segment. I just wanted to make sure, though.

Anyway, for this input:

040000007003225F30E1015EE14609B222E6036B7572963E18355688A966BB0E00000000E53B8DC142BBF69584F26B5F1D2125B79F238E77D04A37CDFAE64D3CFE9B2E730000000000000000000000000000000000000000000000000000000000000000C85BDA595DB6121C4FFFFFFF0500000000000000000000000000000000000000000000000000000000000000

I receive:

10a71c3968181c4feb7b615f2e11ca551b5d41abb2d09818a1b20d2a4e3760f9d13aed079ffe3b1bac2b69c09239b955b260

using the first method (converting to a 144-byte work chunk) or:

82b56b82381ec3efca8ce131e90320706a17f0587109e34fa84ee60d60bff3310f8125657ccdd750b1ffd3f8e9ff4397d943

parsing the string byte for byte.

Do either of these results look correct?

Thank you in advance.

yes, all binary manipulations are going on bytes, definitely not on “hex string read by bytes”.

sorry, not quite clear what are you doing here.

for Blake2B ZCash-style hash of that 144 bytes I get:

302b73bb4f258cf918ad9d9555321f5f7a9e88392a1a4b674e4c420c5ecba665b5c412edda230dc93a4fce4956bc8f8dce74

Thank you. That agrees with what is listed in the discussion that I quoted previously. Obviously there is an error in my algorithm that I will have to track down. Your verification helps me to confirm that.

You may find https://blake2.net/blake2.pdf paragraph 2.8 and zips/protocol.pdf at main · zcash/zips · GitHub paragraph 5.4.1.9 useful to get what “Zcash-style” means here for Blake2B, since RFC 7693 paragraph 2.5 does not specify these Zcash’ details.

Thank you. I will look into those.

If I read 2.3 of https://blake2.net/blake2.pdf, am I to understand that I should be using both f0 and f1 as end indicators?

Okay, so think I’ve answered my own question. I went digging around in the nheqminer source and it would appear that no, f1 is not needed. With the last flag, just xor 0xFFFFFFFFFFFFFFFF with v[14] and that is sufficient.