Topic: [ANN][SRC] Securecoin | A Fast and Secure Version of Bitcoin | 2013 - page 24. (Read 195277 times)

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 software i built myself using the python quark module along with tenebrix pushpool. Which i admit is possible to contain bugs, Python is far from my preffered language VB.Net Is

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/b1af442712ee82fe9764df3812d134a99e11e3f2

I 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.

---

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.

in quark.c
change
to

profit))

well tbqh i dont plan on touching the pool. I am retiring pushpool and moving to stratum which does not have that problem. Until then everyone is free to use the modified miner it doesnt affect me. I have someone with 150+ machines joining the pool tomorrow and will recommend him to use the modified miner to keep things equal for everyone until then

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.

^there is no problem if the hashes are valid and they are submitted. Spoetnik isnt the only one who's stated that. MeshGreed who created another miner stated the same. He recieved a 75% speed increase on my pool with his miner so i dont believe theres much wrong?

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.

you definitly havent demonstrated how to solve the problem. It has 0 to do with the terms

Here is the demonstration of the code : https://forum.litecoin.net/index.php?topic=4002.0

I dont think i can fix it in pushpool and im not willing to fix pushpool. My time would be much better spent completing the coding of stratum which ill share with erundook when im finished

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.

you dont understand how the pool code works so lets just leave it at that. youre last post is completely irrelevent since thats the share diff not the target diff

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

^okay i cant argue with that but even still you're wrong a higher diff wont solve anything its the minimum target diff which will need to be changed

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.

Just to point out. the block stats page on my pool proves he is finding blocks which just goes to show youre argument doesnt match: http://src.crypto-expert.com/

And here is the reason why the pools show the wrong hashrate. it is a fault in the quarkcoin/securecoin code. Basically the way difficulty/hashrates are calculated there mean they are not equivelent to the btc/ltc equivelent difficulty. To obtain the correct hashrate for miners the difficulty must be / by 256 which should bring up the actual hashrate of the miners. Now that is the different between my and erundook and feeleep's pool.

i've been away from this thread but ill give my input. the possability of my code being somehow different to coinex is absurd. we both share the same pushpool code. Proof i hear you ask? check github.com/ahmedbodi the repo is called pushpool and the branch is called securecoin. You will see erundook pushed a compiling fix to my code so he can use it. There is 0 difference between either code. Secondly. i gave spoetnik permission to use the miner on my pool and afaik he isnt submitting shares any lower than anyone. Thirdly give me a day or 2 to finish my coding of stratum and i will release the code spoetnik sent me after inspecting it. So these rants should be stopped. As simple as that

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.

Eliot i done with with you.. and stop asking for my magical cheating client AND bitching about me please..

and before you guys crucify me how about we get the other guys finding blocks over here and ask them what the hell THEY are using ?

If it is saying i am doing 5 Mega hashes a second at CoinEX and i am actually doing 220 on my miner then how slow is those other guys going ?

how on earth does some guy mining that slowly get blocks that much ?

all i know is that pool has massive issues and no way to see any stats basically and it times-out a lot and i have seen people report this that are not using my miner..

i notice after this topic drama i was penalized on the pool and went from getting 1.x amount of coins to 0.6 doing under the same circumstances
so i am fairly sure simply out of paranoia and a couple people that don't like me got me screwed over.. congrats Trolls lol

Andi love all the expert analysis by people who know nothing what so ever about coding and have not looked at the miner source code
and when it was offered refused and yet i am penalized flamed and trolled etc.

want to analyze ? what ? that picture ? going to ask me what i was running ? or guess ? lol gimme a break
i have dissected all code bases and built them all so yeah i think i'd know if i was cheating the damn pool.

sorry but you guys are being REALLY dumb.. and screw CoinEX i know damn well they did something, so i won't go back there ever.