Except, of course, when the new ASIC farms come online in the next 3-6 months, and everyone switches away to nScrypt and other algorithms which these ASICs can't handle.

At the moment the ROI for a Gridseed is in the 9-12 month range (accounting for difficulty), and I have little faith that straight Scrypt based coins will remain profitable for that long.

I think GPU mining will remain the best long term bet for quite some time now.

I just had a thought.

Let's say that this is only rarely occurring not by choice, but by necessity.

When you lose connectivity there will be likely be a small window during which the server isn't responding.

What if you were monitoring the network, and when you see a loss of connectivity you spring into action, responding to the reconnection request pretending to be the other server?  Spoofing/monitoring is a pain, and besides once they reply again then things are going to get messy.  So the very first thing that you do is redirect to your own (local) server (which also stops attempting to reconnect to the primary), then once the connected to you then you can redirect to the proper server without having to spoof or monitor the network.

If this isn't triggered, and only happens during a natural disconnect then it would explain why it happens to so few people.

Perhaps people can try to intentionally cause a disconnect from their primary server, momentary firewall rule or just rebooting your gateway could do it.  See if anything attempts a redirect?

Is it just cgminer?

Anyone on BAMT affected?

Has anyone been affected that has api mode disabled?

I'm sorry, I'm sure these answers are out there already, but I don't have time to read through all the threads (hence why I asked if there's a consolidated page somewhere).

If it was MITM couldn't this be completely transparent, as it could pretend and report that it's on pool X when it's actually funnelling requests to pool Z.  Hell, if it was smart and only redirected 5% of the hash nobody would probably notice.  Rounded pennies on bank interest payments anyone? 

What if it is malware, the malware itself hosts a stripped down pool, the reconnect goes there then the redirect goes to the malicious pool?  Could be done with local DNS spoofing.

I wonder if we can just ask the NSA to forward us a copy of our network traffic so we can analyze what happened 

Thanks Terk for all your help thus far!

Just to clarify, what sort of MITM attack are you thinking of?  It would essentially have to be router based, no?

But since it can be any network connected device that was infected and remotely controlled the mining machines, there could be a common OS between all infected networks.  I agree that it seems unlikely, but occam's razor here.  The rest of the options seem more unlikely.

In regards to DNS hijacking - if you can do that, you're probably going to go after email systems, banking or credit card, or actual websites including hosted wallets.  It's like being given a space based laser and using it to open your can of tuna :-)

Not trying to insinuate anything, but just suggesting...  I apologize if any of these ideas have already been covered, just trying to help.


Is it possible that clevermining was hacked, or at least one of the servers was, but the hack is smart enough to only siphon off a small amount of hash?  Otherwise it would be immediately noticeable when it was implemented.

Granted it appears that other pools were affected as well.  Is it possible that they're using similar backend software that may have been compromised?

Otherwise we appear to have a paradoxical situation.

- it isn't the pool because multiple pools are affected
- it isn't cgwatcher because those without it are affected
- it isn't the miner because people's miners that haven't been touched in weeks or longer are affected (unless it's a virus on the network)
- DNS hijacking seems unlikely, as that's a pretty massive thing to implement, and if you have that ability you're probably going after bigger fish.

I think malware does seem most likely, as if cgminer is open to remote control there is no authentication.  Any computer or device anywhere on the network could scan for and redirect miners.  This way even miners that haven't been touched in a year could still be affected.

Do we have a thread with full details on everyone who has been affected?  All software installed and versions, OS, patches, windows updates on/off, last time any configuration was modified, router, ISP, location, etc?

Do we have any way to reproduce this?  Does anyone with logging enabled have a record of the request?  Is it happening frequently enough to run a network monitor?  Do we know what coin is being maliciously mined?

I know exactly how this stuff works, and just because I posted a solution which isn't perfect (but still helps in this particular situation) doesn't mean that you have to insult me or others.


Notice the   after my comment?





... and additional random stuff at the end to convince the forum that I didn't already post this when it refused my post because I tried to repost after being refused because the thread had been updated.  This forum's auto-filters need some tweaks :-/

Valid point!  I had assumed that it was a fixed IP, however either way can't hurt at the moment.

Why wouldn't that help?

Doesn't help to determine why it's happening or who's doing it, but it will prevent it from happening.

For safety, everyone should consider doing this on any windows rig:

route -p add 190.97.165.179 {your computer ip}


Also we should flood that IP address with invalid responses and DDoS him  

I'm also local and very interested in discussing this with you further - will PM for more details.

I've been fiddling with risers as well, and as far as I can tell it's more a motherboard problem.

For example on ASUS motherboards they very rarely like the 30cm risers, but can usually handle the 15cm risers.  However the exact same 30cm riser and card on an MSI motherboard works perfectly fine.  I have an older ASUS P5Q-E motherboard with 5 slots, and only two of them like the 15cm risers, the rest refuse to work.  There are three on-board x16 slots, and all three can run a card no problem, so it's not the card or the motherboard directly.

I've tried risers in all configurations - completely unpowered (and no cap), unpowered (with cap) (as in the molex is there, just unused), powered (molex attached) and cut (molex attached).  Doesn't seem to make a difference to this motherboard.

I suspect the BIOS and/or motherboards have different thresholds for detecting the cards, and since risers drastically increase the line length you have slightly different timings.  If the BIOS/mobo isn't versatile enough to handle that it just won't detect the card, or it may work flakey.

Other people have mentioned that if your BIOS has settings to force the PCIe slots to v1.0 or v2.0 mode then risers tend to work more reliably, however my BIOSes don't seem to have that option.

Thanks!  But... I already have that, and it still reports the total in GH, and the individual cards in MH. 

I took a look at the source code, and it appears that it's hardcoded to always display that way.

Can I fork&pull to add a switch to allow toggling this between GH/MH and MH/KH?  If so, any particular option name I should use?

This looks very nice, thank you!  I've got one card that cgminer just seems to keep declaring dead, and occasionally cgminer crashes which stops everything.  I'm hoping that this will help with that!

Is there a way to change the scale for us lowly non-massive-farm scrypt farmers?

Right now the status page shows GH/s and MH/s but we're just doing MH/s and KH/s.

Thanks!

Did you manage to get it working?

If not then make sure that you're on cgminer 3.7.2.  Those versions that you mentioned are old.

What do you mean by "doesn't start mining" ?  More details would help.

Also try without the SDK, uninstall both the SDK and the Catalyst drivers and try to reinstall just the Catalyst.  Apparently you don't need the SDK anymore, and I have heard reports of failures with it installed.

Also try one card at a time.

You may need some wood dowels to support the card and to give a suitable edge to screw into.  Pictures of your setup may help us to help you better :-)

Are these needed anymore? 

I can't seem to find a definitive answer.

I have 6 rigs running without using the SDK, but they're all running slower than expected.  Is that what I should expect without installing the SDK?

I can see from the newbie help that it says that "logging in" and "searching" can trigger this. 

Isn't that a little over-sensitive? 

If I happen to want to respond to a post, or search for something and can clearly see that it isn't there, why do I have to wait another 5 minutes before I can post it?  Similarly if I search, can clearly see that my question has not been asked before, why do I have to wait?

Similarly with posting.  If I'm in many conversations at once, and I have to wait 6 minutes before responses, I'll likely leave and forget to come back...

Same deal with logging in.  That one seems really crazy.  If I'm in the middle of a conversation, haven't logged in yet today, then I have to log in and then wait 6 minutes before I can respond?

I can understand some restrictions to prevent spamming, but it would seem like the newbie only forum + 4 hour wait seems like a pretty good middle ground there.  Maybe 30 or 60 seconds between messages too (like most other forums).  That's enough to stop spammers, and require a little bit of thought on your posts, but 6 minutes is way too long.  I can quite easily compose meaningful and useful responses to threads within 60-90 seconds.  Again, if I'm forced to wait then I'm more likely to go do something else and forget to come back.

If someone is determined to spam, they will work around the restrictions.  Is seems a little overbearing and counterproductive to punish everyone for the actions of only a few.

What's really frustrating is that after getting the "you can't post yet" message, if you wait then it tells you that you've already posted this message.  I have to actually cancel it and start again?

I also ran into this bug today.

When you try to sign up there is no information about password size.  If your password is too short, you get an error message after you submit.  No problem.  But then when you go back to set a longer password and resubmit it fails saying that you already registered XX seconds ago.

It could be useful to both put the password restriction information on the registration page, and also not invoke the "already registered" if the registration failed.  First part is probably really easy, second part not as much.