Tentative block template refresh timeout

[pallas1]

Untested: I have no pool setup to verify it.

[Venthos]

I was connected for over 18 hours straight to a pool node instance running this patch.

CONNECTION REPORT
Pool address    : 69.162.83.202:3333
Connected since : 2018-05-21 19:24:50
Pool ping time  : 56 ms

Network error log:
Yay! No errors.
HASHRATE REPORT - CPU
| ID |    10s |    60s |    15m |
|  0 |   49.6 |   48.2 |   49.3 |
Totals (CPU):    49.6   48.2   49.3 H/s
-----------------------------------------------------------------
Totals (ALL):     49.6   48.2   49.3 H/s
Highest:    81.0 H/s
-----------------------------------------------------------------
RESULT REPORT
Difficulty       : 1860
Good results     : 2550 / 2551 (100.0 %)
Avg result time  : 28.9 sec
Pool-side hashes : 4614826

Top 10 best results found:
|  0 |          3245510 |  1 |          1095595 |
|  2 |           850582 |  3 |           714172 |
|  4 |           639139 |  5 |           522523 |
|  6 |           479195 |  7 |           454593 |
|  8 |           451686 |  9 |           446834 |

Error details:
| Count | Error text                       | Last seen           |
|     1 | Low difficulty share             | 2018-05-21 22:58:33 |

Given that this was with a single core of my CPU and not an entire CPU or GPU, the single "Low difficulty share" is likely legitimate.

I'd like to see another person test this as well, if at all possible. I know ddvs1 was checking it out yesterday. If nobody is able/willing to test beyond this, the next step is production testing to confirm blocks get mined with this change. I'll see where we are tomorrow on this and potentially shift itnspool.net over to this.

[bobbieltd]

What is advantage of refreshing block template (even it is stale) ? Refreshing = same block template ?

[pallas1]

@bobbieltd to update block time and, most importantly, add new transactions from the memory pool.

[bobbieltd]

@pallas1 Thanks for clarification.

[Venthos]

I have taken a slightly modified approach to this which also tackles the duplicated/unnecessary templateUpdate fighting going on between the master and worker processes of pool.js.

I have it in a dev branch right now: https://github.com/Venthos/nodejs-pool/tree/templaterefreshdev

It is currently the live code for all 3 of my pool nodes after performing some extensive hours of testing on a testnet pool. We'll see how it goes. Feel free to pull down the dev branch and test with me.

[Venthos]

To add a bit of clarification to help with testing. There are 3 situations in which you should see a new block template from a miner standpoint.

• A block was mined by the network, causing a new block template
• The templateRefreshTime was met, causing a new block template
• You are using variable difficulty and your miner was determined to need its difficulty adjusted, causing the existing block template to be sent with new job criteria

This can cause the appearance of a "double block template being sent" when the templateRefreshTime coincides with a vardiff update.

[pallas1]

maybe we should apply some sort of locking, to avoid any of the first two conditions race with the third for the new template?

[Venthos]

It's possible, but we'd have to make the logic much more granular per-miner. Just adding locking won't help.

The difficulty change only applies to users connecting via vardiff. Static Difficulty miners never get this logic. Beyond that, not every vardiff miner will have their difficulty adjusted each "diff check" cycle. It only happens if the logic discerns that their diff needs to change.

Further, the difficulty change sends the exact same template but provides new job criteria (a new difficulty target). This is unique per-miner.

Lastly, sending a new block template per #1 or #2 does NOT affect the miner difficulty. This is independently handled by #3. This is why even if it is rapid-fire closer together it does have value in its current form.

Sending this "same template" is not considered a duplicate job by miners since by definition its job details are unique (a new diff target).

Resolving this in a more sane matter would involve a heavier rewrite than simply adding locking. But, I agree, it's less than ideal right now. I would like to get some more testing from folks (has anyone else put this into testing?).

One person has indicated they have gotten a few "Low difficulty share" errors in their miner yesterday, but it's unclear if they were simply legitimately low or due to a bug (I haven't seen the logs yet). I did not experience this in testing.