<p>Since we have quite a few questions about mining I took the liberty of <a href="http://bitcoinstats.com/network/mining/manual" rel="nofollow">creating a tool</a> that demonstrates how to get from the <code>getwork</code> to the actual hashes and testing them against the target.</p>

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

<p>All parameters are taken from the <a href="https://blockchain.info/block-index/138942/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d" rel="nofollow">actual block</a>.
This is a version 1 block so we start with the <code>01000000</code> (1 little
endian). This is followed with the 32 byte prev_hash, again in little
endian:</p>

<pre><code>00000000000008a3a41b85b8b29ad444def299fee21793cd8b9e567eab02cd81
</code></pre>

<p>becomes</p>

<pre><code>81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000
</code></pre>

<p>same goes for the merkle root:</p>

<pre><code>2b12fcf1b09288fcaff797d71e950e71ae42b91e8bdb2304758dfcffc2b620e3
</code></pre>

<p>becomes</p>

<pre><code>e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b
</code></pre>

<p>Next comes the timestamp. <code>1305998791</code> (<code>4dd7f5c7</code> in big endian) is
<code>c7f5d74d</code> in little endian. Then the bits (encoded difficulty)
<code>440711666</code> is <code>1a44b9f2</code> in big endian and <code>f2b9441a</code> 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 (<code>00000000</code>).</p>

<p>Putting it all together we have a data field of the getwork request
that is </p>

<pre><code>0100000081cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122bc7f5d74df2b9441a00000000
</code></pre>

<p>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</p>

<pre><code>00000001ab02cd818b9e567ee21793cddef299feb29ad444a41b85b8000008a300000000c2b620e3758dfcff8bdb2304ae42b91e1e950e71aff797d7b09288fc2b12fcf14dd7f5c71a44b9f200000000
</code></pre>

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

<p>The padding is discarded by the miner, but for completeness:</p>

<pre><code>000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
</code></pre>

<p>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):</p>

<pre><code>93c524951367c505ba69e616a010282d376ee807daa9562f69ce5bcd2dda787a
</code></pre>

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

<pre><code> 00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000
</code></pre>

<p>It is always constant, and is pretty useless.</p>

<p>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:</p>

<pre><code>00000000FFFF0000000000000000000000000000000000000000000000000000
</code></pre>

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

<pre><code>0000000000000000000000000000000000000000000000000000ffff00000000
</code></pre>

<p>The entire reconstructed getwork should look something like this</p>

<pre><code>{
  "midstate" : "bfc1dbf82dd6335830eb42a5258fb7ceb4c566ed2ae7ec4ed1d23bd9dbbff68f",
  "data" : "00000001ab02cd818b9e567ee21793cddef299feb29ad444a41b85b8000008a300000000c2b620e3758dfcff8bdb2304ae42b91e1e950e71aff797d7b09288fc2b12fcf14dd7f5c71a44b9f200000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
  "hash1" : "00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
  "target" : "0000000000000000000000000000000000000000000000000000ffff00000000"
}
</code></pre>

<p>To see how a miner finds a block from these parameters just enter them in the <a href="http://bitcoinstats.com/network/mining/manual?data=00000001ab02cd818b9e567ee21793cddef299feb29ad444a41b85b8000008a300000000c2b620e3758dfcff8bdb2304ae42b91e1e950e71aff797d7b09288fc2b12fcf14dd7f5c71a44b9f200000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000&amp;target=0000000000000000000000000000000000000000000000000000FFFF00000000&amp;nonce=9546a142" rel="nofollow">manual miner</a> I created. Notice that if we fill in the nonce that is in the block (<code>2504433986</code> or <code>9546a142</code> in its hex representation), we indeed get a block of the required difficulty.</p>

<p><strong>Edit</strong>: Frank Buss contacted me for a correction: the midstate I posted above was wrong.</p>

CC BY-SA 3.0
2014-01-24T21:22:04.027Z
The midstate is still wrong. From the "reconstructed getwork" data field, the following midstate can be calculated: 93c524951367c505ba69e616a010282d376ee807daa9562f69ce5bcd2dda787a, e.g. with this script: http://pastebin.com/sZrMZ0EK
Frank Buss
CC BY-SA 3.0
2014-01-25T11:56:55.983Z
Thanks, I corrected it and removed it from the manual miner as it was unused anyway.
cdecker
CC BY-SA 3.0
2013-06-17T15:26:10.680Z
2014-01-25T11:56:02.433Z
2014-01-25T11:56:02.433Z
cdecker
<p>Lets say I want to find out what getwork would have returned for an already mined block <a href="http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d" rel="nofollow">http://blockexplorer.com/block/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d</a>. How would I go about doing this?</p>

CC BY-SA 3.0
2013-06-04T05:02:41.767Z
Are you asking what the getwork that created that block looked like? Is this to create test data for a Bitcoin miner?
Nick ODell
CC BY-SA 3.0
2013-06-04T05:59:02.163Z
Yes. Thats right
Enthusiast
<blockchain>
How do I find out what getwork would have returned for an already mined block?
Enthusiast
# How do I find out what getwork would have returned for an already mined block?

(Asked by: username_0 on 2013-06-04)

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?

**Tags:** blockchain

> **Comments:**
> **username_1**: Are you asking what the getwork that created that block looked like? Is this to create test data for a Bitcoin miner?  
> **username_0**: Yes. Thats right  

---

## 1 answers

### Answer by username_2 on 2013-06-17. Score: 5

Since we have quite a few questions about mining I took the liberty of [creating a tool](http://bitcoinstats.com/network/mining/manual) 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](https://blockchain.info/block-index/138942/00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d).
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](http://bitcoinstats.com/network/mining/manual?data=00000001ab02cd818b9e567ee21793cddef299feb29ad444a41b85b8000008a300000000c2b620e3758dfcff8bdb2304ae42b91e1e950e71aff797d7b09288fc2b12fcf14dd7f5c71a44b9f200000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000&target=0000000000000000000000000000000000000000000000000000FFFF00000000&nonce=9546a142) 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**: username_3 username_3 contacted me for a correction: the midstate I posted above was wrong.

> **Comments:**
> **username_3**: The midstate is still wrong. From the "reconstructed getwork" data field, the following midstate can be calculated: 93c524951367c505ba69e616a010282d376ee807daa9562f69ce5bcd2dda787a, e.g. with this script: http://pastebin.com/sZrMZ0EK  
> **username_2**: Thanks, I corrected it and removed it from the manual miner as it was unused anyway.  

---

