Hasher

[razorfish-sl]

I suspect that 'hasher.java' should also contain
public boolean meetsTarget(int nonce, Hasher hasher) throws GeneralSecurityException {....}

Specifically because hasher has been threaded and is called from
meetsTarget on each thread for every nonce, therefore it may become reentrant but it has not been synchronized.

Really there should be one nonce check routine for each hasher.

[pooler]

I haven't looked at the code for a long time, but if I remember correctly each thread has its own instance of Hasher.
Why do you think the current meetsTarget method isn't safe, exactly?

[razorfish-sl]

yes correct……..
But not of the resultant hash checker(there is only 1 instance of work), so that would indicate that 'n' threads of hasher are attempting to use 1 instance of a comparison routine, for every single nonce.
by shear luck, the number of threads (since it is a result of the number of CPU), there are no clashes, but if you increase the CPU/threads……..

It may be more astute to move the checking to the hasher and return a simple T/F boolean from 'hasher'
That would of course require the difficulty to be passed in, but would save at least 3 stack calls per nonce in the process, or about 12,884,901,885 stack calls over a full range search……….

On Sep 23, 2013, at 6:09 PM, pooler notifications@github.com wrote:

I haven't looked at the code for a long time, but if I remember correctly each thread has its own instance of Hasher.
Why do you think the current meetsTarget method isn't safe, exactly?

—
Reply to this email directly or view it on GitHub.

[pooler]

It is true that Work.meetsTarget is called concurrently by the threads, but I still cannot see how "clashes" could happen, given that no shared data is being modified.

Regarding the cost of the calls, to me it seems negligible when compared to the time it takes to compute a hash. 13 billion calls is nothing given that it would take 3 days to do a full-range search on a high-end PC. Have you done timings?

[razorfish-sl]

I merely point out potential bugs.. it is not my place to have to justify why I think they should be fixed…..

As regards 'high end pc'…. one word…..'Scaleability'.

You might want to look at the 'atomic' as well…. no under/overflow detection, so if we were to scan a section close to the boundary condition, bad results may be returned.

On Sep 25, 2013, at 4:20 PM, pooler notifications@github.com wrote:

It is true that Work.meetsTarget is called concurrently by the threads, but I still cannot see how "clashes" could happen, given that no shared data is being modified.

Regarding the cost of the calls, to me it seems negligible when compared to the time it takes to compute a hash. 13 billion calls is nothing given that it would take 3 days to do a full-range search on a high-end PC. Have you done timings?

—
Reply to this email directly or view it on GitHub.

[pooler]

Regarding "high-end PC", it was just an example to give an idea of how negligible the cost of a function call is per hash. Such cost is obviously not fixed, so I don't see how scalability could be affected.

I'm not sure which "atomic" you are referring to... the only one I can see is Worker.hashes, and it would take ages for it to overflow even on the fastest hardware.