MRR's overhead is quite small but unless you really need MRR between you and the pool for some other feature then I would always recommend the most direct connection regardless of where you mine as every tiny bit of latency matters in the event of finding a block to avoid losing a potential orphan race.

There is no secret to luck. You are gambling and there is no way to make luck. You are only lucky or unlucky after the fact.

EDIT: Kano has uploaded binaries for S1-3 here:
https://github.com/kanoi/cgminer-binaries

Yes it does.

With all the recent bug tracking I was doing on Kano's pool and finally sorted the problems, this pool had ended up in an intermediate code point between the old and new when I last restarted it so it probably wasn't running ideal.

Seems ok but I'll give the pool a kick in the arse to bring it in line with current code just in case.

Indeed this is not a problem with ckpool applying some kind of restriction on mining. I do have quite a few miners mining with 2GH or less, despite what you see here and the feedback of shares is helpful to them. If nice/westhash want to have an arbitrary lower limit on diff they support they should use the "suggest diff" method that is in the original stratum specification so that the pool knows what the mining client wants.

Why do you think it would let you continue mining at the low diff? As soon as the hashrate climbed it would just keep bumping your diff up and ckpool has the fastest adapting diff algorithm in use of any pool software. ckpool also happens to be absurdly scalable (which was the whole point of the design when I started writing it) so it could likely handle 100k clients. There are much more effective ways to "attack" a pool, like any server, though there's really nothing to gain by attacking this one, just downtime.

Pool's starting diff is 1000 and it can work at any diff whatsoever from 1 up to virtually infinity. This is not my problem, take it up at their end.

Here's a painful eventuality for someone:


Note that my ckpool code figures it may as well submit blocks that look very close to the diff in case there's a rounding error, but alas that really didn't meet the target which is currently 47610564513

So close...

Does not matter at all.

Tagged milestone M15. Numerous bugfixes and performance improvements to ckpool and significant feature upgrades to ckdb, too many to describe in detail.

Indeed, it adds to the community feel but one of the features of the pool is the relative anonymity of those mining here so if they choose to remain anonymous we'd have to respect that decision.

cgminer was revamped completely to not use getwork when talking to bitcoind a long time ago and use getblocktemplate support to be able to generate work itself to mine solo to bitcoind/qt. Local work generation is the only way to provide enough work for asic generation miners and most pools normally use stratum which is a much lower overhead template based local work generation protocol. Trying to mine to bitcoin-qt on port 3333 will fail because there is no support for stratum on bitcoin-qt. The best you can do is to use port 8332 (specify it as http:// ) and cgminer will automatically generate work locally on the device running cgminer using getblocktemplate. That said, the controller in an S5 is so low spec a CPU that it will be pushed to its limits to try to generate work in this manner and you're better off using a pool to create streamlined stratum templates of work for you. To that end, I run solo.ckpool.org which does all the work for you and avoids the significant local resources you'd need to dedicate to trying to make your bitcoin connection connected and fast enough to minimise the risk of getting an orphan block in the extremely unlikely event you found a block, only for it to be invalid. Bottom line is you're better off using a dedicated server to do the work for you if you want to solo mine.

Extranonce support is a non standard stratum extension designed by nicehash just for nicehash to use to support their multicoin multipool proxy switching pseudo-pool. We have no interest in putting support for one service like that in mainline cgminer. Officially provided source and binaries by the cgminer team do not have extranonce support. Their patch also appears to introduce some kind of bug that prevents workers from switching away from a dead pool.

Dear nicehash/westhash admins/programmers.

If you disconnect miners that have been idle for 5 minutes you will get into a never ending fight with cgminer clients that only fail back to stable pools after 5 minutes leading to a persistent resonating failure. Can I suggest you increase your disconnect timer to longer, say 10 minutes, if you must have one.

The force is strong in this one.

Will that do?

I believe I've made significant inroads into finding the cause of the long standing bug which recently has become much more pronounced after investigating for the last week solid (see ckpool git for the number of patches recently committed). It's too early call it fixed but it has not shown up for a longer stretch than in a while and we've ruled out numerous other possible causes so this was the first scheduled restart in a while, and hopefully we can leave the pool in peace for a bit.

And now for some blocks please.

Think about those two statements.