kenshirothefist (OP)
|
|
May 07, 2014, 11:25:17 PM |
|
what was the nature and reason for the patch - I've been using cgminer and love it because it's got a monitoring api
To add better support for NiceHash stratum severs for better efficiency. If you have good experience with any existing cgminer build for gridseeds that is working fine with NiceHash, please let me know which one are you using. any reason to switch to cpuminer for my seeds and blades?
No. Who is talking about cpuminer anyway?
|
|
|
|
jjj0923
|
|
May 07, 2014, 11:27:58 PM |
|
what was the nature and reason for the patch - I've been using cgminer and love it because it's got a monitoring api
To add better support for NiceHash stratum severs for better efficiency. If you have good experience with any existing cgminer build for gridseeds that is working fine with NiceHash, please let me know which one are you using. any reason to switch to cpuminer for my seeds and blades?
No. Who is talking about cpuminer anyway? just saw your posts and asked - I am not working with you guys but I do have a question. I visited your site and saw this: Scrypt: 2.10 GH/s @ 3.84 BTC/GH/Day I'm all scrypt and I have 30 Mhs - so - what could I earn/day selling you my hash? thanks in advance.
|
|
|
|
kenshirothefist (OP)
|
|
May 07, 2014, 11:32:24 PM |
|
Scrypt: 2.10 GH/s @ 3.84 BTC/GH/Day
I'm all scrypt and I have 30 Mhs - so - what could I earn/day selling you my hash?
Pretty simple ... 30 * 3.84/1000 = 0,1152 BTC per day at current rate (3.84 BTC/GH/Day).
|
|
|
|
jjj0923
|
|
May 07, 2014, 11:34:56 PM |
|
Scrypt: 2.10 GH/s @ 3.84 BTC/GH/Day
I'm all scrypt and I have 30 Mhs - so - what could I earn/day selling you my hash?
Pretty simple ... 30 * 3.84/1000 = 0,1152 BTC per day at current rate (3.84 BTC/GH/Day). ok - that's what I came up with also - just wanted to verify - thank you.
|
|
|
|
mrwizzy2002
Newbie
Offline
Activity: 14
Merit: 0
|
|
May 08, 2014, 01:00:12 AM |
|
So does anyone know why cudaminer isn't supported here. It's worked for me for a while and never seems to really fail but my numbers on the site don't appear to be counting all my power lately. I should be mining at around 2,200 Kh/z but it's only counting around 1,200 atm and seems to be this low all the time lately. My miners are mining just fine but the only thing that looks fishy is that my sgminer with my 7970 is always saying request work restart. Is that normal at all? Trying to figure out what's wrong here. So inconsistant!! It always ran at a constant rate when I was mining DOGE so does that mean it's not my miner? https://i.imgur.com/lh3JWUP.png
|
|
|
|
p4u
Member
Offline
Activity: 111
Merit: 10
crypto lover
|
|
May 08, 2014, 01:23:14 AM |
|
@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.
|
|
|
|
phzi
|
|
May 08, 2014, 01:32:36 AM |
|
@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.
|
|
|
|
isaax
Newbie
Offline
Activity: 6
Merit: 0
|
|
May 08, 2014, 02:42:20 AM |
|
To add better support for NiceHash stratum severs for better efficiency. If you have good experience with any existing cgminer build for gridseeds that is working fine with NiceHash, please let me know which one are you using.
Please patch this cgminer for Gridseeds. It allows individual frequency tuning for each of the Gridseeds one has. https://github.com/girnyau/cgminer-gc3355
|
|
|
|
zmija
|
|
May 08, 2014, 08:26:32 AM |
|
Hi, will be @ your multipool any x11 soon? Any plans and if yes when do u think it will happen thx . Btw summer is comming and it will get much hotter
|
|
|
|
kenshirothefist (OP)
|
|
May 08, 2014, 09:22:16 AM |
|
@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 !
|
|
|
|
|
|
p4u
Member
Offline
Activity: 111
Merit: 10
crypto lover
|
|
May 08, 2014, 10:01:13 AM |
|
@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. I see. However if I'm not wrong the client.reconnect method needs host and port parameters. The nicehash stratum server is not providing them, so it makes some system crash. I'm not using sgminer/cgminer directly, I'm using a stratum proxy instead. Can you provide the specification on this new command so I can implement it in the stratum proxy?
|
|
|
|
BitcoinGeekBoy
Member
Offline
Activity: 104
Merit: 10
|
|
May 08, 2014, 01:46:39 PM |
|
|
|
|
|
nicehashdev
|
|
May 08, 2014, 03:53:14 PM |
|
I don't see how this could be abused in NiceHash scenario. To be able to redirect miners, you either have to hijack domain or stratum server. Spoofed TCP packets might be oriented towards certain victim only - if you know it's IP. To get list of IPs of all miners on NiceHash, you need access to stratum server. We don't ever send reconnect to any other pool, we use param-less reconnect method, which should result in miner connecting to same host. This has been documented already. For all implementing your own extranonce subscriptions, here is proposed stratum extension RFC, which is currently being used: Uppon successful subscription to stratum with "mining.subscribe" method, client should send "mining.subscribe.extranonce" method.
{"id": X, "method": "mining.subscribe.extranonce", "params": []}\n
This informs the server (pool) that client (miner) supports extranonce1 change on-the-fly without the need to reestablish connection.
Servers supporting this method will reply:
{"id": X, "result": true, "error": null}\n
If the server does not support method, reply will be:
{"id": X, "result": false, "error": [20, "Not supported.", null]}\n
Server may also simply ignore this subscription and return no reply or return invalid method. Some pools may return incorrectly formed error message. Some pools may drop connection (in such cases, it is best to offer user a way to turn extranonce subscriptions off for certain pools - via config for example). In all cases, client does not perform any logic when receiving back these replies.
With mining.subscribe.extranonce subscription, client should handle extranonce1 changes correctly. Server would send:
{"id": null, "method": "mining.set_extranonce", "params": ["08000002", 4]}\n
First parameter is string extranonce1 value, second parameter is integer value of extranonce2 size. Miner shall start using new extranonce1 when new job is provided with mining.notify.
|
|
|
|
kenshirothefist (OP)
|
|
May 08, 2014, 05:55:36 PM |
|
when will my hosted miners with gawminers be able to work at nicehash? since they use cgminer
Good news. GAW miners software engineering team notified us that they have updated their cgminer software with our patches. GAW miners hosted miners should now work fine with NiceHash. Please try to connect your miners to NiceHash and let us know if all is fine now.
|
|
|
|
x8008
|
|
May 08, 2014, 06:59:53 PM |
|
when will my hosted miners with gawminers be able to work at nicehash? since they use cgminer
Good news. GAW miners software engineering team notified us that they have updated their cgminer software with our patches. GAW miners hosted miners should now work fine with NiceHash. Please try to connect your miners to NiceHash and let us know if all is fine now. yes things are working fine
|
|
|
|
zmija
|
|
May 08, 2014, 07:19:36 PM |
|
Any news on x11 mining?
|
|
|
|
CoinBuzz
|
|
May 08, 2014, 09:04:19 PM |
|
Do u have any plan to add X11 support?
|
|
|
|
comeonalready
|
|
May 09, 2014, 01:20:11 AM |
|
@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?
|
|
|
|
|