<p>The client needs to handle dividing up the extranonce2 across all workers. Proxies can do this by moving part of the extranonce2 into the extranonce1.</p>

<p>Generally, the entire pool uses the same job_id for any given template, though it's only guaranteed to be valid across a single connection.</p>

<p>There is no reason for a server to send a new mining.notify when additional workers authenticate, though there is no reason they couldn't choose to either. You'll notice that most servers send the first mining.notify <em>before any</em> workers authenticate.</p>

<p>The practical problem with multiple workers on a single connection is that share difficulty is <em>also</em> set per-connection, and it is common that servers would want to give different workers their own difficulty levels.</p>

<p>While multiple workers is not especially common, it is helpful to reduce bandwidth on a large network where you may want to track pool statistics per-worker - or even conceivably per-chip (though no software supports that as of this time).</p>

CC BY-SA 3.0
2014-07-11T17:24:33.707Z
Thanks a lot for your answer. I've some additional questions if you don't mind. 1) I didn't quite understand what does "job_id is only guaranteed to be valid across a single connection" exactly mean? If the entire pool uses the same job_id for any given template, in what situation would 2 miners on 2 different connections have 2 different job_ids? 2) "It is common that servers would want to give different workers their own difficulty levels" - could vardiff be a solution for this problem? Thank you again.
thankyou
CC BY-SA 3.0
2014-07-12T18:17:07.893Z
The entire pool *may* use the same job_id for any given template, but it isn't required to outside the scope of a single connection.
Luke Dashjr
CC BY-SA 3.0
2014-07-12T18:17:36.883Z
Vardiff doesn't help because the pool can only adjust the entire connection at the same time. It cannot adjust only a specific worker.
Luke Dashjr
CC BY-SA 3.0
2014-07-11T16:18:37.363Z
2014-07-11T16:18:37.363Z
Luke Dashjr
<p>The <a href="https://mining.bitcoin.cz/stratum-mining" rel="nofollow">stratum protocol</a> supports authorizing multiple workers in a single connection. Unfortunately, I didn't find any documentation about how this should be handled by pool server software.</p>

<p>If multiple workers share the same <code>extranonce1</code> (which is a <strong>per-connection</strong> unique string), wouldn't the workers duplicate work? Is this to be handled by the client?</p>

<p>Do all the workers use the same <code>job_id</code> for share submission?</p>

<p>Should a server send a job notify when the second, third etc. worker successfully passes authorization?</p>

<p>And finally, does anyone actually use this (multiple workers per connection) and for what purpose?</p>

CC BY-SA 3.0
2014-07-10T19:42:50.317Z
Regarding the second question, I may have misunderstood the purpose of `job_id`. Is it common for all clients currently working on the block solving and does it change only if a new block template comes in? So share submission is identified by worker name, nonce etc. but not by job_id, it's there only for stale shares check?
thankyou
<mining-technical-details><stratum>
How do pool server's handle multiple workers sharing one connection with Stratum protocol
thankyou
# How do pool server's handle multiple workers sharing one connection with Stratum protocol

(Asked by: username_0 on 2014-07-10)

The [stratum protocol](https://mining.bitcoin.cz/stratum-mining) supports authorizing multiple workers in a single connection. Unfortunately, I didn't find any documentation about how this should be handled by pool server software.

If multiple workers share the same `extranonce1` (which is a **per-connection** unique string), wouldn't the workers duplicate work? Is this to be handled by the client?

Do all the workers use the same `job_id` for share submission?

Should a server send a job notify when the second, third etc. worker successfully passes authorization?

And finally, does anyone actually use this (multiple workers per connection) and for what purpose?

**Tags:** mining-technical-details, stratum

> **Comments:**
> **username_0**: Regarding the second question, I may have misunderstood the purpose of `job_id`. Is it common for all clients currently working on the block solving and does it change only if a new block template comes in? So share submission is identified by worker name, nonce etc. but not by job_id, it's there only for stale shares check?  

---

## 1 answers

### Answer by username_1 on 2014-07-11. Score: 1 | Accepted answer

The client needs to handle dividing up the extranonce2 across all workers. Proxies can do this by moving part of the extranonce2 into the extranonce1.

Generally, the entire pool uses the same job\_id for any given template, though it's only guaranteed to be valid across a single connection.

There is no reason for a server to send a new mining.notify when additional workers authenticate, though there is no reason they couldn't choose to either. You'll notice that most servers send the first mining.notify *before any* workers authenticate.

The practical problem with multiple workers on a single connection is that share difficulty is *also* set per-connection, and it is common that servers would want to give different workers their own difficulty levels.

While multiple workers is not especially common, it is helpful to reduce bandwidth on a large network where you may want to track pool statistics per-worker - or even conceivably per-chip (though no software supports that as of this time).

> **Comments:**
> **username_0**: Thanks a lot for your answer. I've some additional questions if you don't mind. 1) I didn't quite understand what does "job_id is only guaranteed to be valid across a single connection" exactly mean? If the entire pool uses the same job_id for any given template, in what situation would 2 miners on 2 different connections have 2 different job_ids? 2) "It is common that servers would want to give different workers their own difficulty levels" - could vardiff be a solution for this problem? Thank you again.  
> **username_1**: The entire pool *may* use the same job_id for any given template, but it isn't required to outside the scope of a single connection.  
> **username_1**: Vardiff doesn't help because the pool can only adjust the entire connection at the same time. It cannot adjust only a specific worker.  

---

