<p>The stratum pool managing software I'm familiar with is <a href="https://github.com/zone117x/node-stratum-pool" rel="nofollow">https://github.com/zone117x/node-stratum-pool</a>, so I can tell you what they do. Stratum is a protocol, though, so multiple pieces of software could implement it differently.</p>

<p>This parameter is controlled by the <code>blockRefreshInterval</code> in the config. Every <code>blockRefreshInterval</code> milliseconds, the stratum server checks the bitcoin core node, via RPC, for new blocks using <code>getblocktemplate</code>. If there hasn't been a new block since the last time <code>getblocktemplate</code> was called, then it sets the current job, which is returned to all new requests for work.</p>

<p>The polling interval suggested in the config is every 1 second. Miners may request work at very different rates as well, so some may be working on older work. As long as it's work for the next block, it's considered valid though. The pool does use the same node and mempool data to build blocks, though. So, given all these variables, <strong>miners most likely won't be working on the exact same transaction set</strong>.</p>

<p>Relevant bits of code: </p>

<ul>
<li><a href="https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/pool.js#L555-L562" rel="nofollow">https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/pool.js#L555-L562</a></li>
<li><a href="https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/jobManager.js#L138" rel="nofollow">https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/jobManager.js#L138</a></li>
<li><a href="https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/pool.js#L492" rel="nofollow">https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/pool.js#L492</a></li>
</ul>

CC BY-SA 3.0
2015-12-15T03:41:51.937Z
Ok, thanks this is good stuff. From what I see initially (might take me a while to digest this) processTemplate will just return false if the block hasn't changed. So I'm still missing where the data gets refreshed if the block hasn't changed. Seems like it will keep the same data unless the block changes, which means all miners would be working on the same job essentially, and the same set of txs. I'll keep looking at it though.
Fraggle
CC BY-SA 3.0
2015-12-16T14:51:05.290Z
Now that I look at it again, I think you're right. This seems like a poor strategy, though, because newer transactions wouldn't get mined. It could be done intentionally, if it had some benefit for miners, but I don't see any benefits off hand. The regular get block template polling seems to only use the result if there has been a new block. Maybe we should open a github issue about this.
morsecoder
CC BY-SA 3.0
2015-12-16T14:58:29.983Z
Judging by their commit log and un maintained issues list, though, I don't think it will do any good. You might try looking at https://github.com/int6/CoiniumServ or https://github.com/slush0/stratum.
morsecoder
CC BY-SA 3.0
2015-12-16T15:06:29.350Z
Needless to say, the way it SHOULD work in any decently implemented stratum server is that you regularly check for new transactions (so that new transactions get mined), and update the current job to be given out from here forward (until a new block is found). Any work done for any jobs given out that build on the most recent block are valid. So, in the expected behavior, miners would not be mining on exactly the same transaction set most of the time.
morsecoder
CC BY-SA 3.0
2015-12-17T16:12:35.760Z
Ok, thanks. I'm going to mark this as the answer. I think with the comments above it provides enough info. Also of course there are other stratum pool implementations that may work differently than this code base. So ultimately maybe figuring out what the top mining pools are doing is what I really need to do.
Fraggle
CC BY-SA 3.0
2015-12-14T13:35:54.963Z
2015-12-14T13:35:54.963Z
morsecoder
<p>When miners connect to the server, they get a "job" message back with a merkle_branch field that has hashes that correspond to transactions that will be included in the block being worked on. </p>

<p>What I'm wondering is, does the pool server bother changing that transaction set very often, or do they just wait for a block to be solved, and only then broadcast a new job with a different list?</p>

<p>In other words, in between block solvings, is everyone in the pool generally working on the same set of transactions? </p>

<mining-pools><stratum>
In stratum mining pools, are most miners working on the same set of transactions?
Fraggle
# In stratum mining pools, are most miners working on the same set of transactions?

(Asked by: username_0 on 2015-12-13)

When miners connect to the server, they get a "job" message back with a merkle\_branch field that has hashes that correspond to transactions that will be included in the block being worked on.

What I'm wondering is, does the pool server bother changing that transaction set very often, or do they just wait for a block to be solved, and only then broadcast a new job with a different list?

In other words, in between block solvings, is everyone in the pool generally working on the same set of transactions?

**Tags:** mining-pools, stratum


---

## 1 answers

### Answer by username_1 on 2015-12-14. Score: 0 | Accepted answer

The stratum pool managing software I'm familiar with is <https://github.com/zone117x/node-stratum-pool>, so I can tell you what they do. Stratum is a protocol, though, so multiple pieces of software could implement it differently.

This parameter is controlled by the `blockRefreshInterval` in the config. Every `blockRefreshInterval` milliseconds, the stratum server checks the bitcoin core node, via RPC, for new blocks using `getblocktemplate`. If there hasn't been a new block since the last time `getblocktemplate` was called, then it sets the current job, which is returned to all new requests for work.

The polling interval suggested in the config is every 1 second. Miners may request work at very different rates as well, so some may be working on older work. As long as it's work for the next block, it's considered valid though. The pool does use the same node and mempool data to build blocks, though. So, given all these variables, **miners most likely won't be working on the exact same transaction set**.

Relevant bits of code:

* <https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/pool.js#L555-L562>
* <https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/jobManager.js#L138>
* <https://github.com/zone117x/node-stratum-pool/blob/02e78da1ab53a2409bbb8721f9771346c373482b/lib/pool.js#L492>

> **Comments:**
> **username_0**: Ok, thanks this is good stuff. From what I see initially (might take me a while to digest this) processTemplate will just return false if the block hasn't changed. So I'm still missing where the data gets refreshed if the block hasn't changed. Seems like it will keep the same data unless the block changes, which means all miners would be working on the same job essentially, and the same set of txs. I'll keep looking at it though.  
> **username_1**: Now that I look at it again, I think you're right. This seems like a poor strategy, though, because newer transactions wouldn't get mined. It could be done intentionally, if it had some benefit for miners, but I don't see any benefits off hand. The regular get block template polling seems to only use the result if there has been a new block. Maybe we should open a github issue about this.  
> **username_1**: Judging by their commit log and un maintained issues list, though, I don't think it will do any good. You might try looking at https://github.com/int6/CoiniumServ or https://github.com/slush0/stratum.  
> **username_1**: Needless to say, the way it SHOULD work in any decently implemented stratum server is that you regularly check for new transactions (so that new transactions get mined), and update the current job to be given out from here forward (until a new block is found). Any work done for any jobs given out that build on the most recent block are valid. So, in the expected behavior, miners would not be mining on exactly the same transaction set most of the time.  
> **username_0**: Ok, thanks. I'm going to mark this as the answer. I think with the comments above it provides enough info. Also of course there are other stratum pool implementations that may work differently than this code base. So ultimately maybe figuring out what the top mining pools are doing is what I really need to do.  

---

