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

Less focus on infighting and more focus on moving SRC forward?

Now you are requesting 1, but accepting 1/65536.
I'll shut up now.

yes now i am.

But you are accepting shares at 16/65536

im pretty sure i set that purposely. i do know what i am doing you know

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://bitcointalksearch.org/topic/m.3036951), 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.

interesting and wow i want to reply to everything said lol

first off happy Cheating Eliot ..hypocrite lol

i spent time debugging this last night and have tried out ALL the code and all the tweaks so i understand every comment here
except the ones regarding the pools.. and its obvious who i would agree with

murraypaul i don't know why you are claiming to be an authority on this by doing some half ass after the fact checking of random code
you could of simply asked me.. anything as i have said 4 times now..
and your assertion that "everybody" is running the same slow client is unproven and almost certainly false and that is the basis of your cheating argument..

and that comment by ig0tik3d  saying "profit" is an excerpt of a code fix that KILLER stated ALL people should patch their clients with
and i asked more than once about it in the Quark ANN topic and was ignored (his diff patch was posted 1 page after the v2 QRK miner was posted for win64)
and NOW you guys catch on months later after many of you have been raping quark with it and have some cheating bullshit for me and only me LOLOLOL

and murraypaul you are sooo wrong when you said there is no difference in hash speed between Stoenfoz's version vs Neisklar's
i have compared hashing using same difficulty settings and UncleBob's old git hub code he updated over a month ago is WAAAAY faster
it also has issues compiling and i said that ALSO numerous times once again on the Quark topic and got little reply if any..

I didn't do squat.. i have done nothing but try and learn this crap and help out and i have been unjustly screwed over big time !
So where are the people screaming cheater for the XPM HP series of miners ? same situation different people using different miners..
did you guys go and call that guy who made it a scammer or something ? of course not lol

murraypaul  your making dumb excuses to call me a cheater

Just a quick tip:
I wrote something down about cost efficient cloud mining, check it out if interested:

https://bitcointalksearch.org/topic/cloud-mining-cpu-coins-303122

murraypaul has said everything that needs to be said

youll be happy to hear i can stop being nice to you now

luckily my fee is 0 so i dont lose at all. i've kept it at 0 for a long time since i began to plan out my stratum work

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:) )

Not doing the stratum-diff/65536 thing is the correct way.

IMHO changing the miner is to late, since all miners out there behave over stratum like bitcoin, and the p2pool stratum also behaves like bitcoin.
Having mixed miners out there will lead to massive problems.
BTW that's a thing i'm still a little angry with myself, since i didn't do that when i released the first standalone miners and p2pool software.
But now we have to see it as defacto standard that QRK-based coins behave like Bitcoin-based ones: no diff-adjustment over stratum.

what the difference is i believe is feeleep uses stratum which contains more error checking code in comparison to pushpool which we use atm

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?

Yeah, thats one of it, but there maybe more:

QRKs Difficulty reported from the wallet (and therefore also in all QRK clones if not changed) is "1 Byte off", means on Bitcoin, Litecoin a Difficult=1 Target would need at average 2^32 hashes to be found. In QRK a Difficulty=1 Target needs only 2^24 hashes at average.

This fact is irrelevant when doing solo-mining, since then the target is directly communicated over getwork to the miner and not over the conversation to difficulty.

In the p2pool code i modified for QRK i changed that part as well on the p2pools statistic-frontend.

So it may then be, that in some pushpool or stratumpool implementations these corrections are not made. Especially stratum, which uses Difficulty and not Target.



Another thing to note is, that for scrypt-based coins (AFAIK only over stratum) the real diff is a multiply by 65536. That is then reversed for example by the cpuminer before it calculates the target.
For the quark-miner i did not do that reversing. So when using a litecoin-stratum implementation as base to create a pool to use with QRK-Algo-coins, that may also cause some problems.