5

I recently tried playing around with the getwork command for JSON-RPC and I'm trying to understand what I got out of it. According to the API Call List wiki entry, the "data" field should contain the block data to be hashed.

The data field I got was:

00000001a10bacc7e639d1c69a01014bc5db6f2604b3477a3f273a4e019a232700000000a5942372cc60477c8a276e59c8f1a3f58654ea2f6c4402bf1b18e48455b5b8f64f10868b1c07475200000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000

Which after being dissected a bit according to the protocol would yield:

00000001 - version
a10bacc7e639d1c69a01014bc5db6f2604b3477a3f273a4e019a232700000000 - prev_block
a5942372cc60477c8a276e59c8f1a3f58654ea2f6c4402bf1b18e48455b5b8f6 - merkle_root
4f10868b - timestamp
1c074752 - bits
00000000 - nonce
00 - txn_count of 0?
0000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000 - ??

Is there something wrong with the data I'm getting? Would the client respond differently if I run it with the -gen option?

1 Answer 1

4

The number of transactions in the header is always zero, per the specification. The -gen option has no effect on the getwork RPC call.

I'm not sure what you think is wrong with that information, but if it's just the zero transaction count, that's always that way. If it's the fact that you only get the headers you need to hash, it's always that way. Of course the nonce is 0 because the client has no idea what the nonce should be. (That's the point of mining.)

1
  • 2
    I thought it was wrong, because the wiki on API calls referred to "data" field as "block data", whereas more correctly it would be "block header data".
    – ThePiachu
    Jan 13, 2012 at 22:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.