Satoshi on November 24, 2010 said:
getwork does the byte-reversing. midstate, data and hash1 are already big-endian, and you pass data back still big-endian, so you work in big-endian and don't have to do any byte-reversing. They're the same data that is passed to the ScanHash_ functions. You can take midstate, data and hash1, put them in 16-byte aligned buffers and pass them to a ScanHash_ function, like ScanHash(pmidstate, pdata + 64, phash1, nHashesDone). If a nonce is found, patch it into data and call getwork.
My bitcoind client returns this when I call getwork:
./bitcoind getwork
{
"midstate" : "923e3f981b6a8c0c9bef7e6779f6b27cf8eaf2865ac6baf853eca0d75d48248e",
"data" : "00000001fe030434c35a05ac7066dfcf03c774c0c818ebd04f9c0cc700000ed400000000d5d67bdee77028ba4d12b7639063ab1c4f135d60e1a8c5b971eeef444ba848644dee50581a1d932f00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
"hash1" : "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
"target" : "00000000000000000000000000000000000000000000002f931d000000000000"
}
The last word of the data field is 80020000. This field indicates the length of the message. However, the length is only correct if we convert 8002000 to big endian. 0x80020000, in big endian, is 0x280. Which in decimal is 640... the length of the message.
So it would appear that data is not big endian.
The same is true with hash1.
I am trying to build a client to understand getwork. Is the data, hash1 and midstate big endian or little endian?
