<p>The problem you are describing could be due to pool optimisation, as it is easier to prune 1 minute old shares than probably it is to look through 10 minutes of shares in order to validate them.</p>

<p>As for why a miner would request new work from a pool, other than as a result of longpolling or finishing a work, might be due to the work becoming invalid with time (with standard protocol a miner would request work every second). Alternatively, the miner is trying to be malicious and trying to make the pool do extra work.</p>

CC BY-SA 3.0
2012-03-31T23:55:26.957Z
2012-03-31T23:55:26.957Z
ThePiachu
<p>This is asked in a context to better understand why a submitted share by a miner might be rejected.</p>

<p>I know when a new block gets solved that would require a work update, which is approximately every 10 mins on average. Are there any other circumstances where miners in a pool would get new work from the pool server?</p>

<p>I'm mainly asking this question to better understand the explanation given <a href="https://bitcointalk.org/index.php?topic=60507.msg706083#msg706083" rel="nofollow">here</a>:</p>

<blockquote>
  <p>The cause of this problem is low overall hashrate. Phoenix maintains a work queue to reduce hashrate disruptions caused by momentary connection problems. This works great on faster hardware like the ATI 5870, but it can cause issues with miners that get &lt;100 Mhash or so. The reason for "unknown-work" rejects is that those shares were from work that has been <i>sitting in the queue</i> for <b>long periods of time</b>(>1 min). Some pools "<i><b>forget</b></i>" about assigned work after very short time periods (1 minute for example) and any results returned based on that work are rejected as unknown...</p>
</blockquote>

<p>It sounds like a pool ignores submitted shares that's over a 1 min even if no new blocks were solved in that time. The submitted share clearly shouldn't be considered stale yet so why would a pool do this?</p>

<mining-pools><phoenix>
Under what circumstances would a server submit new work to a miner?
greatwolf
# Under what circumstances would a server submit new work to a miner?

(Asked by: username_0 on 2012-03-31)

This is asked in a context to better understand why a submitted share by a miner might be rejected.

I know when a new block gets solved that would require a work update, which is approximately every 10 mins on average. Are there any other circumstances where miners in a pool would get new work from the pool server?

I'm mainly asking this question to better understand the explanation given [here](https://bitcointalk.org/index.php?topic=60507.msg706083#msg706083):

> The cause of this problem is low overall hashrate. Phoenix maintains a work queue to reduce hashrate disruptions caused by momentary connection problems. This works great on faster hardware like the ATI 5870, but it can cause issues with miners that get <100 Mhash or so. The reason for "unknown-work" rejects is that those shares were from work that has been *sitting in the queue* for **long periods of time**(>1 min). Some pools "***forget***" about assigned work after very short time periods (1 minute for example) and any results returned based on that work are rejected as unknown...

It sounds like a pool ignores submitted shares that's over a 1 min even if no new blocks were solved in that time. The submitted share clearly shouldn't be considered stale yet so why would a pool do this?

**Tags:** mining-pools, phoenix


---

## 1 answers

### Answer by username_1 on 2012-03-31. Score: 3

The problem you are describing could be due to pool optimisation, as it is easier to prune 1 minute old shares than probably it is to look through 10 minutes of shares in order to validate them.

As for why a miner would request new work from a pool, other than as a result of longpolling or finishing a work, might be due to the work becoming invalid with time (with standard protocol a miner would request work every second). Alternatively, the miner is trying to be malicious and trying to make the pool do extra work.


---

