Zcash mining proof of concept in FPGA

I am trying to build some proof of concept in FPGA for zcash mining.

I have gone through following discussions and understood the algorithm flow upto some extent.

My current confusion is regarding the blake2b input

block header:
040000007003225F30E1015EE14609B222E6036B7572963E18355688A966BB0E00000000E53B8DC142BBF69584F26B5F1D2125B79F238E77D04A37CDFAE64D3CFE9B2E730000000000000000000000000000000000000000000000000000000000000000C85BDA595DB6121C4FFFFFFF05000000000000000000000000000000000000000000000000000000 + 4 byte Index
If I consider the above block header of 140 byte, then I have some question regarding how I can feed the block header to blake2b input

Blake2b-512 can accept 128byte of message block. So, I need to break 140 byte + 4 byte index = 144byte header to 2 message blocks. Then calculate the hash of first 128byte block data and then calculate the final hash by considering the hash of 1st block and remaining message block.

So, In my view the fist message block should be 22E6036B7572963E18355688A966BB0E00000000E53B8DC142BBF69584F26B5F1D2125B79F238E77D04A37CDFAE64D3CFE9B2E730000000000000000000000000000000000000000000000000000000000000000C85BDA595DB6121C4FFFFFFF050000000000000000000000000000000000000000000000 + 00000000 (index, will increment 10000000, 20000000, 30000000 …)
and 2nd message block should be remaining 16 bytes of header and appended with zero in the left side {(112 byte appended zero) || 040000007003225F30E1015EE14609B2 (16 byte).}

Also, as per wiki

Function Compress
we need to feed input t
t: Number, 0…2128 Count of bytes that have been fed into the Compression
for first block it must be 128byte and for 2nd block whether it must be 144 byte of 256byte (as we are padding 112bytes with zero) ?

Please confirm whether the block1 & block2 data arrangement to blake2b input is correct or any rearrangement should be done.

1 Like


Any thought on above query ?

HP Bhat