claymore v11...

[PeshBG]

It is not working with v11

[Demion]

It is working with Claymore v11.0.

https://i.imgur.com/P59wCCz.png https://i.imgur.com/HrmrC6C.png

s = 0x02C8 flags = 0x0000 len =  148 buf = 7B 22 77 6F 72 6B 65 72 22 3A 20 22 65 74 68 31 2E 30 22 2C 20 22 6A 73 6F 6E 72 70 63 22 3A 20 22 32 2E 30 22 2C 20 22 70 61 72 61 6D 73 22 3A 20 5B 22 30 78 63 62 34 65 66 66 64 65 62 34 36 34 37 39 63 61 61 30 66 65 66 35 66 35 65 33 35 36 39 65 34 38 35 32 66 37 35 33 61 32 2E 77 6F 72 6B 65 72 31 22 2C 20 22 78 22 5D 2C 20 22 69 64 22 3A 20 32 2C 20 22 6D 65 74 68 6F 64 22 3A 20 22 65 74 68 5F 73 75 62 6D 69 74 4C 6F 67 69 6E 22 7D 0A 
{"worker": "eth1.0", "jsonrpc": "2.0", "params": ["0xcb4effdeb46479caa0fef5f5e3569e4852f753a2.worker1", "x"], "id": 2, "method": "eth_submitLogin"}

Although, actual mining efficiency you need to test by yourself.

Users report some actual efficiency decrease starting from version 10.1 and later (might be some hidden protection). Seems to work fine on 9.7 and ethermine for me.

For further troubleshooting upload your Claymore Log and nodevfeeLog.txt.

[babbage2018]

nodevfeeLog.txt работает Журнал Claymore был отключен, сейчас включу завтра загружу 14 февраля 2018 года в Claymore увидел как Devfee получил 2 шара, на пуле появился только один. (логи были выключены). Продолжаю смотреть

[br1egel]

well done, are you able to look in to the claymore.exe v11 ? I deobfuscated this https://bitcointalk.org/index.php?topic=2274616.0 hack. the guy did a different approach and used kernel32.dll to actually write the registers used in claymores version 10.0 by ReadProcessMemory and WriteProcessMemory. Unfortunately, the guy that wrote the hack also incorporated his wallet address. dll was gzipped and obfuscated with .net reactor 5.0. After a lot of debugging the claymore version 11, I found some addresses in memory which are storing the wallet and dev addresses. Nevertheless, is doesn't work quite right. I could upload the deobfuscated dll because the mentioned approach has a lot less code involved. Overall, I am not against a developer fee, but what this claymore is doing ( after debugging through his code) I don't like his statement of 1% dev which is actually far more - who else needs as one person around 500k $ per month for developing a cli program.... Just a hint for everybody : debug by x64odg with SycllaHide. You can search for the address in x64 by "ethdcrminer64:base + 0x9B29D". Kind Regards

[br1egel]

P.S: https://github.com/ethereum-mining/ethminer has a new release. for r9 390 till rx580 one can use parameters: --cl-kernel 1 --cl-local-work 256 --cl-global-work 18432 --cl-parallel-hash 2 vega a running quite nice around --cl-kernel 1 --cl-local-work 128 --cl-global-work 18432 --cl-parallel-hash 4 & --cl-kernel 1 --cl-local-work 256 --cl-global-work 65536 --cl-parallel-hash 4 global work size 65536 could be too big. Just wanted to mention ethminer, unless the dual mining and the gui is needed ...

[rzrwolf]

I had 24 hrs run with nofee on claymore 11 and it seems his protection works, as on 146mhs rig i got average of 136mhs on poolside. With nodevfee and v10 i get abt 144

Used as nodevfee.exe ethdcrminer64.exe and so on..

[rzrwolf]

nodevfeeLog.txt

Here is nodevfeelog.txt i got so far. I have default worker on pool side, however it seems claymore drops hashrate as with -nofee option..

[br1egel]

same on my side, seems that hashrate is decreased. I have attached the dll (ClaymoreLib.zip) that had worked for v10 (be aware that I changed several int to work with v11). In x64 dbg two wallet addr's (mine and claymores) are on the stack but referenced this time not in the same memory map of the program itself. I assume that he maybe delegates the saves to another program ? (just wild guesses - offsets could be 789024d or 722416d)

[Demion]

Maybe your devfee is mining to different pool, you can try pool redirection nodevfeePools.txt I see diffrent connections in log:

sin_addr = 149.202.57.197 sin_port = 9999
sin_addr = 149.202.57.197 sin_port = 9999
sin_addr = 79.137.82.104 sin_port = 9999 
sin_addr = 79.137.82.104 sin_port = 9999
sin_addr = 149.202.57.197 sin_port = 9999
sin_addr = 79.137.82.104 sin_port = 9999
sin_addr = 164.132.108.171 sin_port = 9999
sin_addr = 164.132.108.171 sin_port = 9999
sin_addr = 185.71.66.38 sin_port = 9999
sin_addr = 79.137.82.70 sin_port = 9999
sin_addr = 92.222.180.118 sin_port = 9999
sin_addr = 92.222.72.197 sin_port = 9999
sin_addr = 213.32.74.230 sin_port = 9999
sin_addr = 149.202.57.197 sin_port = 9999

Maybe it is just mirrors of same pool (same host name). To be sure need to check bat / settings, nodevfeePools.txt settings (if used).

Claymore might have some hidden protection algorithms, I am no much expert in reverse engineering, for now I am still on 9.7 version.

I can say though that claymore has a lot of different wallets and it changes from version to version. Simple memory patch at offset might not help.

[br1egel]

I think you did not understand me correctly : I am talking about the registers he passes to the function eth_submit work. That means, that it doesnt really matter what addresses he uses for his devfee, you just replace that memory content with another wallet address. I hoped that someone with a bit more reverse engineering skills could colaborate with me to get the right location. Nonetheless, I am back to ethminer - high avg hashrate with less stale share.

[Demion]

I understand what you mean, but my approach is similar in some way, have you looked at code? It does hook (intercept) winsock2 (ws2_32.dll) win32 api and in send function replace their devfee wallet to your wallet. What makes you think if you patch that wallet in some other memory buffer or registry it will not get detected. Anyway good luck with that, feel free to share results here, would be intersting to see.

By the way if there is check for buffer integrity we can try use copy of buffer and leave original buffer unmodified or after packet sent just replace wallet back. Also splicing is current hook method, can try more advanced hook method (without memory modification) using hardware debug breakpoints (int 1) and exception handler.

If anyone interested you can test update, that uses buffer copy, instead of modification. Just remember it may be unstable and you need to test for quite time (12-24 hours the least in my opinion), otherwise there are a lot of variables that can affect actual hashrate.

NoDevFee_v0.2.6a_x64.zip

[kirillp]

Я тоже самое делаю, копию буфера в своей ветке, я добавляю worker если его нет и заменяю точки в воркере т.к мой пул иначе некорректно работает.

I do the same in my branch, I make a copy of buffer in case I need to add worker (if not defined). Also I replace '.' in worker names. This is required on my pool (etherdig.net)

[br1egel]

alright, will look after that new code and try it. I found another approach, because I wanted to do the hack more at the origin instead of doing 'it' almost at the end, when alternating the submit. link removed . That guy seems to have extracted a libeth.dll. Looks like claymore used virtualproctect to save his memory against access from outside. been testing this, hopefully the devfee function will never be called anymore -> that would be the best of all case

[Demion]

I would not advise using d3z00r version.

1. EthDcrMiner64.exe is unmodified.
2. Only file seems to be modified is libcurl.dll (which is C http library).
3. According to hex editor and PE tools app it has IAT (import address table) modified so that it load (inject)libeth.dll.
4. I havent looked libeth.dll in details, but I believe it is 3rd party dll, not extracted from somewhere cause EthDcrMiner64.exe is unmodified and libcurl.dll has just libeth.dll inserted in IAT at end.
5. Most important in hex editor I found wallet 0x0b374e2f03dDe62aBdC7D28a9efa2081a93974aA https://ethermine.org/miners/0b374e2f03dDe62aBdC7D28a9efa2081a93974aA

So I believe it can be malicious, I remove link for now. If anyone want to test then search for author name.

[br1egel]

well could be, but all I saw was that there was a 0x21000 address offset to the original ethdcrminer.exe and that in libeth.dll they were 2 methods only exported. the start method just returns zero. anyway, back to debugging :D I liked the idea of dual mining keccak algos... I will try your new approach. Moreover, you are submitting the sources, which is far more trustful.

[dugyitla]

i often get eth authorization failed whenever i start/restart claymore using 0.2.6a

ill observe for 24hrs. those who are testing, please report back as well. thanks

[dugyitla]

i hope you guys can make nodevfee efficient for 10.3 above. cant really use pre 10.3 because adrenalin is not supported with pre 10.3, thus cant oc, control fan, etc. and i have stability issues pre 10.3

[kirillp]

it is very efficient for me for 10.6

[br1egel]

Hi, seems to work. much lower stale rate in contrast to original claymore version 11. seems like claymore is still submitting the same share for his own devfee.... As hardworker01 already mentioned I sometimes get a json with unkown response (mining.notify etc.) After some restarts of the miner it works normally.

[br1egel]

Don't have the time now, but could be interesting to compare each binary versions (snowman). Maybe one gets a better idea of what claymore changes from exe to exe and isolate the devfee and/or dual mining part (keccak, blake2s).

[TheWhiteGoblin]

Just wanted to drop in and leave my experiences for everybody. First off, thank you very much for your time working on this Demion, I really appreciate your open approach here. I've been testing your various releases for the last few weeks across some of my equipment including using the different versions of Claymore's software.

What I've found is the previous versions (v0.2.5b and down) produced very unstable hash rates inside 10.5, 10.6, & 11.0. (it's important to note: i've only ran tests so far while dual mining pascal lite & verge) To clarify this for others, what I mean by this statement, is my actual hash rates no matter of equipment, would rarely if ever match my reported hash rates. They would operate quite a bit below average, noticeably beyond the normal ups and downs expected throughout the process.

I always noticed the highest hash rates right after starting the program, but it would always die off quickly. You could restart the program to try and always keep the first few normal looking peaks/vally ratios but whenever you let it just work away you'd come back to having under performance issues. Almost as if, a delayed security check somewhere along the line kicked in & down with the hash rates it went after it noticed something afoul.

Though with the v0.2.6a build you posted for us to try utilizing buffer copy instead of modification everything is working at their reported hash rates or damn near it, hell sometimes over it. (aka: much closer to normal operation) I keep tweaking things myself which is not giving me the long term graphs I'd like to take screenshots of for reporting back here. Though once I get a decent screenie or two captured where they've had time to just run on their own for long(er) periods of time I'll return here to post about it.

This leads me to believe you're clearly onto something with this new technique. I wish I could help more but I'm not a skilled programmer. I'm benching your versions across my test rigs including; 13x 1080Ti FTW3 Hybrids, 4x MSI Wave Vega 64s, a Waterforce 1080, & a Titan Xp with it's own custom EKWB loop. They all regarding of manufacturer, driver version, clocks, currency being mined, or basically any setting universally like the v0.2.6a version better reporting more stable hash rates. I'm currently testing on Claymore's newest release (11.0), it would be great if other's could let us know their results as well.

These machines are running in Windows 10 Pro, latest builds released off the stable branch. They might throw a single rejected share a week and are generally rock solid. I notice the only times they tend to reject is when I'm personally testing on the machines as I'm taking resources away, turning monitors on and off, changing clocks, etc. When left alone they're good to go, this means they never throw the restart flags, which means I haven't had a situation come up where I could even test the restart.bat functionality.

I do have it in there though as per your instructions file. So others can follow along I'm also including the nodevfeePools file, though I'm not using the nodevfeeWallet file. I'm on ethermine.org as my primary pool. I always delete the older preexisting log files before starting the miner again, though I have no reason to believe this does anything at all. (more just ocd about keeping a clean house so to speak) I've also, once again for no reason at all other then cheeky superstition, changed the name of the nodevfee.exe to hashishalldayallnight.exe and call it in the .bat file instead.

Not to go on a bicycle ride here but my thinking went back to cheating / hacking early MMORPG launches. In a couple Korean titles the botting and exploit software needed to be launched with completely randomized names and other identifying marks. There was a couple great bans that happen simply because they scanned for the same process names, process guards, etc.

Given there's been multiple versions of Claymore's releases since this has been around, I assumed at some point he would integrate some basic checks, at the very least, to see if nodevfee.exe or say even nodevfeeDll.dll where present in the miners launch location. Something to that overall effect anyways, I'd actually think he would integrate a system much more complicated then that, though once again, I'm not really a programmer.

I don't know if any of this information helps, I sure hope it does though. Good luck to everybody out there and of course, I'll be around watching! /shaka

[Demion]

Thanks for testing, great report.

I created small test update so that you can change not only exe name but also dll name. Names of exe and dll can be anything but must match though. For instance you can rename it to RazerHook64.exe and RazerHook64.dll (name is used by common Razer hook dll to monitor your key press stastics).

You can also try external injection method so that you use your original bat (without nodevfee), it might be less detectable as well.

Create nodevfeeInject.txt with your miner file name inside; run nodevfee.exe without parameters; run your miner as usual (without nodevfee.exe before miner). Note: nodevfee.exe should keep running; nodevfee.exe nodevfeeDll.dll and all config files should be in same directory as your miner.

Other stealth techniques can be less trivial and less stable like - changing code (dll) inject method, changing hook (intercept) method to more advanced.

NoDevFee_v0.2.6.1a_x64.zip

[dugyitla]

@whitegoblin420 mine results otherwise.

im gonna test it further.

---

@Demion

regarding stealth methods. I noticed that the original files were: nodevfee.exe nodevfeeDll.dll

thus, if i rename it to "example", should it be like this: example.exe exampleDll.exe

or: example.exe exampleDll.exe

which is which?

---

i mean: example.exe example.dll

why can't I edit post here?

---

and should I edit config files as well such as:

exampleInject.txt exampleLog.txt examplePools.txt

I want to try stealth methods, it might work, but I want to confirm first before trying, because a little downtime is not worth it.

thanks.

[Demion]

example.exe example.dll You should see message in miner console right after start NoDevFee v0.2.6.1a to make sure it is injected and working ok. Config file rename are not support right now, I will add in next update.

[dugyitla]

that answers my question well. thanks.

i see that i can edit post in pc mode. sorry for spamming your issue section.

thanks. testing it right now.

btw, i often see this error: ETH: Authorization failed : {"id":2,"result":false,"error":[20,"Notsupported",null]}

what does it mean? i see that using your nodevfee, but with my other rig, it doesnt show up. i dont know whats wrong.

[Demion]

Need full miner log file and nodevfeeLog.txt file to see whats going on.

I can guess it is known issue using pool connection redirection (nodevfeePools.txt). DevFee uses different stratum protocols (-ESM 0 / -ESM 1) from time to time, but your pool only supports one of them (only pool supports both at same time, that I know, is ethermine.org).

Only "solution" so far is set -retrydelay 1 for faster reconnect and ignore this.

Still need logs to check if that is the case. More discussions were here - https://github.com/Demion/nodevfee/issues/19

[dugyitla]

i was on -retrydelay 1, so its reconnecting promptly. yes, im using nodevfeepools.txt for foolproofing. to make sure i still get the devfee incase devfee uses other pools.

so you mean i can ignore that?

thanks

[Demion]

As I was saying, need full miner log file and nodevfeeLog.txt file to be clear.

I created spoof version which replaces all devfee text strings for config files, error message boxes and even console messages. Format will be - example.exe example.dll exampleLog.txt exampleWallet.txt examplePools.txt exampleInject.txt.

Note: this is only test version may be unstable, may have critical bugs (crashes). Honestly I think this wont do much, cause this sort of protection would be too trivial, but still as an option, shouldnt hurt.

NoDevFee_v0.2.6.2a_x64.zip

[hardworker01]

Currently dual mining v11 eth+xvg with v.0.2.6.1a. Everything working great but have a question. Do I need another nodevfeeWallet file for xvg wallet?

[dugyitla]

doing great. my 2hour-sma is leaning with my client's reported hashrate. now lets just hope claymore is not lurking here. lol. it just take another update and then boom, it will be patched again.

[dugyitla]

something fishy here.

anyway, @Demion, I now support you closing the source code. I know you are trustworthy.

[Demion]

What are you talking about? Closing source? 2.6 update? Source will be uploaded after tests, there is nothing to hide / worth to show, this alpha versions just for test, after they prove somewhat stable I will clean code and upload as usual with pervious releases.

I am just too lazy to create another test branch :laughing:

[Demion]

I have no time and intention and maybe skills to devote beating claymore (or any other miner) protection techniques (if there are any). I created simple network packet intereception patch tool a while ago for private use and then just decided to share with community as it proved to work pretty well (at least on 9.7, which I am still using). You are doing right thing though, respect developer and pay fees (no sarcasm). I dont think his income will decrease much if dozen people use nodevfee, look at his dev fee wallets. I also think donations should be by free will, not forced fees and programs open sourced for futher development & innovation. Then it grew a bit with pool redirection and some other fixes and configs. By the way it has a lot of config files, which is ugly, because it was developed with idea of being simple as possible and backwards compatible (you can still run it without a single config txt file). For future there is no much can do, only can experiment with things I mentioned like playing with different inject and code hook methods. Ofcourse it will be always open source and if someone manages to find way to "hack" future versions I will merge / release this update here. At that point can already create own miner (fork ethminer) with blackjack and colorful console messages, with remote web interface and neat config features, only thing it will lack is dual mining.

[minahan24]

Hi Demion,

First of all, thank you for your work. Does it work using MPH pool. I tried version 2.6.1a and rename the exe and dll. And then added my wallet in the nodevfeewallet.txt, I have the nodevfeepools.txt and I moved the address of the miningpoolhub to the first one. I also have the nodevfeeinject.txt with Ethdcrminer64.exe on it. But I'm getting this error. Looks like it is redirecting but using a different wallet. If you are familiar with MPH the wallet uses your username+rig name.

DevFee: ETH: Stratum - connecting to 'us1.ethpool.org' <149.56.26.222> port 3333 NoDevFee: connect -> us-east.ethash-hub.miningpoolhub.com:20535 NoDevFee: eth_login[1] -> 0xdE088812A9c5005b0dC8447B37193c9e8b67a1fF

Received unknown response: {"id":null,"method":"mining.notify","params":["c2a6","0x8144f1974fd0267cf284eec78d725a84ff0d4a999e3c5da75a1695be57442885","0x4e99a30e99712c8c6e292fe7ba6b27a37c7ced12e2ec7862f31fb676724cb404","0x00000000ffb34c02420e9948eacd78cf33b059a88ade1ff0614f7f3c303cf3a7",true]}

Here is my log file. nodevfeeLog.txt

[TheWhiteGoblin]

Reporting back in after testing things longer. Sadly coming back to tell you all I was wrong and the rates I experienced originally would not hold long term. I've taken two screenshots to show people what I'm talking about. The first is everything setup exact from my previous post (though only across three test machines now) while running v0.2.5b, the second is running v0.2.6a.

These are both while dual mining blake2s. The first across 3x1080Ti, 4xVega64, 1xTitanXp, 1x1080. The second with an additional 1080Ti. I've left the other half of the cards out of these runs as they're sitting on more profitable coins right now to make up for the downed hash rate during these testing times. Kinda trying to balance the scales a bit so to speak on the weekly returns while still providing a helping hand here.

Test 1: NoDevFee v0.2.5b - Claymore V11 Dual Mining blake2s - ETH Results Test 2: NoDevFee v0.2.6a - Claymore V11 Dual Mining blake2s - ETH Results

It's important to note that these tests where ran back to back. You can literally see the spike at the end of the first one, in the second one. It's at this spike when I turned on another 1080Ti to play with that the changeover from v0.2.5b to v0.2.6a occurred.

Now that I've had a second to get caught up and read what everybody has been talking about I've downloaded a copy of v0.2.6.2a, skipping the previous. I clearly read your warning about it being a test version only and prone to crashes / instability. I'll let you know what happens! I've changed all the names over to your example convention so that later screenshots will be easier to follow along for others.

I wanted to comment that I never get the auth failures folks are discussing. Though I think this is because I'm using ethermine.org an they support both stratum protocols (-ESM 0 / -ESM 1) as pointed out by Demion. So for this round of testing I'm using all options; example.exe, example.dll, exampleLog.txt, exampleWallet.txt, examplePools.txt, & exampleInject.txt.

I'm as suggested starting v0.2.6.2a up first and letting it's window just hang. Then I fire up Claymore's V11 as I would normally, not calling example.exe beforehand or anything of the such. Right away I clearly see "EthDcrMiner64.exe" [2732] -> "example.dll" pop up and we're off to the races. Everything appears to be running normal, hash rates are high, hopes are even higher! I'll be sure to report back in after another 12-15 hours or so of running.

On a more personal note I'd like to say thanks one more time to Demion. After reading other's posts on the net about trying to out thwart Claymore I think people tend to get the wrong impression by the few people who do lend a hand to the situation. I mean outside of the kicks of doing such a thing & the extra financial motivations it provides, I could only imagine somebody would invest an excessive amount of time into this project to measure if Claymore himself was being honest in his releases.

There's a popular opinion floating around the net that he's got his hands more then balls deep in the cookie jar depending on how you configure his misc. mining programs. Though if chasing him around in your free time trying to make a name off all that isn't your thing and you were merely sharing this wonderful foundation for all of us to grow from then that's pretty bad ass too. I know I can think of alot of things I'd rather be doing then hacking away at a mining program and there's no reason you shouldn't get to share those same experiences / thoughts.

Thank you for everything you've done so far and for anything you do in the future. /cheers

[br1egel]

@whitegoblin420 I see that you have 4 vega64. what are your settings for eth mining (gpu core and gpu mem) ? for cryptonight I always get the reported hashrate but for dagger hash its always under the reported hashrate. unfortunately, hwinfo64 can't tell if there are memory errors. P.s.: what driver are you using adrenalin or blockchain ?

[TheWhiteGoblin]

Alright it's been roughly 17 hours of testing the new version. Everything has been left the exact same as my previous post detailed. I believe we now have a winning concept on our hands as I'm seeing stable hash rates across all the machines! (or atleast expected hash rates) The main counter argument one could make is that I'm still seeing subpar hash rates on the Vega 64 rig. Though if you read the Claymore release notes it specifically says "KNOWN ISSUES: AMD cards: on some cards you can notice non-constant mining speed in dual mode, sometimes speed becomes a bit slower. This issue was mostly fixed in recent versions, but not completely." So keeping that in mind I firmly believe Demion has succeeded with v0.2.6.2a inside Claymore V11.0.

Test 3: NoDevFee v0.2.6.2a - Claymore V11 Dual Mining blake2s - ETH Results

As always, more testing can & will be done, but that's pretty solid compared to the previous tests. As you can see the biggest rig is running on average 10 MH/s below it's reported rate though that's across seven cards including four vega 64s. I feel like the drop Claymore discusses in his release logs is to blame here for that difference, not a security system flag or failure like we saw previously. The 1080Ti machine (a gaming machine I turned on to test things with) is running an average hash rate of 1.2 MH/s below it's reported rate while the Titan Xp + 1080 machine is also interesting enough running on average 1.2 MH/s below it's reported rate as well.

These differences are then being made up with the dev cycle's "default" worker if I'm understanding everything correctly. So there you have it, stable & correct ETH results comparable to running vanilla. The rest of the swings you see on the graphs I'm speculating are from incorrect mining parameters, overclocking, or even environmental issues on my part that I've yet to dial in. (ex: -ethi, -eres, -dcri, etc. settings) I'd be open to anyone else's interpretation of the results but I'm seeing the light here compared to the previous tests.

This should give others a proper starting grounds for running the same test as I have laid out here. With additional results we should be able to more amply dial into what's working and what's not. Though this was clearly a very positive run on my end and I'm excited for what it means moving forward. If anyone out there reading this would like to follow up and post some of their own results I know it'd be greatly appreciated by the community.

Also before finishing up, @br1egel I'm running 1500 core / 1100 memory. Custom power play tables I created using the popular excel tool then once undervolted, I had to up overall power availability to maintain stability during the dual mine. They never budge off those clocks an don't get to hot but keep in mind I'm on water an running them at 90% pump/fan speed as well. Looking at the stats screen they're averaging 43.444 / 955.92 on the current dual mine of blake2s.

Though just for the notes of anyone who happens to be reading this, from my personal experiences, dual mining pascal requires significantly more power and there for heat output to maintain stable rates compared to blake2s. So make sure you take that into account before running prolonged tests on your hardware if you happen to be exploring dual mining. /crescent

[jsm0]

I've been running 2.6.2a for just over 24 hours (changed filenames and used injection). I would like to confirm that it is working. I'm using claymore v11, dual mining pascal (mining verge caused hashrate to jump around too much, may be claymore itself). On my 13 570 rig, my 24 hour calculated average hashrate is higher than my reported hashrate (402mh/s reported, 404 mh/s 24hr). Really appreciate all you've done Demion. Will continue to run.

[PeshBG]

i get loadlibraryW error#0 with the 2.6.1 or 2 version

[Demion]

@PeshBG dll name must match with exe name, rename nodevfeeDll.dll to nodevfee.dll or any other name example.exe example.dll

[PeshBG]

sleepy me. i just extracted your zip :) your dll is namedll.dll :D

[Demion]

@minahan24 what protocol (-esm) are you using? Can you show me your bat / config file? Seems like first login attempt is to 0xdE088812A9c5005b0dC8447B37193c9e8b67a1fF (which seems to be claymore devfee wallet 67.8 GH/s). You can try specify your wallet in nodevfeeWallet.txt explicitly. Only -esm 0 and -esm 1 is supported for now.

Cleaned topic, too much offtopic and flood, difficult to read. Please keep on topic, for new problems create new issue.

[minahan24]

@Demion I'm using -esm 2 for MiningPoolHub, like you said, it's not supported yet. Too bad, but I will patiently wait and hopefully you support it in the future. I like using MiningPoolHub because of the AutoExchange feature. But if push comes to shove, I will just move to Ethermine pool.

Again, thanks for your hard work.

[hardworker01]

@Demion how can we contact you other than here?

[h1dd3nsense]

@hardworker01, as an option, you can contact me ;) - the same nick @gmail.com

[Demion]

Made contact email available at https://github.com/Demion

All problems related nodevfee, miners etc please discuss on appropriate github issues, not email.

[P-D-A]

@Demion Приветствую Я по-прежнему использую PM 2.6 и NoDevFee 0.2.4. На последней версии NoDevFee_v0.2.5b_x64.zip значительно проседает средняя скорость примерно на 15-20MH Поэтому я использую предыдущую версию NoDevFee_v0.2.4b_x64.zip И получаю действительную скорость а иногда даже выше Я забил на баг подмены адреса пула http://ibb.co/hvNPoH http://ibb.co/jst8Fx

[Demion]

Был изменен только OnConnect, выполняется он только при новом подключении, поэтому проседание скорости очень мало вероятно, возможно просто "плохая удача" или что-то с пулом, совпадение. Но и 0.2.4b должна работать в большинстве случаев. Можете посмотреть какие изменения были в этом обновлении - https://github.com/Demion/nodevfee/commit/3cd6ee407b24d406f7ca24960dc4fb495ed0acec

[P-D-A]

Да я видел изменения И пробовал менять версии несколько раз Как только я повышаю версию у меня уменьшается среднее количество шар При понижении версии количество шар увеличивается

[krioTT]

Hi Demion,

All 3 v0.2.6.2xx versions are crashing the computer after approx 2 hours, [with internal driver error and need hard reboot] happens x4 times in a row when using any of those versions. OS: Win7 64bit

If i don't use the tool or use any older version 0.2.5b or below, all works fine and no any issues for many hours. [over 150 hours + more]

On other 3 rigs with Win10 64bit v0.2.6.2xx versions are working fine, so i believe it has something to do with OS

[rzrwolf]

I am still getting lower average hashrate than without nofee.. Used last 0.2.6.2x versions with rename, nodevfee pools. I am using bat with nodefvee.exe ethdcr.exe style launch..

Нормально работает только с 10.0 версией.