x11 abusing happens. really!

[miningpoolhub]

Today I opened givecoin pool. It is x11 algo coin like darkcoin.

See this man.

[deleted image]

It's impossible. One 280x gpu can output about 2MH/s so he is operating 41053 gpus if it's not abusing.

That man used only one worker, and it's submitting difficulty was 1.28 which I had set for highest difficulty value that can't be reached on normal situation.

My pool stat is all messed up by him. [deleted image]

(I locked his account and changed to xxxxxx_locked now)

I ran my pool with latest NOMP which fixed all x11 algo problems. This is real abusing isn't it?

The NOMP doesn't send solution field to DB, and I didn't set log type to "debug" so I have very little logs to trace. I attached share_archive DB data. [file deleted]

I don't have original share DB, since it's cleaned up by cronjob already. share_archive has almost all data except "reason" why our_result is 'N'

This would help analyzing this man's behaviour. This man seems like inputted normal hash but his difficulty increased at some point incredibly.

He frequently got our_result = 'N' value, I think it might the problem of "Low difficulty share". not sure because data is lost. Maybe exploit lies on precision problem, x11 uses very low difficulty values and some difficulty checking logic might not handle it properly.

I think this man used real machine, since he found 22 blocks out of 94. Actually he had to find more blocks about 99% because his hashrate is so big. It was almost net hash!

I am sure he mined at good manner at first, but changed difficulty value at some point, and this ridiculous thing happened.

I'm tired of abusing things. I think there is some exploit in NOMP but don't know how.

[miningpoolhub]

Now this man signed up again after I blocked him. This man created similar id, used similar email as before. I blocked him and closed pool sign up. It's really abusing man. I'm 100% sure.

[miningpoolhub]

I found another user using same exploit I think. This is DB data from shares table. Now it has reason field. [file deleted]

This man also inserted lots of hash and found very little block. They inserts about 10~100 times than normal expected share.

I see some "low difficulty share" reason field data for it. About 1/10 is low difficulty share.

I haven't seen any abusing user on scrypt coins which is based on NOMP. Well my scrypt coins are not big pools but I think this exploit seems only specific to x11 algo.

Oh, I also had set "shareVariancePercent" as 0 of course.

[zone117x]

Can you turn on debug logging and tell me the output for his shares? It logs the real share diff so that will show exactly what we need to know to fix this.

[miningpoolhub]

I turned on debug logging but couldn't see the actual share on log. logger.debug(logSystem, logComponent, logSubCat, 'Share accepted at diff ' + data.difficulty + ' with diff ' + data.shareDiff + ' by ' + data.worker + ' [' + data.ip + ']' ); It's not logging share data. Is it changed? I'm not sure but I think I saw share data before.

Anyway, good news is that I could reproduce the problem by myself.

I contacted abusing users by email and they told me that they don't know what they did, just ran miner from the givecoin dev.

Yes, this weird thing happened on miner that givecoin dev team released. http://public.bomijoa.com/miner.zip

I could reproduce same thing, many HW error occured but anyway it's difficulty value raised rapidly. I think there's some bug in NOMP.

(I deleted image and DB data on original post since they were actually innocent people)

[miningpoolhub]

I logged some hash data and traced but couldn't get the NOMP to run right. About 6~7.3% of shares are found as "low difficulty share" but other shares are submitted as normal hash. This miner putting hash is not an easy bug to fix on my own I think.

(I also had set banning option to block false hash percentage more than 5% but doesn't seem to run right too. It blocks about some seconds but miner runs again. Maybe because of cluster option? It seems to connect to other cluster process and submit again I think)

I could get the miner source code from givecoin dev. Please contact me if you need this. info@miningpoolhub.com

[miningpoolhub]

Any idea?

I tested with givecoin miner and their shareDiff value in jobManager.js was showing 0 ~ 3. Yeah, at number 0, we got low difficulty share.

With phm-sgminer, shareDiff value was much higher like 1237, 578, 548, 1354.

As I calculated the sgminer's diff shown on console (like 0.01) and shareDiff (like 578), every shareDiff value was multiplied by 62035, 61641, 62769, 60921, 62800, 62400 on sgminer's diff. The sgminer reported value is not an actual number, I heard that it's truncated to nearest number by precision problem.

It seems like number related to 65536, isn't it? I think every logic is well maintained in NOMP, but changing some value a bit would fix this.

I could find some articles saying 65536 (2^16) is some special constant value in scrypt coins calculating difficulty. https://bitcointalk.org/index.php?topic=169916.0 Maybe darkcoin needs some sort of additional calculation like this too.

I started to study difficulty, target, things like that but I don't understand it clearly right now. Sorry that I'm just guessing the problem, just leaving some info I found.

[miningpoolhub]

I also could find that maxcoin (keccak) shareDiff value was multiplied by 256 from what cgminer says. scrypt coin was very similar from the miner saying. (Just within the offset of shareVariancePercent)

I think each coin algo needs to be tested by miner's real input. Please leave some ideas or info, or explain me if I'm wrong.

[miningpoolhub]

I could filter false hashes by dividing shareDiff by 65536 for Darkcoin. (I didn't divide the maxDifficulty value directly because bignum doesn't seem to handle float point numbers)

By seeking 65536 (or 65535, 0x0000ffff) and some constants, I could find that darkcoin miner uses this constant value. I think NOMP just focused on coin source to get appropriate diff1 but already published miners are translating difficulty values with their own values. This is the core problem I think. It's not the NOMP's fault or bug.

https://github.com/prettyhatemachine/sph-sgminer/commit/9585d2a8e6a141d2495fd99af2942e6262b8b272#diff-ccb83336fe4e8722c874e79c5c4c4dddR2958 Line 144 : static const uint32_t diff1targ = 0x0000ffff;

Yes, I also could find more 65536 constant values for scrypt algo in source code.

So I think, NOMP need to adjust diff1 values or multiply other division values per algo at checking point to match with miner's shareDiff. We can't change all miner programs at this moment but NOMP need to communicate diff value they defined. so this will be the realistic solution.

Please leave some info if I'm wrong.

[zone117x]

Good research miningpoolhub. I believe you are correct - NOMP, for the most part, treats every algorithm equally. For each algo we use the diff found in source code for the coin. Unfortunately coin-devs, stratum-server devs, and mining-app devs never work together or communicate so they all make different decisions pertaining to how to treat a new algorithm. For example, MPOS requires x11 shares to be multiplied by 256. Perhaps some mining apps do similar things.

At some point I will do some more testing/research on this issue and see what needs to be modified in NOMP to solve this issue. I recently spent a lot of time focuses on supporting new algos, and now I've switchinged focus to other core features of NOMP. Eventually I'll come back around to work on these algo issues but I can't say when.

Please let me know if you come to any solid conclusions on exactly what needs to be modified in NOMP to fix this issue - I can implement the fix easily in the code if I knew what the exact problem was - but I don't have time to spend debugging it right now.

[zone117x]

I did some major changes to how diff is handled for the various algorithms. It looks like before x11 low-diff share abuses were possible. With the latest update it should be fixed