Maybe it's not malicious activity? Maybe there's something wrong with some piece of software being used?
For example, I have a number of S1s running through a Stratum proxy. How can I verify it's properly feeding random work to all the ants, and half of them aren't working on the same thing the other half are working on?
M
Would you mind sharing what stratum proxy you are using? Version?
I've tried running my S1's through BFGMiner 3.10 and I receive 100% errors. I've seen other folks with the same issue
I would like to know which stratum proxy you are using and how you set it up.
I have tried using bfgminer, cgminer, and mining_proxy.exe to proxy the S1's without luck.
Thanks.
I'm using Slush's stratum proxy. I don't like executables when I can run code, so I'm using the latest git through python on my windows machine.
\python27\python mining_proxy.py -o stratum.mining.eligius.st -p 3334 -sp 3333 -gp 8330 -cu -rt -nm
then I point my S1s to port 3333 on that machine with whatever username/pw I want. everything shows up on Eligius under the payout address. I watch the output from the proxy to see it actively hashing and the pool stepping up the vardiff.
On the subject of luck ... it's awful right now. 47% over 24 hours? is everyone 100% sure there isn't some exploit going on here?
Lastly.. anyone notice how network hashrate overall stabilized? According to my math we're looking at a 1% increase next change. The number of minutes between blocks (supposed to be 10):
((timestamp of last block) - (timestamp of last block before diff change)) / 60 / (number of blocks since last change) = 9.79 mins
Divide 10 by that value to get the ratio..
Multiply that ratio times current difficulty to get projected next difficulty.
Now that could mean people stopped adding hash power, or it could mean the network globally is experiencing a really hard time solving blocks at 100% luck since the last difficulty.
M