@Nicehash staff, I think you are abusing of the stratum method "client.reconnect". Why are you sending this? Is it really needed? It adds trouble to the stratum/tcp connection and some extra delays.
Reconnects are needed, because the stratum protocol does not implement a way to change special extranonce parameters except for on first connection. Switching between other pool's relays requires changing these parameters. You can use the patches or patched compiled cgminer that nicehashdev has posted and are available on git. This implements a new command in the stratum protocol so that the reconnects are not necessary.
True, you can simply download pacthed cgminer and sgminer binaries here:
https://www.nicehash.com/software and you'll get rid of these issues and better performance on NiceHash (and the same performance on other pools as if you would be using other non-nicehash cgminer/sgminer builds).
BTW: Some pools ignores connection from our extended cgminer and sgminer. We added an option to disable these "advanced features" for pools not supporting this features. One of these pools is CoinFu.
Just add
"no-extranonce-subscribe" : true to the pool config for pools, that doesn't support extranonce-subscribe
Example:
{
"name" : "NiceHash Scrypt",
"url" : "stratum+tcp://stratum.nicehash.com:3333",
"user" : "btc_address",
"pass" : "x",
"algorithm" : "scrypt",
"nfactor" : "10"
},
{
"name" : "CoinFu",
"url" : "stratum+tcp://pool.coinfu.io:3333",
"no-extranonce-subscribe" : true,
"user" : "myrig_btc_address",
"pass" : "myemail",
"algorithm" : "scrypt",
"nfactor" : "10"
}
Keep in mind: this only applies it you're using our cgminer and sgminer builds from https://www.nicehash.com/software !You guys really mucked up the implementation of the extranonce subscription extension. Of all the ways you could have done it, you chose the only option with the potential to create enabled mining clients that are incompatible with other pools by default. You had full control of your stratum server implementation, and full access to nearly all client miner implementations, but little or no access to oftentimes proprietary stratum implementations at other pools, so the fact that you decided to initiate extranonce subscription messages from the mining client side, demonstrates either your incompetence or ignorance as to how to extend an already well established protocol without introducing negative consequences elsewhere, or callous disregard for the effects upon miners and the other pool operators who are affected by your protocol extension.
Given the circumstances, you should be initiating the extranonce subscription from the stratum server side, at which point an enabled mining client can respond in the appropriate fashion, and an earlier version ignore the message as you can easily verify that most mining clients do. But as it stands now, you have created a situation where extranonce subscription enabled mining clients are sending unexpected messages to stratum servers at other pools potentially causing unknown consequences there. Or was sabotaging your competitors part of the original plan?