Quote

(BTW: if "entry.reason == null && entry.ourResult" evaluates to true, is it safe to assume that this share is valid and should be counted for rewards?).

Yes that should be a safe assumption except for the bug you pointed out

... Actually the check should just be entry.ourResult. Currently reason is left null for a valid share and I can see no reason why it would change but it's possible in future the reason field may be used for some sort of meta data. entry.ourResult is intended to be guaranteed to reflect share valid/invalid from the pool's perspective.

Quote from: gentakin on August 18, 2011, 11:23:42 AM

So when phoenix finds a share, it takes the nonce and submits it, but then increases the nonce by 1 and submits that "share" as well, and then continues until it has reached nonce+20.

I actually find 20 shares in my table when only one should be valid, and they all have "our_result == 1".
Maybe the problem is with Res.getEasyDifficultyTargetAsInteger()?

Thanks for the report. I'm a bit befuddled to be honest since the validation code hashes the solution before checking. Any chance you could send me the modded phoenix file? And let me know what version? Or if you can tell me the version jand which file it's in if the code you quoted is verbatim.

You didn't happen to have useEasiestDifficulty=true in your properties file did you? If so could you set it false and test again? useEasiestDifficulty sets difficult so only 2 hashes are required on avg to get a solution. It's intended for load testing only and should have been set false in the sample properties file but as with the license I forgot to update Wink

I think for next version I might change the property to useRidiculouslyEasyTargetButDontIfThisIsARealPool so it's more obvious that's it's not the same thing as rewritedifficulty in pushpool.