<p>I don't have enough reputation to comment, but just to let you know, the example block header ends with "f8f1753dbdf441b00000000", but it should really be "b8f1753dbdf441b00000000" or fully:</p>

<blockquote>
  <p>020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229b8f1753dbdf441b00000000</p>
</blockquote>

<p>Caught this writing a unit test.</p>

CC BY-SA 3.0
2014-10-09T09:31:51.423Z
Wow, thanks! I think I copied the hash with the final time instead of the starting time by mistake. Do you know if the resulting hash is correct with the correct block header? Otherwise I'll have to rehash it and update my answer. But thanks a lot of letting me know!
MatthiasB
CC BY-SA 3.0
2014-10-10T03:46:53.167Z
The resulting hash is indeed correct with the block header I wrote up above. Just changing this should set everything straight.
Andrew Adams
CC BY-SA 3.0
2014-10-09T08:55:01.370Z
2014-10-09T08:55:01.370Z
Andrew Adams
<p>All else seems OK , but I think there is some issue with the SHA256x2 - e.g. :</p>

<p>according to your example the sha256x2 of :<br>
<code>020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229f8f1753dbdf441b00000000
</code></p>

<p>Should return:</p>

<p><code>f6f13e350aa4f251e192ab8a78690ee99f1cc2d930d4ae16c4172a0a8aefddd0</code></p>

<p>BUT IT ACTUALLY RETURNS :</p>

<p><code>077a4c8f19b52972747fb29a329064965d1c1176a1cd88f1f091e4aabb6fe3fa</code></p>

<p>Am I missing something ? </p>

<p>To verify - go to : <a href="http://www.compileonline.com/execute_python_online.php" rel="nofollow">http://www.compileonline.com/execute_python_online.php</a></p>

<p>and execute :</p>

<pre><code>#!/usr/local/bin/python2.7
import hashlib  
header_hex = "020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229f8f1753dbdf441b00000000"
header_bin = header_hex.decode('hex')
hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()

print hash.encode('hex_codec') 
</code></pre>

<p>`</p>

CC BY-SA 3.0
2014-03-08T16:15:10.753Z
Please note that this example is based on scrypt, not an dsha256. While the calculation of the block header is the same, the final hash is calculated differently.
MatthiasB
CC BY-SA 3.0
2014-03-08T21:07:04.800Z
I'm not sure what you mean by script in this context :) in brief - everything in your example is correct , workflow etc. and it is far far better then the one in the slash's description which lacks of about 5-6 principal mistakes.
user2627206
CC BY-SA 3.0
2014-03-08T22:12:45.693Z
scrypt, not script. Its the proof of work from Dogecoin, Litecoin and others while dsha256 is used by Bitcoin. There is a difference. The bitcoin algorithm (dsha256) uses some padding of the block_header and midstate and such, which I am not aware of, so unfortunately I think it is not fully compatible with my scrypt description.
MatthiasB
CC BY-SA 3.0
2014-03-08T15:39:45.360Z
2014-03-09T07:57:16.597Z
2014-03-09T07:57:16.597Z
user2627206
<p>Alright, I finally managed to fix my bugs and get a full roundtrip. Here is an example for a full communication with a Pool.
I don't explain everything in detail as the API description can be found elsewhere.</p>
<p>a) Suscription</p>
<pre><code>{&quot;id&quot;: 1, &quot;method&quot;: &quot;mining.subscribe&quot;, &quot;params&quot;: []}
{&quot;error&quot;: null, &quot;id&quot;: 1, &quot;result&quot;: [[&quot;mining.notify&quot;, &quot;ae6812eb4cd7735a302a8a9dd95cf71f&quot;], &quot;f8002c90&quot;, 4]}
</code></pre>
<p>We suscribe with the server. This has no parameters.
As result, we receive some Suscription ID, and our Extranonce1 + extranonce2 size, which we need for later.
b) authorization</p>
<pre><code>{&quot;params&quot;: [&quot;User&quot;, &quot;password&quot;], &quot;id&quot;: 2, &quot;method&quot;: &quot;mining.authorize&quot;}
{&quot;error&quot;: null, &quot;id&quot;: 2, &quot;result&quot;: true}
</code></pre>
<p>Authorize worker with Username + password. No parameters to store from the result.
c) Server -&gt; difficulty</p>
<pre><code>{&quot;params&quot;: [32], &quot;id&quot;: null, &quot;method&quot;: &quot;mining.set_difficulty&quot;}
</code></pre>
<p>Sets the difficulty to 32, defining our target. The resulting difficulty can be calculated as</p>
<pre><code>0x0000FFFF00000000000000000000000000000000000000000000000000000000 / 32 =
0x000007fff8000000000000000000000000000000000000000000000000000000
</code></pre>
<p>Now, the fun part:
d) Block info</p>
<pre><code>{&quot;params&quot;: [&quot;b3ba&quot;, &quot;7dcf1304b04e79024066cd9481aa464e2fe17966e19edf6f33970e1fe0b60277&quot;, &quot;01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff270362f401062f503253482f049b8f175308&quot;, &quot;0d2f7374726174756d506f6f6c2f000000000100868591052100001976a91431482118f1d7504daf1c001cbfaf91ad580d176d88ac00000000&quot;, [&quot;57351e8569cb9d036187a79fd1844fd930c1309efcd16c46af9bb9713b6ee734&quot;, &quot;936ab9c33420f187acae660fcdb07ffdffa081273674f0f41e6ecc1347451d23&quot;], &quot;00000002&quot;, &quot;1b44dfdb&quot;, &quot;53178f9b&quot;, true], &quot;id&quot;: null, &quot;method&quot;: &quot;mining.notify&quot;}
</code></pre>
<p>I split the parameters and assign them to variables</p>
<pre><code>job_id = &quot;b3ba&quot;
prevhash = &quot;7dcf1304b04e79024066cd9481aa464e2fe17966e19edf6f33970e1fe0b60277&quot;
coinb1 = &quot;01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff270362f401062f503253482f049b8f175308&quot;
coinb2 = &quot;0d2f7374726174756d506f6f6c2f000000000100868591052100001976a91431482118f1d7504daf1c001cbfaf91ad580d176d88ac00000000&quot;
Merklebranches = [ 
    &quot;57351e8569cb9d036187a79fd1844fd930c1309efcd16c46af9bb9713b6ee734&quot;, 
    &quot;936ab9c33420f187acae660fcdb07ffdffa081273674f0f41e6ecc1347451d23&quot;
    ]
version = &quot;00000002&quot;
nbits = &quot;1b44dfdb&quot;
ntime = &quot;53178f9b&quot;
clean_jobs = true// Not required for block, just for completeness
</code></pre>
<p>What we also need is extranonce1 and extranonce 2:</p>
<pre><code>extranonce1 = &quot;f8002c90&quot; // from earlier
extranonce2 = &quot;00000002&quot; // can be anything, but 4 bytes
</code></pre>
<p>With this, we can start building our Merkle root:
First, the coinbase:</p>
<pre><code>coinbase = coinb1  + extranonce1 + extranonce2 + coinb2;
coinbase = &quot;01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff270362f401062f503253482f049b8f175308f8002c90000000020d2f7374726174756d506f6f6c2f000000000100868591052100001976a91431482118f1d7504daf1c001cbfaf91ad580d176d88ac00000000&quot;
</code></pre>
<p>Now, we convert this coinbase into binary. No flips or BE-LE conversions required, straight from left to right.
The resulting binary data is hashed with sha256(sha256(data)).
From here on, I will post binary as hex representation, but as is: Left to right, no endianess conversion</p>
<pre><code>resulting hash : 280b3927f6763b1ed90cae2a3cef4d27c743f6a7d91e3901dc3816a46acacf36
</code></pre>
<p>This is the start for the merkle concatination. Concatinating means just joining them. 32 byte for the hash and 32 byte for each merkleroot result in 64 byte of data to hash.</p>
<pre><code>for each Merkle_branch
    byte[64] = hash + merkle_branch
    hash = sha256(sha256(byte))
end
</code></pre>
<p>For the example it looks like this:</p>
<pre><code>byte = 280b3927f6763b1ed90cae2a3cef4d27c743f6a7d91e3901dc3816a46acacf36 + 57351e8569cb9d036187a79fd1844fd930c1309efcd16c46af9bb9713b6ee734
hash = e6df228610b9f0e96a42a4877565627a3e1e133e984b6c46ff6e44b7dc9dc056

byte = e6df228610b9f0e96a42a4877565627a3e1e133e984b6c46ff6e44b7dc9dc056 + 936ab9c33420f187acae660fcdb07ffdffa081273674f0f41e6ecc1347451d23
hash = 0b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d5422
</code></pre>
<p>which is the final merkle_root. There is no need of converting it back to hex, it can be kept in binary format for the next step</p>
<p>e) Block header
The block header is build with all previous information + the calculated merkle root. It results in 80 byte of Data</p>
<pre><code>blockHeader {
    version[4]
    prevhash[32]
    merkle_root[32]
    ntime[4]
    nbit[4]
    nonce[4]
}
</code></pre>
<p>Here, byte order gets a bit tricky: All 4 byte types are Little endian, and bytes have to be flipped. Merkleroot can be copied 1:1, without flipping bytes.
prevhash is what surprised me the most. It can be best viewed as an array of 8 4byte ints, where each of these ints has to be converted to LE, but the order is kept left to right.
I show it in the example:</p>
<pre><code>version:  00000002 --&gt; 02000000
prevhash: 7dcf1304 b04e7902 4066cd94 81aa464e 2fe17966 e19edf6f 33970e1f e0b60277
        --&gt;   0413cf7d 02794eb0 94cd6640 4e46aa81 6679e12f 6fdf9ee1 1f0e9733 7702b6e0 // 8 ints left to right, each one flipped
merkle:   0b1edc1c cf82d321 4423fc68 234f4946 119e39df 2cc2137e 31ebc186 191d5422 // nothing changed 
ntime:    53178f9b --&gt; 9b8f1753
nbits:    1b44dfdb --&gt; dbdf441b
</code></pre>
<p>Results in the following bytestream:</p>
<pre><code>020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229b8f1753dbdf441b00000000
</code></pre>
<p>Note that we don't need the padding or anything, like the bitcoin implementations have, the 80 bytes are all we need.
Now, lets hash it
f) hashing and result
sending this through a scrypt cycle results in the following hash:</p>
<pre><code>f6f13e350aa4f251e192ab8a78690ee99f1cc2d930d4ae16c4172a0a8aefddd0
</code></pre>
<p>Well, this is not the hash we are looking for... So we start playing with nonce first, and if thats not enough we can increase the ntime. Until finally, after a long time, we try</p>
<pre><code>nonce = &quot;00007f8a&quot; // BigEndian
time = &quot;53178f9f&quot; // BigEndian
</code></pre>
<p>This gives us the following Block and resulting hash:</p>
<pre><code>block = 020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229f8f1753dbdf441b8a7f0000
hash = 7441207b6390054623bc5e659ffe2581356dafc5ec41db44d27de85035000000
</code></pre>
<p>Looks kind of high, but here again, endianess has to be considered. To compare it with our Target, we have to compare high to low. And, not to forget that we have to change the byte order of our target:</p>
<pre><code>target = 0x000007fff8000000000000000000000000000000000000000000000000000000
   ---&gt;  0x000000000000000000000000000000000000000000000000000000f8ff070000
</code></pre>
<p>Now if we compare them:</p>
<pre><code>000000000000000000000000000000000000000000000000000000f8ff070000
7441207b6390054623bc5e659ffe2581356dafc5ec41db44d27de85035000000
</code></pre>
<p>We see that the hash is below our target, and we can submit it. Alternatively we can look at them in the other byte order (in which it is printed most of the time)</p>
<pre><code>000007fff8000000000000000000000000000000000000000000000000000000
0000003550e87dd244db41ecc5af6d358125fe9f655ebc23460590637b204174
</code></pre>
<p>Which looks the same, mostly. This leads us to our final step:
g) Submit Share
Now we collect the variable parameters we used, and send them to the server.</p>
<pre><code>user = &quot;user&quot;
job_id = &quot;b3ba&quot;
extranonce2 = &quot;00000002&quot; // No byte swapping needed. Its how we put it in the coinbase
ntime = &quot;53178f9f&quot; // This is Big Endian. The ntime in the block_header is little endian. IF you read it from your block_header, don't forget to swap
nonce = &quot;00007f8a&quot; // Same here. Convert To BigEndian before sending
</code></pre>
<p>We pack these Data in a neat JSon wrapper, and send it off to the server:</p>
<pre><code>{&quot;params&quot;: [&quot;User&quot;, &quot;b3ba&quot;, &quot;00000002&quot;, &quot;53178f9f&quot;, &quot;00007f8a&quot;], &quot;id&quot;: 4, &quot;method&quot;: &quot;mining.submit&quot;}
</code></pre>
<p>And, if all works well, and we have no other problems (like stale shares or anything), we get a positive response:</p>
<pre><code>{&quot;error&quot;: null, &quot;id&quot;: 4, &quot;result&quot;: true}
</code></pre>
<p>And thats it! For more shares repeat as often as wanted.</p>

CC BY-SA 3.0
2014-03-06T08:38:46.193Z
This really helps me a lot. Thank you. Im working on the pool side of things so what Im trying to do is veryfy the work of a miner. So if Im not missunderstanding here extranonce2 is fine as it is but ntime and nonce needs to be reversed.
Evelie
CC BY-SA 3.0
2014-03-06T09:08:04.827Z
@Evelie As far as I understood yes. extranonce2 is a bit strange though because it is generated by the miner. In my code, I concatinate "00000002" as string to the rest, and then convert it to binary, as shown. So it should be correct. ntime and nonce are of uint32 type, so they are little endian on your machine, but you need them to be big endian for communication.
MatthiasB
CC BY-SA 3.0
2014-03-06T18:09:41.803Z
Solved my problem. Thanks a lot once again. Funny is that the prevhash needs to be reversed to little endian.. and then same things (as you mentioned) on each 4 bits.
Evelie
CC BY-SA 3.0
2014-03-07T11:23:36.880Z
Nice article! I have not enough reputation to add my question to comments for which I'm appologizing.But are you sure that when hashing twice with sha256 "020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229f8f1753dbdf441b00000000" this header you will receive "f6f13e350aa4f251e192ab8a78690ee99f1cc2d930d4ae16c4172a0a8aefddd0". I can't hash neither of your headers to the values you have showed. Is there any additional reversing I'm not aware about? Thank you in advance.
user2517742
CC BY-SA 3.0
2014-03-07T13:53:59.683Z
I'll have a look at it and let you know then. Could be that I made a mistake there.
MatthiasB
CC BY-SA 3.0
2014-03-07T18:37:31.897Z
I just see, are you talking about the block_header or the merkle_root? The hash you posted is the block header, and it has to be hashed with scrypt, not dsha256. Dsha256 is only used for the merkleroot
MatthiasB
CC BY-SA 3.0
2017-07-20T12:17:35.907Z
@MatthiasB: even 3+ years later, most informative and correct post i've found; including the creator/developer of stratum's own notes. well done.
barrystyle
CC BY-SA 3.0
2017-11-21T00:32:06.543Z
@barrystyle I agree. Cannot believe that 3+ years later this is the most informative thing related with this subject. I have one question though, related with calculating target. Above target is calculated dividing "0x0000FFFF/difficutly_you_get_from_server" ... this first hex number, is this something like default difficulty which is always used and calculated in the same manner just changing the second division parameter?
cool
CC BY-SA 3.0
2018-04-22T14:17:13.547Z
What the hell happened to the prevhash? This isn't documented anywhere. I lost a day or two because of that.
Jules Lamur
CC BY-SA 3.0
2018-04-23T14:25:03.727Z
@JulesLamur What do you mean? The flipping? The is a small section about this in the answer
MatthiasB
CC BY-SA 3.0
2018-04-25T12:55:03.187Z
@MatthiasB I was referring to what you can find online. Your answer saved me a lot of time. Thank you.
Jules Lamur
CC BY-SA 4.0
2021-01-30T02:12:04.310Z
Hi, a few years later I still don't understand how the `target hex` was calculated, anyone here can explain a little bit more? (I am using C++)
WoooHaaaa
CC BY-SA 4.0
2014-03-05T22:27:58.520Z
2021-01-19T09:16:25.033Z
2021-01-19T09:16:25.033Z
MatthiasB
<p>I'm trying to write a Mining client for Scrypt-based mining using Stratum Communication.
As of now, I have some trouble verifying all my bit orders and sequences. Hashes I'm generating get always rejected due to not meeting the Target.</p>

<p>What I'm looking for is a full sequence of data, starting from the information I get from the stratum server (coinbases, merkles,...) to a final hash.</p>

<p>I could already verify parts of the algorithm (mainly from input to a valid merkle-root, using the information of <a href="http://mining.bitcoin.cz/stratum-mining/" rel="nofollow">http://mining.bitcoin.cz/stratum-mining/</a> , and a scrypt hashing, using the block header from <a href="https://litecoin.info/Scrypt" rel="nofollow">https://litecoin.info/Scrypt</a> ), but I guess there is some endian problem in between, or something completely different, I don't know... With a full workflow I could verify where the error happens.</p>

<p>Does anyone know where to get such data, or how to generate them for myself?</p>

CC BY-SA 3.0
2014-03-05T15:00:30.080Z
Gotten any further with this? I'm working on verifying the work a client submits. But I cant really get it right. I'm  expecting I also have some endian problems :/
Evelie
CC BY-SA 3.0
2014-03-05T15:02:58.530Z
@Evelie I managed to get a accepted share yesterday evening, but didn't have time for a summary yet. When I get home today, I'll summarize an example as it is accepted by my client and can give you the communication, as well as my error (it was also an endian problem).
MatthiasB
<scrypt><stratum><mining-software><block-header>
Full example data for scrypt Stratum-client
MatthiasB
# Full example data for scrypt Stratum-client

(Asked by: username_0 on 2014-03-02)

I'm trying to write a Mining client for Scrypt-based mining using Stratum Communication.
As of now, I have some trouble verifying all my bit orders and sequences. Hashes I'm generating get always rejected due to not meeting the Target.

What I'm looking for is a full sequence of data, starting from the information I get from the stratum server (coinbases, merkles,...) to a final hash.

I could already verify parts of the algorithm (mainly from input to a valid merkle-root, using the information of <http://mining.bitcoin.cz/stratum-mining/> , and a scrypt hashing, using the block header from <https://litecoin.info/Scrypt> ), but I guess there is some endian problem in between, or something completely different, I don't know... With a full workflow I could verify where the error happens.

Does anyone know where to get such data, or how to generate them for myself?

**Tags:** scrypt, stratum, mining-software, block-header

> **Comments:**
> **username_1**: Gotten any further with this? I'm working on verifying the work a client submits. But I cant really get it right. I'm  expecting I also have some endian problems :/  
> **username_0**: @username_1 I managed to get a accepted share yesterday evening, but didn't have time for a summary yet. When I get home today, I'll summarize an example as it is accepted by my client and can give you the communication, as well as my error (it was also an endian problem).  

---

## 3 answers

### Answer by username_0 on 2014-03-05. Score: 15 | Accepted answer

Alright, I finally managed to fix my bugs and get a full roundtrip. Here is an example for a full communication with a Pool.
I don't explain everything in detail as the API description can be found elsewhere.

a) Suscription

```
{"id": 1, "method": "mining.subscribe", "params": []}
{"error": null, "id": 1, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f8002c90", 4]}

```

We suscribe with the server. This has no parameters.
As result, we receive some Suscription ID, and our Extranonce1 + extranonce2 size, which we need for later.
b) authorization

```
{"params": ["User", "password"], "id": 2, "method": "mining.authorize"}
{"error": null, "id": 2, "result": true}

```

Authorize worker with Username + password. No parameters to store from the result.
c) Server -> difficulty

```
{"params": [32], "id": null, "method": "mining.set_difficulty"}

```

Sets the difficulty to 32, defining our target. The resulting difficulty can be calculated as

```
0x0000FFFF00000000000000000000000000000000000000000000000000000000 / 32 =
0x000007fff8000000000000000000000000000000000000000000000000000000

```

Now, the fun part:
d) Block info

```
{"params": ["b3ba", "7dcf1304b04e79024066cd9481aa464e2fe17966e19edf6f33970e1fe0b60277", "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff270362f401062f503253482f049b8f175308", "0d2f7374726174756d506f6f6c2f000000000100868591052100001976a91431482118f1d7504daf1c001cbfaf91ad580d176d88ac00000000", ["57351e8569cb9d036187a79fd1844fd930c1309efcd16c46af9bb9713b6ee734", "936ab9c33420f187acae660fcdb07ffdffa081273674f0f41e6ecc1347451d23"], "00000002", "1b44dfdb", "53178f9b", true], "id": null, "method": "mining.notify"}

```

I split the parameters and assign them to variables

```
job_id = "b3ba"
prevhash = "7dcf1304b04e79024066cd9481aa464e2fe17966e19edf6f33970e1fe0b60277"
coinb1 = "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff270362f401062f503253482f049b8f175308"
coinb2 = "0d2f7374726174756d506f6f6c2f000000000100868591052100001976a91431482118f1d7504daf1c001cbfaf91ad580d176d88ac00000000"
Merklebranches = [ 
    "57351e8569cb9d036187a79fd1844fd930c1309efcd16c46af9bb9713b6ee734", 
    "936ab9c33420f187acae660fcdb07ffdffa081273674f0f41e6ecc1347451d23"
    ]
version = "00000002"
nbits = "1b44dfdb"
ntime = "53178f9b"
clean_jobs = true// Not required for block, just for completeness

```

What we also need is extranonce1 and extranonce 2:

```
extranonce1 = "f8002c90" // from earlier
extranonce2 = "00000002" // can be anything, but 4 bytes

```

With this, we can start building our Merkle root:
First, the coinbase:

```
coinbase = coinb1  + extranonce1 + extranonce2 + coinb2;
coinbase = "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff270362f401062f503253482f049b8f175308f8002c90000000020d2f7374726174756d506f6f6c2f000000000100868591052100001976a91431482118f1d7504daf1c001cbfaf91ad580d176d88ac00000000"

```

Now, we convert this coinbase into binary. No flips or BE-LE conversions required, straight from left to right.
The resulting binary data is hashed with sha256(sha256(data)).
From here on, I will post binary as hex representation, but as is: Left to right, no endianess conversion

```
resulting hash : 280b3927f6763b1ed90cae2a3cef4d27c743f6a7d91e3901dc3816a46acacf36

```

This is the start for the merkle concatination. Concatinating means just joining them. 32 byte for the hash and 32 byte for each merkleroot result in 64 byte of data to hash.

```
for each Merkle_branch
    byte[64] = hash + merkle_branch
    hash = sha256(sha256(byte))
end

```

For the example it looks like this:

```
byte = 280b3927f6763b1ed90cae2a3cef4d27c743f6a7d91e3901dc3816a46acacf36 + 57351e8569cb9d036187a79fd1844fd930c1309efcd16c46af9bb9713b6ee734
hash = e6df228610b9f0e96a42a4877565627a3e1e133e984b6c46ff6e44b7dc9dc056

byte = e6df228610b9f0e96a42a4877565627a3e1e133e984b6c46ff6e44b7dc9dc056 + 936ab9c33420f187acae660fcdb07ffdffa081273674f0f41e6ecc1347451d23
hash = 0b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d5422

```

which is the final merkle\_root. There is no need of converting it back to hex, it can be kept in binary format for the next step

e) Block header
The block header is build with all previous information + the calculated merkle root. It results in 80 byte of Data

```
blockHeader {
    version[4]
    prevhash[32]
    merkle_root[32]
    ntime[4]
    nbit[4]
    nonce[4]
}

```

Here, byte order gets a bit tricky: All 4 byte types are Little endian, and bytes have to be flipped. Merkleroot can be copied 1:1, without flipping bytes.
prevhash is what surprised me the most. It can be best viewed as an array of 8 4byte ints, where each of these ints has to be converted to LE, but the order is kept left to right.
I show it in the example:

```
version:  00000002 --> 02000000
prevhash: 7dcf1304 b04e7902 4066cd94 81aa464e 2fe17966 e19edf6f 33970e1f e0b60277
        -->   0413cf7d 02794eb0 94cd6640 4e46aa81 6679e12f 6fdf9ee1 1f0e9733 7702b6e0 // 8 ints left to right, each one flipped
merkle:   0b1edc1c cf82d321 4423fc68 234f4946 119e39df 2cc2137e 31ebc186 191d5422 // nothing changed 
ntime:    53178f9b --> 9b8f1753
nbits:    1b44dfdb --> dbdf441b

```

Results in the following bytestream:

```
020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229b8f1753dbdf441b00000000

```

Note that we don't need the padding or anything, like the bitcoin implementations have, the 80 bytes are all we need.
Now, lets hash it
f) hashing and result
sending this through a scrypt cycle results in the following hash:

```
f6f13e350aa4f251e192ab8a78690ee99f1cc2d930d4ae16c4172a0a8aefddd0

```

Well, this is not the hash we are looking for... So we start playing with nonce first, and if thats not enough we can increase the ntime. Until finally, after a long time, we try

```
nonce = "00007f8a" // BigEndian
time = "53178f9f" // BigEndian

```

This gives us the following Block and resulting hash:

```
block = 020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229f8f1753dbdf441b8a7f0000
hash = 7441207b6390054623bc5e659ffe2581356dafc5ec41db44d27de85035000000

```

Looks kind of high, but here again, endianess has to be considered. To compare it with our Target, we have to compare high to low. And, not to forget that we have to change the byte order of our target:

```
target = 0x000007fff8000000000000000000000000000000000000000000000000000000
   --->  0x000000000000000000000000000000000000000000000000000000f8ff070000

```

Now if we compare them:

```
000000000000000000000000000000000000000000000000000000f8ff070000
7441207b6390054623bc5e659ffe2581356dafc5ec41db44d27de85035000000

```

We see that the hash is below our target, and we can submit it. Alternatively we can look at them in the other byte order (in which it is printed most of the time)

```
000007fff8000000000000000000000000000000000000000000000000000000
0000003550e87dd244db41ecc5af6d358125fe9f655ebc23460590637b204174

```

Which looks the same, mostly. This leads us to our final step:
g) Submit Share
Now we collect the variable parameters we used, and send them to the server.

```
user = "user"
job_id = "b3ba"
extranonce2 = "00000002" // No byte swapping needed. Its how we put it in the coinbase
ntime = "53178f9f" // This is Big Endian. The ntime in the block_header is little endian. IF you read it from your block_header, don't forget to swap
nonce = "00007f8a" // Same here. Convert To BigEndian before sending

```

We pack these Data in a neat JSon wrapper, and send it off to the server:

```
{"params": ["User", "b3ba", "00000002", "53178f9f", "00007f8a"], "id": 4, "method": "mining.submit"}

```

And, if all works well, and we have no other problems (like stale shares or anything), we get a positive response:

```
{"error": null, "id": 4, "result": true}

```

And thats it! For more shares repeat as often as wanted.

> **Comments:**
> **username_1**: This really helps me a lot. Thank you. Im working on the pool side of things so what Im trying to do is veryfy the work of a miner. So if Im not missunderstanding here extranonce2 is fine as it is but ntime and nonce needs to be reversed.  
> **username_0**: @username_1 As far as I understood yes. extranonce2 is a bit strange though because it is generated by the miner. In my code, I concatinate "00000002" as string to the rest, and then convert it to binary, as shown. So it should be correct. ntime and nonce are of uint32 type, so they are little endian on your machine, but you need them to be big endian for communication.  
> **username_1**: Solved my problem. Thanks a lot once again. Funny is that the prevhash needs to be reversed to little endian.. and then same things (as you mentioned) on each 4 bits.  
> **username_4**: Nice article! I have not enough reputation to add my question to comments for which I'm appologizing.But are you sure that when hashing twice with sha256 "020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229f8f1753dbdf441b00000000" this header you will receive "f6f13e350aa4f251e192ab8a78690ee99f1cc2d930d4ae16c4172a0a8aefddd0". I can't hash neither of your headers to the values you have showed. Is there any additional reversing I'm not aware about? Thank you in advance.  
> **username_0**: I'll have a look at it and let you know then. Could be that I made a mistake there.  
> **username_0**: I just see, are you talking about the block_header or the merkle_root? The hash you posted is the block header, and it has to be hashed with scrypt, not dsha256. Dsha256 is only used for the merkleroot  
> **username_5**: @username_0: even 3+ years later, most informative and correct post i've found; including the creator/developer of stratum's own notes. well done.  
> **username_6**: @username_5 I agree. Cannot believe that 3+ years later this is the most informative thing related with this subject. I have one question though, related with calculating target. Above target is calculated dividing "0x0000FFFF/difficutly_you_get_from_server" ... this first hex number, is this something like default difficulty which is always used and calculated in the same manner just changing the second division parameter?  
> **username_7**: What the hell happened to the prevhash? This isn't documented anywhere. I lost a day or two because of that.  
> **username_0**: @username_7 What do you mean? The flipping? The is a small section about this in the answer  
> **username_7**: @username_0 I was referring to what you can find online. Your answer saved me a lot of time. Thank you.  
> **username_8**: Hi, a few years later I still don't understand how the `target hex` was calculated, anyone here can explain a little bit more? (I am using C++)  

---

### Answer by username_2 on 2014-10-09. Score: 1

I don't have enough reputation to comment, but just to let you know, the example block header ends with "f8f1753dbdf441b00000000", but it should really be "b8f1753dbdf441b00000000" or fully:

> 020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229b8f1753dbdf441b00000000

Caught this writing a unit test.

> **Comments:**
> **username_0**: Wow, thanks! I think I copied the hash with the final time instead of the starting time by mistake. Do you know if the resulting hash is correct with the correct block header? Otherwise I'll have to rehash it and update my answer. But thanks a lot of letting me know!  
> **username_2**: The resulting hash is indeed correct with the block header I wrote up above. Just changing this should set everything straight.  

---

### Answer by username_3 on 2014-03-08. Score: 0

All else seems OK , but I think there is some issue with the SHA256x2 - e.g. :

according to your example the sha256x2 of :  
`020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229f8f1753dbdf441b00000000`

Should return:

`f6f13e350aa4f251e192ab8a78690ee99f1cc2d930d4ae16c4172a0a8aefddd0`

BUT IT ACTUALLY RETURNS :

`077a4c8f19b52972747fb29a329064965d1c1176a1cd88f1f091e4aabb6fe3fa`

Am I missing something ?

To verify - go to : <http://www.compileonline.com/execute_python_online.php>

and execute :

```
#!/usr/local/bin/python2.7
import hashlib  
header_hex = "020000000413cf7d02794eb094cd66404e46aa816679e12f6fdf9ee11f0e97337702b6e00b1edc1ccf82d3214423fc68234f4946119e39df2cc2137e31ebc186191d54229f8f1753dbdf441b00000000"
header_bin = header_hex.decode('hex')
hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()

print hash.encode('hex_codec') 

```

`

> **Comments:**
> **username_0**: Please note that this example is based on scrypt, not an dsha256. While the calculation of the block header is the same, the final hash is calculated differently.  
> **username_3**: I'm not sure what you mean by script in this context :) in brief - everything in your example is correct , workflow etc. and it is far far better then the one in the slash's description which lacks of about 5-6 principal mistakes.  
> **username_0**: scrypt, not script. Its the proof of work from Dogecoin, Litecoin and others while dsha256 is used by Bitcoin. There is a difference. The bitcoin algorithm (dsha256) uses some padding of the block_header and midstate and such, which I am not aware of, so unfortunately I think it is not fully compatible with my scrypt description.  

---

