-1

For any bitcoin block we combine various Header fields to create a string which is an input to a 2 pass SHA algorithm. The resultant hash must match with the Hash in the Block header for the Block to be valid.

To test this logic as well as SHA algorithm, I used the header of Block number 695877 (https://blockchain.info/rawblock/695877?format=json) to create the Input string 04008020546c359986812644420e453113e209afeaaeeb316f3a07000000000000000000b8fa13b3fca087c1456daac626ab9b8a47eae821a326f17e0ffffc15433df709b0f718610b1812175a5c9544.

Now when I apply the 2 pass SHA algorithm the resultant hash matches the hash in the Block (ignoring the Endian part for the time being).

Calculated Hash: 629ef98d63e12f6b01476419a5a71efa8814dea40aec09000000000000000000

Block hash: 00000000000000000009ec0aa4de1488fa1ea7a5196447016b2fe1638df99e62

But when I pad the header manually before passing it to 2 pass SHA algorithm as follows: 04008020546c359986812644420e453113e209afeaaeeb316f3a07000000000000000000b8fa13b3fca087c1456daac626ab9b8a47eae821a326f17e0ffffc15433df709b0f718610b1812175a5c9544800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000280 This is resulting in an incorrect hash.

I am failing to see what is wrong in the padding. Can someone please point it out?

J.Doe
  • 151
  • 6
  • I didn't get you question. We pad the message so that the (message length in number of Bits)%512=0 as we process 512 bits chunks. – J.Doe Aug 17 '21 at 13:09
  • 2
    You confirmed that the original input string produce the correct hash. Then you added 800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000280 to the input string, altering it. This will change the hash of the string. That's what hashing is supposed to do. So why do you want to pad, when the unpadded message produce the intended output? – A. Hersean Aug 17 '21 at 13:24
  • 1
    Restating the above comment differently: a hash's padding is part of hashing, and is not to be done externally. – fgrieu Aug 17 '21 at 15:06
  • I am trying to implement SHA myself from scratch (just to see if I understand correctly). There is a follow up query: If I use the above header (without pad) and give it to an algo for 2 passes it gives correct output if the data is specified as 'HEX' but fails for 'TEXT'. What kind of preprocessing is done to convert the 'HEX' data to 'TEXT' before we run the SHA algorithm? Most of the SHA pseudo code I see assumes data is as it is i.e. 'TEXT' format. I would be great if you could explain using current header above? This is the tool [https://emn178.github.io/online-tools/sha256.html] – J.Doe Aug 17 '21 at 17:24
  • I suggest you close this question since the original problem is solved; and that before asking a new question on SHA-256 padding you first read answers to other questions on SHA-256 padding, perhaps starting with this and that. Also, read the nice FIPS 180-4 which contains everything necessary. – fgrieu Aug 17 '21 at 18:55

1 Answers1

-3

Make sure that the size of the encryption in the block is the same as the size you are comparing. Such problems can occur when the block sizes are inconsistent.

alierguc
  • 1
  • 1
    There is no encryption involved: hashing is not encryption. Plus the problem is an extra level of padding, rather than a size issue. – fgrieu Aug 17 '21 at 15:08