Is the data sent by getwork big endian or little endian?

[ahtremblay]

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:

Code:

./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?

[kjj]

It isn't really the length of the message.  It is the salt for the padding.  That just happens to be the size of the message.  See FIPS180-2, section 5.1.1.

The spec calls for a 64 bit value of the length of the message in "a binary representation".  Intel's crazy-endian is what we ended up with here.

[ahtremblay]

It isn't really the length of the message.  It is the salt for the padding.  That just happens to be the size of the message.  See FIPS180-2, section 5.1.1.

The spec calls for a 64 bit value of the length of the message in "a binary representation".  Intel's crazy-endian is what we ended up with here.

So do I use the data field as-is, or do I convert it to big endian first?