I only did a quick read through, and to lazy to do proper quiotation.
First let's make on thing clear:
The fault always lies in buggy server code.
It is always the pools and the deamons task to validate all hashes, validating thats above the needed target, and also validating that the hash is correctly calculated.
So even if the miner reports back shares under the target of what they should, then it is the pools task to sort them out.
It is even regardless of crytocurrency topic ALWAYS the servers task to validate ALL input, NEVER the clients task.
So just so we don't get a misunderstanding:
Of course one could build a miner which tries to cheat, but IF the server part is correct that try will be unsuccesful.
If someone honest got screwed by cheating miners, then he must blame the pools operator, not the cheater, since that's what the task of an pool operator is esp. when taking fees, provide a working system, monitor it, take action when needed.
That's also why you should not just do copy and paste without understanding of what exactly you are copying and how it is working.
---
Yes, the first released quark minerd had (accidently) a hard coded filter in it.
Two days later this was fixed in the repo:
https://github.com/Neisklar/quarkcoin-cpuminer/commit/b1af442712ee82fe9764df3812d134a99e11e3f2I did not produce new binaries, since at at the time the diff for QRK was already so high, that i never thought about the need for diffs lower than 0.0039. I also didn't really thinked about the need in pools. And pools share diff can be adjusted by the pools operator.
Then there are some optimized miners, which others created, which just use more efficient implemtations of the hashing algorithms, and use the old code as base, and never merged the fixes in their branch.
As SRC (as a 1:1 clone of the QRC source/algo) came up, mostly all just used the available tools, without really looking what they are doing and how they are working.
Also in opposite to windows users, linux user mostly get a checkout from the git repo and compile themselves, so they also get the updated code.
So if someone used a minerd without that filter, on a pool with a target that low, he did not cheat, the pool op didn't set up the pool correctly and/or did not provide the right miner software for their miners.
The
corrected code is already over a month in the repo, no one has a "secret advantage" or did cheat, it's all open and accessible for everyone.
So again: It is not a modified or tweaked miner, it's just the fixed miner, the other ones are just buggy miners.
In addition, that miner did not use a hole or bug, it worked like it should. The user could even NOT detect this error, since for him the reported hashrate by the minerd and the hashrate reported from the pool was correct.
---
toying with a miner you can get some accepted shares 50% of the time by dropping half the algo work
which is proof that all algos are not used at all times..
It's not really dropping half of the algo work, it's more like that the different hashing algos have different costs in terms of cpu power. Some are blazing fast, some need some heavy work from the cpu (maybe even 10 times more). When you are at the branch point, and see that you will go the heavy computation road, then it
may be quicker to throw that try away, and do the next one, instead of calculating that one. (Didn't test and avaluate that at all, it's just an assumtion and depends on the used algo-implementations)
So in opposite to the sha256 stuff where each hash try needs roughly the exact same amount of time, the time for a complete quark-hash vary.
