Shares are submitted before being committed locally

[zone117x]

It appears that sgminer will submit shares before saving the share locally, and if the stratum server replies fast enough, then sgminer outputs the error:

[09:38:43] Accepted untracked stratum share from (null)

A user of my node-stratum pool sever discovered the issue, see debug and details here: zone117x/node-stratum-pool#9

[veox]

TODO: see git blame/history on this log line as to why it was introduced.

EDIT: 8baac0d

[veox]

To clarify, this is not an error. The message is of log level LOG_NOTICE, and is expected behaviour.

[veox]

There seems to be no memory leak related to the HASH_FIND macro (called by HASH_FIND_INT) used in parse_stratum_response() (that prints this notice), and introducing an artificial delay as proposed in zone117x/node-stratum-pool#9 is an unnecessary regression.

Closing as wontfix.

[zone117x]

Are you saying this is fixed in sgminer? Or that Accepted untracked stratum share from (null) are expected messages that users can expect?

[veox]

The latter. It is OK if the pool software is faster than the miner (which handles mining in high-priority threads, and leaves accounting to the low-priority ones).

This is in fact the case with p2pool setups: between 1 and 10 per cent shares are untracked.

[zone117x]

Alrighty. You know you wouldn't have to delay submitting the shares - when the share submission response comes back from the server you could wait until the share has been tracked/flushed locally before outputting to console.

[veox]

Hmm, that is true. I'm not well-versed in Stratum yet, though.

Reopening as enhancement.

[icook]

I too would like this. The custom stratum server developed for SimpleVert (https://github.com/simplecrypto/powerpool) has this issue and users ask about it often. Adding delays definitely fixes the problem, but seems like a hack.