But you are accepting shares at 16/65536

You are requesting a Bitcoin-style difficulty of 16, that is massively high for an scrypt coin.
You probably mean 0.000244140625 (16/65536)

Question for you about cheating.
I have found a pool that will accept shares at 1/256th the difficulty that it asks for.
Doing so as a test took me from a measly ~240kh/s in accepted shares to over 25Mh/s.
I think it would be cheating to run a miner submitting those low-difficulty shares, as it is clearly exploiting a bug.
Do you agree, or do you think it is fair game?

The builds that were posted in the SRC thread all had the speed limiter in.
The UncleBob repository still has the speed limited code, so anyone building from there will build a speed-limited version.
I think it is reasonable to think that most people were using them.
It also fits in with what people have seen, that they make less SRC when using a pool that allows the lower-diff shares.
Soon after the coin was released I found that I earnt a lot more on the coinmine pool that on crypto-expert (https://bitcointalk.org/index.php?topic=270852.msg3036951#msg3036951), maybe this was the reason?


? I don't think I said that?


I've tried to remember to put 'cheat' in quotes, as here, but have probably forgotten a few times.
A client submitting lower-diff shares is doing exactly what the pool has asked it to do, so is playing fair with the pool.
The problem is that most (I think) people are using a broken client that voluntarily chooses to make life harder for itself.
By using the faster client, you get more shares for the same hashpower.
People using the client they were told to use will probably think that is cheating.

At least one pool is vulnerable to this, and will accept shares 256 times too easy for the requested difficulty.
I have let the pool operator know.
(Being honest is sadly unprofitable:) )

Checking on the coinmine pool, it seems that they already correct for this on their end, so changing the miner to submit shares at difficulty/65536 results in the extra shares being rejected.
(Which means that I need to leave the 'incorrect' code in place, or waste time submiting 99% invalid shares)
I've found at least one pool that doesn't correct for it, which allows the submission of massively more shares than an uncorrected miner.

I had a look at this, and it seems to almost exactly come out in the wash, the overall hashrate (counting only fully computed hashes) stays almost exactly the same if you skip hashes that need the second Groestl function, at least with the UncleBob implementation.
Presumably this means that the performance difference between Groestl and Skein is about the same as the cost of performing Blake plus BMW?

This is the issue.
It is fixed in your repository, but not in the UncleBob one, which most users were pointed to in the SRC thread.

The extra shares will never solve a block, because they are guaranteed to have been sent anyway if they had passed a difficulty 256 check.
Your pool will significantly overstate the sharerate of miners using the modified miner, compared to those using the standard miner.
This means they will take far more of the block reward, leaving very little for the users on the standard miner
Eventually all the users on the standard miner will leave, to go to a pool which doesn't have this issue, and will see their reward significantly increase.
You will be left with only users on the modified client, who are all submitting far too many shares, so the effect will cancel out.
The users with the modified miner will no longer see any advantage, as all they are doing is submitting more shares, not solving more blocks, so they only gain if there are standard miners to leech reward from.
You will be left with a small group of users on the modified miner, and will receive very little from running the pool, as your fee comes from solved blocks, not submitted shares, and these users are not solving blocks faster than users with the normal miner. The increase they are seeing is only in shares submitted, not in blocks found.

Did you not wonder why there are only three users left on your pool (excluding my testing), who (at a guess) are all running the modified miner. [Compared to 305 workers on coinmine, which uses a higher target share diff, and cannot be exploited this way]
A user running the standard miner would be insane to mine with you, as they will not receive a fair share of their effort.

You currently accept shares against this target:
Target: 00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
If instead you accepted shares against this target:
Target: 0000007fff800000000000000000000000000000000000000000000000000000
(Or anything starting with six 0s rather than 5)
The problem would go away.
This is because of the following check in the quark miner code:
        if ( ((hash64[7]&0xFFFFFF00)==0) && fulltest(hash64, ptarget)) {
            *hashes_done = n - first_nonce + 1 - skipped;
         return true;
   }
The standard miner will never submit shares with a hash of less than six starting zeros.

The shares being submitted are completely valid, it is just that the standard miner would never submit them.

I may well be using the wrong terms, but I think I have clearly demonstrated:
a) That a problem exists
b) Why the problem exists
c) How to solve the problem

Your pool accepts shares that meet a lower target than coinmine does.
Your pool accepts shares that meet a target that the standard quark minerd would never submit, as there is a hardcoded lower limit in it.
By removing that limit, I can have your pool accept shares from me that most users would never have submitted.
Those shares will never solve a block, as they are of a very low score (otherwise they would have been submitted by the normal client).
Therefore I get credited with many more shares submitted than normal users, despite not solving any more blocks than normal users.

Yes, that is what I mean.
Try a target of 512/65536 = 0.0078125
(Gives target hash of 0000007fff800000000000000000000000000000000000000000000000000000)

And at what rate is he finding blocks?
One that matches his local hashrate, not the pool hashrate, is my guess.


As I have shown in my earlier post, if I use the standard miner, the pool hashrate matches my local hashrate.
If I use my modified miner, the pool hashrate is many times higher than my local hashrate.
This isn't because of a fault in the coin code, it is because I am submitting many more shares than people with the standard client.
Change your pool difficulty to >= 256, and this effect will go away.

If I am wrong, then setting diff to 512, to match coinmine, will have no effect.
If I am right, it will massively reduce the reported hashrate of users using a modified client, and not change the hashrate of users using the standard one.

You are right, your pool has the same problem as CoinEx.
The coinmine pool does not.
[Edit: There is nothing wrong with the pool coding, it is just that almost all users are using a miner which will never submit shares lower than 256 diff. So if the pool sets a diff lower than that, it allows people to 'cheat', by submitting shares that everyone else has agreed not to.]

Your pool accepts shares with target starting: 0000FFFF
The cpu-miner program is hard-coded, by default when generating quark hashes, not to submit shares with target starting worst than 000000FF.
By removing that hard-coding, your pool will accept extra shares, which cannot solve blocks, and which would never be submitted by users with the standard miner.

Here is 1 minute of mining on your pool with the limit in place:

$ ./minerd.exe -R 5 -t 1 -a quark -o http://stratum.crypto-expert.com:7103 -u murraypaul.1 -p x
[2013-09-26 12:37:06] 1 miner threads started, using 'quark' algorithm.
[2013-09-26 12:37:06] Long-polling activated for http://stratum.crypto-expert.com:7103/LP
[2013-09-26 12:37:32] thread 0: 2097152 hashes, 81.64 khash/s
[2013-09-26 12:38:06] thread 0: 2775688 hashes, 81.99 khash/s

Here is 1 minute of mining on your pool with the limit removed:

$ ./minerd.exe -R 5 -t 1 -a quark -o http://stratum.crypto-expert.com:7103 -u murraypaul.1 -p x
[2013-09-26 12:35:13] 1 miner threads started, using 'quark' algorithm.
[2013-09-26 12:35:14] Long-polling activated for http://stratum.crypto-expert.com:7103/LP
[2013-09-26 12:35:20] thread 0: 491362 hashes, 82.47 khash/s
[2013-09-26 12:35:20] accepted: 1/1 (100.00%), 82.47 khash/s (yay!!!)
[2013-09-26 12:35:26] thread 0: 522738 hashes, 82.03 khash/s
[2013-09-26 12:35:26] accepted: 2/2 (100.00%), 82.03 khash/s (yay!!!)
[2013-09-26 12:35:33] thread 0: 530008 hashes, 83.75 khash/s
[2013-09-26 12:35:33] accepted: 3/3 (100.00%), 83.75 khash/s (yay!!!)
[2013-09-26 12:35:37] thread 0: 375004 hashes, 78.27 khash/s
[2013-09-26 12:35:38] accepted: 4/4 (100.00%), 78.27 khash/s (yay!!!)
[2013-09-26 12:35:38] thread 0: 66187 hashes, 82.94 khash/s
[2013-09-26 12:35:38] accepted: 5/5 (100.00%), 82.94 khash/s (yay!!!)
[2013-09-26 12:35:49] thread 0: 897888 hashes, 79.09 khash/s
[2013-09-26 12:35:50] accepted: 6/6 (100.00%), 79.09 khash/s (yay!!!)
[2013-09-26 12:36:09] LONGPOLL detected new block
[2013-09-26 12:36:09] thread 0: 1656698 hashes, 83.30 khash/s
[2013-09-26 12:36:11] thread 0: 139319 hashes, 81.80 khash/s
[2013-09-26 12:36:11] accepted: 7/7 (100.00%), 81.80 khash/s (yay!!!)


Same hashrate, and no shares accepts vs 7 shares accepted.
If you think 1 minute is too short a sample period, I can run for as long as you like to demonstrate that the results are reproducible.

You are cheating the pool. (Although it is the pool's fault for allowing itself to be cheated)
You are submitting lower diff shares than any other pool user, thus getting more reward but not solving any more blocks.

I suspect I have worked out why, or at least I have reproduced the problem.
The coinmine pool asks for diff 512 shares. (0.0078125)
The coinex pool asks for diff 16 shares.
However, there is a built-in throttle in the quark miner which prevents it from submitting shares at < diff 256.
If this throttle is removed, you will be able to submit significantly more shares than with it present, but those shares are guaranteed not to be able to find a block, as they are known to be less than diff 256.
 
This explains all the observed behaviour:
a) Local hashrate does not change, you are not generating any more hashes, just submitting lower difficulty ones that were previously thrown away
b) Pool hashrate does change, as you are submitting many more shares
c) Found blocks do not increase, as these extra shares are guaranteed not to be able to find any blocks, as we know they are less than diff 256
d) Incoming from pool does increase, as your sharerate is much much higher than any other user's, so you 'steal' block reward from them

The solution is for the CoinEx pool operator to increase the pool difficulty to at least 256, which will prevent the modified client submitting shares that the original clients will not.

Edit: As a very brief test, I ran my modified client against the CoinEx pool, and my local hashrate of ~240Kh/s shows up as ~2.6Mh/s and made my lowly laptop briefly the highest hashrate on the pool. I expect that if left to run long enough, it would settle down to 3.84Mh/s, minus what is lost to rejects.

I created an account on the QRK pool, and everything seemed to be working fine until I got a confirmation email, and clicked on the link in it to confirm my account.
I then got a message saying invalid token, and my account is now locked.
Account name is murraypaul, could you unlock it please.

That seems broadly in line with about 1Mh/s-1.25Mh/s, or a little bit more?
I've been getting a bit less than 5 SRC a day with about 240kh/s [on coinmine]

Ah, someone coherent to talk to
At least on CoinEx, the shares don't seem to be leading to blocks, otherwise you would surely have expected one of you to have found one of the last 15 blocks, as you had [a very large percentage] of the pool hashrate?
I suspect that the shares generated are invalid in a way that passes the pool's checks, but fail to generate blocks.

But faster there means generating more hashes per second.
That is what the incrementally better releases in the QRK thread were doing.
What you have posted is something generating more shares with exactly the same hashrate, that is very different.


Perhaps that is because you are generating invalid shares, which cannot solve a block?