<ol>
<li><p>the link you posted is referring to for the full process of mining, as you would need if you're using an ASIC or some other hardware solution capable of generating 4 gigahashes or more per second. if you're using <code>getwork</code>, most of that information is irrelevant and confusing.</p></li>
<li><p>see (1) above. you don't worry about extraNonce when using getwork; you can just request <code>getwork</code> again and get a new <code>data</code> string from the server.</p></li>
<li><p>the reason for reversing the header (actually reversing each 32-bit word in the header) is that <em>it has already been reversed (converted to little-endian)</em> before sending it to you and you need to <em>undo</em> that reversal, putting it back in big-endian form.</p></li>
</ol>

<p>all you need to do when using getwork is:</p>

<ul>
<li>convert the <code>data</code> to big-endian</li>
<li>get the sha256 hash of the sha256 hash of the 80-byte header</li>
<li>if that hash is below the threshold, send your header with current nonce to the server using the appropriate <code>getwork</code> RPC call with data</li>
<li>keep trying again with different nonces each time (the last 4 bytes of the 80 bytes are the nonce)</li>
</ul>

CC BY-SA 3.0
2014-01-26T10:42:51.270Z
you mean the only thing I care about will be the last 4 bytes of the data, right? But whose last bytes, the little-endian one or the other? :)
Eray Tuncer
CC BY-SA 3.0
2014-01-26T18:06:24.097Z
it really doesn't matter. typically, at least on x86 computers, people increment the little-endian number, then convert the block to big-endian for hashing. I just use random numbers so I couldn't care less about endianness; just have to make sure to put it in the right order for submission to the server.
jcomeau_ictx
CC BY-SA 3.0
2014-01-26T18:13:45.857Z
remember, it's the *same* 4 bytes in each case; you're not reversing the 80 bytes, you're reversing every 4 bytes *within* the 80 bytes, so 0x12345678 becomes 0x78563412.
jcomeau_ictx
CC BY-SA 3.0
2014-01-27T01:03:53.687Z
In the example of 0x12345678 you are reversing every 1 byte chunks within a 4 byte value right? 
0x12345678 = 00010010-00110100-01010110-01111000.    
0x78563412 = 01111000-01010110-00110100-00010010
Eray Tuncer
CC BY-SA 3.0
2014-01-27T01:07:52.233Z
yes, that's the idea.
jcomeau_ictx
CC BY-SA 3.0
2014-01-26T06:14:13.957Z
2014-01-26T06:14:13.957Z
jcomeau_ictx
<p>Guys I have a few points that are not clear for me.
1) In the link below it says there are some fields we have to combine and hash. However when I get a work by saying getwork from a pool. What I get is in the below either. The problem is that I cannot find the fields listed in the first link, Version, hashPrevBlock etc.</p>

<p><a href="https://en.bitcoin.it/wiki/Block_hashing_algorithm" rel="nofollow">https://en.bitcoin.it/wiki/Block_hashing_algorithm</a></p>

<p>Getwork result.</p>

<pre><code>{   'data':'0000000271112b7a1cf8e97b8367102f7e155499bf5c7303cbcdd4360000000000000000427719b35a84bc7732edd34ff3a6278dc4ac0ec2a9544e6088bc0bd719e17a8e52db3b211902666600000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000',
'hash1':'00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000',
'target':'0000000000000000000000000000000000000000000000000000ffff00000000',
'midstate':'45aebb01c0fdb704ee7d2bbf02665943f50f299ff8bb252e614100065bc5c20c'
}
</code></pre>

<p>2) It says in the first link "Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root." Should I put extra 32 bits for extranonce?</p>

<p>3) What is the reason reversing the header?</p>

<block><hash><getwork><nonce>
Block Hashing Data
Eray Tuncer
# Block Hashing Data

(Asked by: username_0 on 2014-01-25)

Guys I have a few points that are not clear for me.
1) In the link below it says there are some fields we have to combine and hash. However when I get a work by saying getwork from a pool. What I get is in the below either. The problem is that I cannot find the fields listed in the first link, Version, hashPrevBlock etc.

<https://en.bitcoin.it/wiki/Block_hashing_algorithm>

Getwork result.

```
{   'data':'0000000271112b7a1cf8e97b8367102f7e155499bf5c7303cbcdd4360000000000000000427719b35a84bc7732edd34ff3a6278dc4ac0ec2a9544e6088bc0bd719e17a8e52db3b211902666600000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000',
'hash1':'00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000',
'target':'0000000000000000000000000000000000000000000000000000ffff00000000',
'midstate':'45aebb01c0fdb704ee7d2bbf02665943f50f299ff8bb252e614100065bc5c20c'
}

```

2) It says in the first link "Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root." Should I put extra 32 bits for extranonce?

3) What is the reason reversing the header?

**Tags:** block, hash, getwork, nonce


---

## 1 answers

### Answer by username_1 on 2014-01-26. Score: 0 | Accepted answer

1. the link you posted is referring to for the full process of mining, as you would need if you're using an ASIC or some other hardware solution capable of generating 4 gigahashes or more per second. if you're using `getwork`, most of that information is irrelevant and confusing.
2. see (1) above. you don't worry about extraNonce when using getwork; you can just request `getwork` again and get a new `data` string from the server.
3. the reason for reversing the header (actually reversing each 32-bit word in the header) is that *it has already been reversed (converted to little-endian)* before sending it to you and you need to *undo* that reversal, putting it back in big-endian form.

all you need to do when using getwork is:

* convert the `data` to big-endian
* get the sha256 hash of the sha256 hash of the 80-byte header
* if that hash is below the threshold, send your header with current nonce to the server using the appropriate `getwork` RPC call with data
* keep trying again with different nonces each time (the last 4 bytes of the 80 bytes are the nonce)

> **Comments:**
> **username_0**: you mean the only thing I care about will be the last 4 bytes of the data, right? But whose last bytes, the little-endian one or the other? :)  
> **username_1**: it really doesn't matter. typically, at least on x86 computers, people increment the little-endian number, then convert the block to big-endian for hashing. I just use random numbers so I couldn't care less about endianness; just have to make sure to put it in the right order for submission to the server.  
> **username_1**: remember, it's the *same* 4 bytes in each case; you're not reversing the 80 bytes, you're reversing every 4 bytes *within* the 80 bytes, so 0x12345678 becomes 0x78563412.  
> **username_0**: In the example of 0x12345678 you are reversing every 1 byte chunks within a 4 byte value right?  0x12345678 = 00010010-00110100-01010110-01111000.     0x78563412 = 01111000-01010110-00110100-00010010  
> **username_1**: yes, that's the idea.  

---

