Bitcoin Forum
December 03, 2016, 09:44:24 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Is the data sent by getwork big endian or little endian?  (Read 1370 times)
ahtremblay
Jr. Member
*
Offline Offline

Activity: 50


View Profile
June 07, 2011, 09:04:29 PM
 #1

Satoshi on November 24, 2010 said:
Quote
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?
1480758264
Hero Member
*
Offline Offline

Posts: 1480758264

View Profile Personal Message (Offline)

Ignore
1480758264
Reply with quote  #2

1480758264
Report to moderator
1480758264
Hero Member
*
Offline Offline

Posts: 1480758264

View Profile Personal Message (Offline)

Ignore
1480758264
Reply with quote  #2

1480758264
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480758264
Hero Member
*
Offline Offline

Posts: 1480758264

View Profile Personal Message (Offline)

Ignore
1480758264
Reply with quote  #2

1480758264
Report to moderator
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
June 08, 2011, 12:35:34 AM
 #2

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.


p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
ahtremblay
Jr. Member
*
Offline Offline

Activity: 50


View Profile
June 08, 2011, 12:38:41 AM
 #3

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?
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!