This repository has been archived by the owner on Apr 24, 2022. It is now read-only.
Nicehash stratum extranonce isn't handled correctly. #1096
Labels
Comments
|
Just done checking newer releases. 0.15.0.dev0 - 0.15.0.dev4 are working fine Anything newer than either 0.15.0.dev4 or 0.14.0.rc5 doesn't work. |
|
0.15.x works fine with nicehash. For instance running on 0.15.0.dev8-5+commit.a073a8c3 etherdig.net:4444 (ethereumstratum mode) does not send "mining.set_extranonce" notifications or sends em wrongly. Same pool with ethproxy mode (etherdig.net:8008) works fine Finally using original Nicehash works ok. As you can see extranonces are processed correctly. We've done some work to ensure messages are properly formatted. Please track down all messages output'ed from your pool. |
|
Ethereumstratum specs can be checked here https://github.com/nicehash/Specifications/blob/master/EthereumStratum_NiceHash_v1.0.0.txt |
I followed this specification while implementing protocol on my pool. Everything is functional with PhoenixMiner, Claymore's Dual Ethereum miner and specified subset of ethminer releases.
Please read the specification first. Nicehash's Stratum uses bitcoin like difficulty notation. Difficulty 1.0 means 2^32.
Ability to send mining.set_extranonce notification is not a part of protocol, it's just an extension. According to specification, pool is not obliged to send extranonces via mining.set_extranonce notification. The mining.set_extranonce is used only if it's neccessary to change extranonce prefix without reestablishing connection to the pool. Just check the following lines: "May" doesn't mean "has to". On the other hand, according to specification, Nicehash stratum pool must set the extranonce via response to mining.subscribe request: https://github.com/nicehash/Specifications/blob/master/EthereumStratum_NiceHash_v1.0.0.txt#L152 Ignoring the extranonce which was set by mining.subscribe response is incorrect behaviour. Even if some pools are setting extranonce prefix again via mining.set_extranonce notifications. Of course I can add mining.set_extranonce notification but this would seem as no more than workaround, not a correct implementation... Because it will break those clients which doesn't provide support for mining.set_extranonce notifications. |
Agreed. |
|
Extranonce is not ignored if the proper formatting of jsonrpc message are met. Ethereumstratum specs depict But your pool responds That extra "jsonrpc="2.0" makes us fallback into examining "params" member (as per notifications of Jsonrpc 2.0). |
|
If you want to endorse jsonrpc 2.0 it think it should be |
|
Otherwise we need to implement a trick to handle this "mixed" behavior as Ethereumstratum specs never use "jsonrpc" : "2.0" |
|
@AndreaLanfranchi Ok, thanks. I'll try this. |
|
@AndreaLanfranchi What about job messages? Do I need to provide jsonrpc version field there or not? Nicehash messages are seem as correct jsonrpc 2.0 messages but this field is not defined by specification. When sending nicehash stratum responses without version field I'm getting error messages which are asking me to obey the jsonrpc specification. So it seems that I have to send jsonrpc:"2.0" in every message with exception for response to mining.subscribe. Of course I'll do this in my implementation but this seem inconsistent to me. And it confuses me a lot. |
|
Could you please provide an example of any of your message(s) which triggers compliance warning ? |
|
Thise are messages in a typical session done via dummy client: |
|
Ethminer works fine with such message format. When I remove "jsonrpc" field, I'm getting this message: So it looks like I have to stick with jsonrpc 2.0 specification in some messages, while in others I don't have to. I can understand this but nicehash specification doesn't require us to obey the jsonrpc standard. How such dilemma can be resolved? |
|
Do you remove the "jsonrpc" member or do you value it to null ? I mean this
In short ... if you insert jsonrpc member it has to be exactly valued "2.0" otherwise this member MUST not be present. |
|
Could you report transcript from a "real" failing conversation ? |
|
@AndreaLanfranchi I remove it entirely, so messages are looking exactly as they are presented in specification. Just for example, if I'm sending job without version field: then I'm getting standard compliance error message. |
|
Which error ? Version 1 or Version 2 ? |
|
Quote from the miner's output: This is a reaction to message which I provided. |
|
Could you give a test address of pool for me to perform some debug ? |
|
@AndreaLanfranchi I'll set it up now, will report you back in a matter of hour. |
|
188.65.212.49:13333 - this server responds exactly according to nicehash specification, i.e. without version field. Getting standard compliance error with latest ethminer. 188.65.212.49:16666 - this server provides "jsonrpc" field, which is set to "2.0", for all messages except response to mining.authorize request. It works fine with latest ethminer. |
|
@CryptoManiac Do you mind if I run a couple of tests against those? |
|
@jean-m-cyr Nope, of course. It's purposed to run tests :) |
|
@CryptoManiac |
|
@AndreaLanfranchi Understood. So, ethminer runs JSON-RPC compliance checkings for any kind of stratum protocol, am I right about that? |
|
@CryptoManiac Ok, done. Thanks |
|
@jean-m-cyr These servers will be available for some time, but I wouldn't rely on them in the future. They may be stopped if owner will need this machine to test some other things. |
|
Thank you guys, I think it's not relevant anymore. |
Yes ... you're right. |
|
It seems other miners aren't as rigorous, and nor were we till recently. I only test nicehash against daggerhashimoto.usa.nicehash.com and they are compliant. I wonder about other nicehash pools? |
|
@jean-m-cyr It looks like my pool is the only one for now. This seems to be a result of absence of official support for unix-like systems by its reference implementation. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi all. I'm getting incorrect behaviour with nicehash-startum pools. Looks like ethminer ignores extranonce which was set by pool and uses 0x00 instead. As the result, all generated shares are rejected.
As you can see, there is no "Extranonce set to" message.
If I downgrade to 0.15.0.dev0 then everything is working fine:
You can see that extranonce value is processed properly and all generated shares are accepted by pool.
I'm currently using this implementation of stratum server:
https://github.com/CryptoManiac/open-ethereum-pool-pps/tree/POT
Alive stratum server is available at etherdig.net:4444.
The text was updated successfully, but these errors were encountered: