Data ordering for the Double SHA-256 function for Equihash

Hey everyone,

I’m developing a miner for the Equihash algorithm and I’m having some trouble finding out the ordering of the data I should send to the final double SHA-256 function. From what I read from here, I understand that I should send the Block Header (140 bytes) + SolutionSize (3 bytes) + Solution (1344 bytes), but I have no idea about the endianness of those fields or the order I’m supposed to send them.
Do you guys have some examples that I could check out against? I’ve been using this block header as example up until now but I’m stuck in this last function.

Thanks!

1 Like

Reading some other implementarions for this algorithm might clarify you,

139 repository results
Search · Equihash · GitHub

Thank you, I’ll take a look!

Can you give any details on your miner? I’d be interested to hear any info you’d like to share. I personally found this one to be very good to study:

It’s a pretty standard Equihash(200,9) solver. I generate the Blake hashes using the block header I’ve linked, then distribute them into buckets and look for collisions on the first 20 bits in each bucket, repeat until the last round, where I look for collisions on the remaining 40it.
I’ve got the right solution, but a bunch of other solutions too, so I need to look into why I’m getting more than one when this block header is supposed to give out only one.
There’s a caveat though, I’m planning to deploy this code to an FPGA to see what can I get.
Thanks for the link, I’ll be looking into it. Feel free to ask more questions if you wish :smiley:

Just a question, in the solutions here, the value of Soln: 0x0 (for example) is the BlockHeader we should send to the Equihash function, right? And each header can have more than one solution, correct?

I think those are the hex representation of the 512 solutions (in this case “solution” is the 512 blake2 hashes that xor to 0), these are added to the block header and hashed with sha256, and if the difficult is matched, it’s a solution for the block. Some one please correct if that’s wrong!

Yep, you’re right. Before adding them to the BlockHeader to be hashes, you’ll need to encode them from 32 bits to 21. I tested my implementation with some of those headers and got good results, however it generates way too many duplicated solutions, I’m looking into that now.