New stratum/getwork proxy with Web-based GUI and pools management

[johnsmithx]

If there is nothing from the miner after it issued the mining.multi_version request then it's apparently waiting for the response. Maybe a simple non-error response would do, it should be fairly easy to implement in StratumConnection.java and StratumWorkerConnection.java.

But actually maybe you should respond with the error, maybe it is indicating it supports some non-public stratum protocol extensions (which this proxy of course obviously doesn't) so you need to let it know to downgrade itself back.

Maybe it's actually this proxy's bug that it doesn't respond with error to an unknown request and keeps the requester hanging.

Here is some comment hinting it could be something proprietary and here is another hint indicating S9 might be using this way to signal which extension(s) it supports. So the proxy just needs to respond appropriately.

EDIT: if you are up for it you might want to have a look at slush0's stratum-mining-proxy and his stratum implementation to see how that would react in case of an unrecognized request. He invented the whole stratum thing so I suppose that's the best place to look as this java proxy should imitate the same behavior.

Or maybe it would be faster to just try the slush0's proxy and see how it actually behaves and if it does allow your S9 to mine then just sniff their whole convo and implement what's missing into this one.

[edonkey]

If there is nothing from the miner after it issued the mining.multi_version request then it's apparently waiting for the response. Maybe a simple non-error response would do, it should be fairly easy to implement in StratumConnection.java and StratumWorkerConnection.java.

But actually maybe you should respond with the error, maybe it is indicating it supports some non-public stratum protocol extensions (which this proxy of course obviously doesn't) so you need to let it know to downgrade itself back.

Maybe it's actually this proxy's bug that it doesn't respond with error to an unknown request and keeps the requester hanging.

Here is some comment hinting it could be something proprietary and here is another hint indicating S9 might be using this way to signal which extension(s) it supports. So the proxy just needs to respond appropriately.

EDIT: if you are up for it you might want to have a look at slush0's stratum-mining-proxy and his stratum implementation to see how that would react in case of an unrecognized request. He invented the whole stratum thing so I suppose that's the best place to look as this java proxy should imitate the same behavior.

Or maybe it would be faster to just try the slush0's proxy and see how it actually behaves and if it does allow your S9 to mine then just sniff their whole convo and implement what's missing into this one.

I suspect that this might be a problem with the S9 firmware. When it first came out, the S9 could not be used on NiceHash. There was a firmware update that supposedly fixed that.

I never updated the firmware because I didn't need it. So my S9 has whatever stratum bug Bitmain introduced in their changed miner software.

Other people have been able to get this proxy to work with their S9, so it might be that all I need to do is update the firmware.

[edonkey]

If there is nothing from the miner after it issued the mining.multi_version request then it's apparently waiting for the response. Maybe a simple non-error response would do, it should be fairly easy to implement in StratumConnection.java and StratumWorkerConnection.java.

But actually maybe you should respond with the error, maybe it is indicating it supports some non-public stratum protocol extensions (which this proxy of course obviously doesn't) so you need to let it know to downgrade itself back.

Maybe it's actually this proxy's bug that it doesn't respond with error to an unknown request and keeps the requester hanging.

Here is some comment hinting it could be something proprietary and here is another hint indicating S9 might be using this way to signal which extension(s) it supports. So the proxy just needs to respond appropriately.

EDIT: if you are up for it you might want to have a look at slush0's stratum-mining-proxy and his stratum implementation to see how that would react in case of an unrecognized request. He invented the whole stratum thing so I suppose that's the best place to look as this java proxy should imitate the same behavior.

Or maybe it would be faster to just try the slush0's proxy and see how it actually behaves and if it does allow your S9 to mine then just sniff their whole convo and implement what's missing into this one.

I suspect that this might be a problem with the S9 firmware. When it first came out, the S9 could not be used on NiceHash. There was a firmware update that supposedly fixed that.

I never updated the firmware because I didn't need it. So my S9 has whatever stratum bug Bitmain introduced in their changed miner software.

Other people have been able to get this proxy to work with their S9, so it might be that all I need to do is update the firmware.

Updating the firmware to the latest resolved my problem. I've now got my S9 happily submitting shares through the proxy.

The update had a weird side effect of changing the MAC address on my miner. So after the update I lost contact with the miner. I was afraid that I bricked it until I found that it had been given a new dynamic DHCP address.

Weird...

[johnsmithx]

Updating the firmware to the latest resolved my problem. I've now got my S9 happily submitting shares through the proxy.

The update had a weird side effect of changing the MAC address on my miner. So after the update I lost contact with the miner. I was afraid that I bricked it until I found that it had been given a new dynamic DHCP address.

Weird...

Glad you worked it out!
Maybe it's a feature, maybe the new MAC is from a different set so that you can see at the first sight what firmware is given device running just from looking at its MAC.


Anyway, I succeeded with lowering the CPU and memory load, the new config options are as I suggested:

Code:

  "disableApi": true,
  "poolHashrateSamplingPeriod" : 2147483,
  "userHashrateSamplingPeriod" : 2147483,
  "connectionHashrateSamplingPeriod" : 2147483,
  "hashrateDatabaseSamplingPeriod": 2147483,
  "hashrateDatabaseHistoryDepth": 0,

and now (after hours of running) the both database files dbpools and dbusers stay untouched at 1422 bytes. So to my great relief I didn't have to actually abuse the source code at all. I also considered some additional flags that perhaps might increase the performance, something like:

Code:

java -d64 -server -XX:+AggressiveOpts -XX:+AggressiveHeap -jar stratum-proxy.jar

but I actually never got to test it because I managed to compiled the whole thing so I don't run it with java -jar stratum-proxy.jar anymore, but this is very experimental and needs testing so I am not going to describe it just yet.

So I am not sure which of these changes contributed more to the final result but now stratum-proxy is actually taking less memory than eth-proxy (before it was taking twice as much as eth-proxy) and its CPU load is 0%, literally (before it was in tens of %):

Code:

USER       PID  PPID  PR  NI %CPU %MEM    VIRT    RES    SHR   SWAP S TTY          TIME+ WCHAN      COMMAND
root     21613     1  20   0  2.0 13.2  502176 134388  27380    276 S pts/7      1:31.07 ep_poll    ./eth-proxy.exe
root     13122     1  20   0  0.0 10.2 3860096 103096  52044      0 S pts/7      0:02.72 futex_wai+ ./stratum-proxy.exe -f stratum-proxy.conf

(don't mind the .exe suffix, it has nothing to do with Windows; btw I compiled eth-proxy, too, so I don't run it with python eth-proxy.py either)


So I would say a success. When the author comes back from vacation (or whatever) and checks this thread I think he will be pleased.

[edonkey]

Glad that you were able to get the performance you need by just changing options.

It would be cleaner if there was a new option to run completely headless, but that would be more work. It would be nice to hear from the author at some point.

In the meantime I've been very happy with this proxy, now that I got the logging under control and worked through my miner-specific problems.

[Queenvio]

Hey guys.
I want to connect Nicehash to my proxy. But it got the error: "Disconnected. Remote pool extranonce2 size too small (min=4)." from Nicehash.
Can I set the extranonce2 to 4 anywhere?

Greetings

[scyth33]

Hey guys.
I want to connect Nicehash to my proxy. But it got the error: "Disconnected. Remote pool extranonce2 size too small (min=4)." from Nicehash.
Can I set the extranonce2 to 4 anywhere?

Greetings

try adding this to your conf file

"workerNumberLimit" : 1,

[Queenvio]

Hey guys.
I want to connect Nicehash to my proxy. But it got the error: "Disconnected. Remote pool extranonce2 size too small (min=4)." from Nicehash.
Can I set the extranonce2 to 4 anywhere?

Greetings

try adding this to your conf file

"workerNumberLimit" : 1,

I tryed it. But if I check the pool I got the message:
"Error: Extranonce2 size is 3 (minimum is 4)"

with "workerNumberLimit" : 256
the message is "Error: Extranonce2 size is 2 (minimum is 4)"

[johnsmithx]

Hey guys.
I want to connect Nicehash to my proxy. But it got the error: "Disconnected. Remote pool extranonce2 size too small (min=4)." from Nicehash.
Can I set the extranonce2 to 4 anywhere?

Greetings

You want to connect your proxy to Nicehash, not Nicehash to your proxy. The error is from your proxy, not from Nicehash, and it says that Nicehash, not your proxy, is using too small extranonce2. Your proxy expects the size to be at least 4, Nicehash says 3. There is nowhere you could set 4 as you obviously cannot change how Nicehash servers are configured. The only way would be to make the proxy accept size 3.

What algo?

[Queenvio]

Hey guys.
I want to connect Nicehash to my proxy. But it got the error: "Disconnected. Remote pool extranonce2 size too small (min=4)." from Nicehash.
Can I set the extranonce2 to 4 anywhere?

Greetings

You want to connect your proxy to Nicehash, not Nicehash to your proxy. The error is from your proxy, not from Nicehash, and it says that Nicehash, not your proxy, is using too small extranonce2. Your proxy expects the size to be at least 4, Nicehash says 3. There is nowhere you could set 4 as you obviously cannot change how Nicehash servers are configured. The only way would be to make the proxy accept size 3.

What algo?

Algo : Scrypt

To be clear. I want to rent some mining power at nicehash and send it via my proxy to another pool. (Dosnt matter why)
And if I add my proxy as a pool there, I got the these errors.

[johnsmithx]

Hey guys.
I want to connect Nicehash to my proxy. But it got the error: "Disconnected. Remote pool extranonce2 size too small (min=4)." from Nicehash.
Can I set the extranonce2 to 4 anywhere?

Greetings

You want to connect your proxy to Nicehash, not Nicehash to your proxy. The error is from your proxy, not from Nicehash, and it says that Nicehash, not your proxy, is using too small extranonce2. Your proxy expects the size to be at least 4, Nicehash says 3. There is nowhere you could set 4 as you obviously cannot change how Nicehash servers are configured. The only way would be to make the proxy accept size 3.

What algo?

Algo : Scrypt

To be clear. I want to rent some mining power at nicehash and send it via my proxy to another pool. (Dosnt matter why)
And if I add my proxy as a pool there, I got the these errors.

Oh, that makes sense, I couldn't find anywhere in the proxy source code where would it require 4. So Nicehash is a miner here and requires 4, but proxy says 3. Well, if I get it (this time) right the proxy just passes what the remote pool (what you called "another pool") says.  I don't think there is anything that could be done in the proxy source code. If I am correct (which I am not sure) then even if you connected Nicehash directly to your "another pool" it would give the same error. Can you try that? If you don't want the "another pool" to see Nicehash IP (if that's the reason why you want to use proxy) then you can redirect the connection via any Linux box with iptables, I can help you with that if you need.

[scyth33]

any of you guys managed to get multiple "apiListenPort" to work on the same pc so that the web gui can be accessed accordingly? getting  the following error
tried using 45001, 45002, 45003... in 3 different conf file but only 45001 is accessible through the web. the other 2 is not accessible.

Code:

2016-08-30 21:28:01,272 ERROR    [main]:strat.mining.stratum.proxy.Launcher - Failed to start the proxy.
java.net.BindException: Address already in use: bind
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Unknown Source)
	at sun.nio.ch.Net.bind(Unknown Source)
	at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
	at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
	at org.glassfish.grizzly.nio.transport.TCPNIOBindingHandler.bindToChannelAndAddress(TCPNIOBindingHandler.java:132)
	at org.glassfish.grizzly.nio.transport.TCPNIOBindingHandler.bind(TCPNIOBindingHandler.java:88)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.bind(TCPNIOTransport.java:236)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.bind(TCPNIOTransport.java:216)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.bind(TCPNIOTransport.java:207)
	at org.glassfish.grizzly.http.server.NetworkListener.start(NetworkListener.java:680)
	at org.glassfish.grizzly.http.server.HttpServer.start(HttpServer.java:278)
	at strat.mining.stratum.proxy.Launcher.initHttpServices(Launcher.java:260)
	at strat.mining.stratum.proxy.Launcher.main(Launcher.java:132)

[yslyung]

still can;t find the answer, other miners connected to this proxy then to nh/wh works ok with some occasional rejects then back to normal but when antminers connected via this proxy pointed to nh/wh, it gets lots of rejects, dupes, stales...

BUT when the antminers are pointed directly to nh/wh, they work fine.

mystery waiting to be solved.

just to nh/wh on the ants that have high errors but to other pools it works fine.

[sigwo]

If there is nothing from the miner after it issued the mining.multi_version request then it's apparently waiting for the response. Maybe a simple non-error response would do, it should be fairly easy to implement in StratumConnection.java and StratumWorkerConnection.java.

But actually maybe you should respond with the error, maybe it is indicating it supports some non-public stratum protocol extensions (which this proxy of course obviously doesn't) so you need to let it know to downgrade itself back.

Maybe it's actually this proxy's bug that it doesn't respond with error to an unknown request and keeps the requester hanging.

Here is some comment hinting it could be something proprietary and here is another hint indicating S9 might be using this way to signal which extension(s) it supports. So the proxy just needs to respond appropriately.

EDIT: if you are up for it you might want to have a look at slush0's stratum-mining-proxy and his stratum implementation to see how that would react in case of an unrecognized request. He invented the whole stratum thing so I suppose that's the best place to look as this java proxy should imitate the same behavior.

Or maybe it would be faster to just try the slush0's proxy and see how it actually behaves and if it does allow your S9 to mine then just sniff their whole convo and implement what's missing into this one.

I suspect that this might be a problem with the S9 firmware. When it first came out, the S9 could not be used on NiceHash. There was a firmware update that supposedly fixed that.

I never updated the firmware because I didn't need it. So my S9 has whatever stratum bug Bitmain introduced in their changed miner software.

Other people have been able to get this proxy to work with their S9, so it might be that all I need to do is update the firmware.

Updating the firmware to the latest resolved my problem. I've now got my S9 happily submitting shares through the proxy.

The update had a weird side effect of changing the MAC address on my miner. So after the update I lost contact with the miner. I was afraid that I bricked it until I found that it had been given a new dynamic DHCP address.

Weird...

Where did you get the updated S9 firmware? I do not see it available on the bitmain site. https://bitmaintech.com/support.htm?pid=00720160628032419599ebY2YSlj06DE

[sigwo]

Found some useful links
https://we.tl/UT5QgpzDb6 firmware

https://enforum.bitmain.com/bbs/topics/3554 for the procedure

[Nataly2014]

Hi!
Help me who know?
Give me please some a manual or link (url)
How i can to setup a proxy for work with my client-wallet scrypt coins.
I.e. - I want could connect to the strathem stratum proxy from hash (rental: Nicehash or miningrigrentals) on stratum proxy -  And stratum proxy will to connect to my wallet.
P.S. impossible for me to connect with my coin-wallet from the rent service  on a directly!
Thanks!

[crysx]

Hi!
Help me who know?
Give me please some a manual or link (url)
How i can to setup a proxy for work with my client-wallet scrypt coins.
I.e. - I want could connect to the strathem stratum proxy from hash (rental: Nicehash or miningrigrentals) on stratum proxy -  And stratum proxy will to connect to my wallet.
P.S. impossible for me to connect with my coin-wallet from the rent service  on a directly!
Thanks!

solo mining cannot be done through the stratum-proxy - unless someone has figured a way of doing it through stratum that converts it back to getwork ...

#crysx

[HardSign]

Does it work with zec coin stratum? I've tried but got an error like "disconnected, expected "str" "

[toptek]

Does it work with zec coin stratum? I've tried but got an error like "disconnected, expected "str" "

 not yet that i tired , that doesn't mean it doesn't yet or won't .

[edonkey]

I'm trying to point my S9's at NiceHash for SHA256 mining. Unfortunately I'm seeing a large percentage of rejects (around 30%). Most of the rejects seem to be duplicate shares:

Code:

2016-11-07 08:26:41,291 INFO     [Pool-NiceHash-Thread]:strat.mining.stratum.proxy.worker.StratumWorkerConnection - REJECTED share (diff: 32768.0) from s92@192.168.80.102 on NiceHash. Booo !!!!. Error: JsonRpcError [code_=22, message=Duplicate share., traceback=null]
2016-11-07 08:26:45,510 INFO     [Pool-NiceHash-Thread]:strat.mining.stratum.proxy.worker.StratumWorkerConnection - REJECTED share (diff: 32768.0) from s91@192.168.80.101 on NiceHash. Booo !!!!. Error: JsonRpcError [code_=22, message=Duplicate share., traceback=null]

I tried to work around this by enabling and disabling extranonce and by setting a reasonable minimum difficulty. I also tried both syntaxes for specifying the extranonce to NiceHash (i.e. adding "#xnsub" and "/#xnsub" to the URL).

I've also tried a single worker behind the proxy, in case the issue is related to multiple workers.

Nothing I change seems to help.

When I point the S9s directly at NiceHash, they work fine with almost no rejects. But of course that defeats the purpose of a proxy.

Any recommendations for getting this proxy to work with NiceHash?