3

Lets say I want to find out what getwork would have returned for an already mined block http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d. How would I go about doing this?

  • 1
    Are you asking what the getwork that created that block looked like? Is this to create test data for a Bitcoin miner? – Nick ODell Jun 4 '13 at 5:02
  • Yes. Thats right – Enthusiast Jun 4 '13 at 5:59
5

Since we have quite a few questions about mining I took the liberty of creating a tool that demonstrates how to get from the getwork to the actual hashes and testing them against the target.

Your question is simply the reverse direction of mining, so let's get started.

All parameters are taken from the actual block. This is a version 1 block so we start with the 01000000 (1 little endian). This is followed with the 32 byte prev_hash, again in little endian:

00000000000008a3a41b85b8b29ad444def299fee21793cd8b9e567eab02cd81

becomes

81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000

same goes for the merkle root:

2b12fcf1b09288fcaff797d71e950e71ae42b91e8bdb2304758dfcffc2b620e3

becomes

e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b

Next comes the timestamp. 1305998791 (4dd7f5c7 in big endian) is c7f5d74d in little endian. Then the bits (encoded difficulty) 440711666 is 1a44b9f2 in big endian and f2b9441a in little endian. And finally the nonce. Since you are asking for the getwork this is the part that your miner will have to find, hence we just mark it out with 0 (00000000).

Putting it all together we have a data field of the getwork request that is

0100000081cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122bc7f5d74df2b9441a00000000

Then getwork does a strange thing: it chunks the header up into groups of 4 byte and switches the endianness. So that this string becomes

00000001ab02cd818b9e567ee21793cddef299feb29ad444a41b85b8000008a300000000c2b620e3758dfcff8bdb2304ae42b91e1e950e71aff797d7b09288fc2b12fcf14dd7f5c71a44b9f200000000

This is exactly 80 bytes in length and corresponds to the data field (without padding). The getwork however includes some padding to become two SHA-256 blocks of length 64 bytes.

The padding is discarded by the miner, but for completeness:

000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000

Next in the getwork we have the midstate. This is simply first 64 bytes of the header with a partially applied first round of hashing, hence we can recover it from the block header (or data):

93c524951367c505ba69e616a010282d376ee807daa9562f69ce5bcd2dda787a

The getwork also includes an additional field that keeps some internal state from the SHA-256 algorithm, the hash1 field:

 00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000

It is always constant, and is pretty useless.

The final field in our reconstruction of the getwork request is the target. This is the one field we cannot actually reconstruct as it depends on the pool setting that provided the work. It is likely to be difficulty 1, hence the field itself is:

00000000FFFF0000000000000000000000000000000000000000000000000000

which is a long, below which the found hash has to be. Due to this being Bitcoin it is again little endian and becomes

0000000000000000000000000000000000000000000000000000ffff00000000

The entire reconstructed getwork should look something like this

{
  "midstate" : "bfc1dbf82dd6335830eb42a5258fb7ceb4c566ed2ae7ec4ed1d23bd9dbbff68f",
  "data" : "00000001ab02cd818b9e567ee21793cddef299feb29ad444a41b85b8000008a300000000c2b620e3758dfcff8bdb2304ae42b91e1e950e71aff797d7b09288fc2b12fcf14dd7f5c71a44b9f200000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
  "hash1" : "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
  "target" : "0000000000000000000000000000000000000000000000000000ffff00000000"
}

To see how a miner finds a block from these parameters just enter them in the manual miner I created. Notice that if we fill in the nonce that is in the block (2504433986 or 9546a142 in its hex representation), we indeed get a block of the required difficulty.

Edit: Frank Buss contacted me for a correction: the midstate I posted above was wrong.

  • 1
    The midstate is still wrong. From the "reconstructed getwork" data field, the following midstate can be calculated: 93c524951367c505ba69e616a010282d376ee807daa9562f69ce5bcd2dda787a, e.g. with this script: pastebin.com/sZrMZ0EK – Frank Buss Jan 24 '14 at 21:22
  • Thanks, I corrected it and removed it from the manual miner as it was unused anyway. – cdecker Jan 25 '14 at 11:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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