<p>You can find some examples of the GetWork protocol <a href="https://bitcointalk.org/index.php?topic=51281.msg611090#msg611090" rel="nofollow">here</a>.</p>

<p>Generally, the pool provides a block header that is to be hashed with various nonces, as well as some additional information, such as:</p>

<ul>
<li>hash1, which is always "0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000"</li>
<li>midstate (deprecated), a value calculated by hashing half of the block header, used to speed up the process. Midstate is deprecated, as it is redundant data that can be calculated by the miner.</li>
<li>target - the target that is to be used to determine if the header is hashed correctly</li>
<li>Various other <a href="https://en.bitcoin.it/wiki/Getwork" rel="nofollow">protocol extensions</a></li>
</ul>

<p>The pool has to keep a track of the various block headers sent, as well as their corresponding blocks.</p>

<ul>
<li>Generally, the transactions that are included in the block are all the transactions that the pool knows about (with some exceptions, for example some pools exclude 0 fee transactions altogether).</li>
<li>The order of the transactions can be random, but the coinbase transaction is most often the first transaction in the block.</li>
<li>Most miners will work on different sets of transactions, but most often it will just differ by the coinbase transaction or their order.</li>
<li>If a transaction is included in a block that gets overwritten by a fork it will be be treated as a new transaction to be considered for inclusion in the block. Provided there was no double-spend attempt, it should be included in the future blocks.</li>
</ul>

CC BY-SA 3.0
2012-09-21T06:32:10.590Z
2012-09-21T06:32:10.590Z
ThePiachu
<p>According to <a href="https://bitcoin.stackexchange.com/a/1378/1878">this answer</a> GetWork() sends "a chunk of data containing the block data, including the randomized bits, and the nonce (the bit which the miner changes)."</p>

<p>Can anyone provide details on that logic?  For example:</p>

<ul>
<li><p>What transactions are included and which aren't?  </p></li>
<li><p>What ordering of transactions occur?</p></li>
<li><p>Is it likely that multiple solo or pooled miners are mining a different set of transactions?</p></li>
<li><p>If latency (or bad network connectivity)  were to cause transactions to be delayed, and added to a fork that is discarded, will they be re-added to the next GetWork() request?</p></li>
</ul>

<protocol><getwork><mining-technical-details><transaction-selection>
What are the internal details of GetWork() .. the foundation of Bitcoin mining?
makerofthings7
# What are the internal details of GetWork() .. the foundation of Bitcoin mining?

(Asked by: username_0 on 2012-09-20)

According to [this answer](https://bitcoin.stackexchange.com/a/1378/1878) GetWork() sends "a chunk of data containing the block data, including the randomized bits, and the nonce (the bit which the miner changes)."

Can anyone provide details on that logic? For example:

* What transactions are included and which aren't?
* What ordering of transactions occur?
* Is it likely that multiple solo or pooled miners are mining a different set of transactions?
* If latency (or bad network connectivity) were to cause transactions to be delayed, and added to a fork that is discarded, will they be re-added to the next GetWork() request?

**Tags:** protocol, getwork, mining-technical-details, transaction-selection


---

## 1 answers

### Answer by username_1 on 2012-09-21. Score: 1 | Accepted answer

You can find some examples of the GetWork protocol [here](https://bitcointalk.org/index.php?topic=51281.msg611090#msg611090).

Generally, the pool provides a block header that is to be hashed with various nonces, as well as some additional information, such as:

* hash1, which is always "0000000000000000000000000000000000000000000000000000000000000000000000800000000 0000000000000000000000000000000000000000000010000"
* midstate (deprecated), a value calculated by hashing half of the block header, used to speed up the process. Midstate is deprecated, as it is redundant data that can be calculated by the miner.
* target - the target that is to be used to determine if the header is hashed correctly
* Various other [protocol extensions](https://en.bitcoin.it/wiki/Getwork)

The pool has to keep a track of the various block headers sent, as well as their corresponding blocks.

* Generally, the transactions that are included in the block are all the transactions that the pool knows about (with some exceptions, for example some pools exclude 0 fee transactions altogether).
* The order of the transactions can be random, but the coinbase transaction is most often the first transaction in the block.
* Most miners will work on different sets of transactions, but most often it will just differ by the coinbase transaction or their order.
* If a transaction is included in a block that gets overwritten by a fork it will be be treated as a new transaction to be considered for inclusion in the block. Provided there was no double-spend attempt, it should be included in the future blocks.


---

