Quote from: Lem on February 24, 2013, 12:48:22 PM

Quote from: ckolivas on February 24, 2013, 12:36:38 PM

Quote from: Lem on February 24, 2013, 12:31:58 PM

Sounds to me like a HHTT stratum implementation issue rather than anything else.

Thanks for your quick reply.

Sorry to bother you. Since I don't know anything about the protocol and about your code, let me know whether I understand correctly (so I will contact HHTT and I will be able to explain better the issue): that nonce isn't real, is it? Cgminer never found it and never sent it: it is faked by HHTT.
Otherwise I don't understand why cgminer didn't log it.

Thanks again.

Stratum always starts at diff 1, even if you have asked for a different diff. So cgminer starts sending diff 1 shares until it is told to change diffs, and even then, if there are any shares that it has already found, it still submits them. The stratum protocol specifies that these should be valid shares and accepted if submitted with the original work item. Now cgminer does NOT log shares submitted at the time they're submitted, unless you're in verbose mode. It only shows the response from pool when it accepts or rejects the share submitted. Otherwise it would have to show them twice. Instead it keeps a database of shares submitted and waits till it gets a response before saying accepted or rejected. If the share has been submitted, and the pool never responds to it, you will never see any record of it. If a connection is dropped, cgminer discards all recollection of old shares submitted and considers them lost, because most of those shares will be lost somewhere in networking, and the pool will not accept shares from old connections until stratum develops a robust resume mechanism (which I'm trying to push forward at the moment). If any shares come back from the old connection as accepted or rejected, cgminer will call them "untracked shares" because it will have discarded any record of them.