Disconnect from pool, if auth is failed
handle mining.set_extranonce method
subscribe for mining.extranonce
Allow disable extranonce subscribe
Send subscribe request before auth
Change mining.set_extranonce method as stratum notification
Set extranonce.subscribe timeout to 2sec
Some tweaks for extranonce
Handle pool response, who send errors in invalid format
Move no-extranonce-subscribe parameter to a pool config
Include pool.h
Set the pool idle and switch pool, if need
Mark pool as idle if stratum restart is failed
Conflicts:
sgminer.c
It looks like there's an exploit that abuses said command, but it is still not clear exactly how.
There's also an additional message when the reconnect happens: "WARNING: POTENTIAL CLIENT.EXPLOIT!", but it requires you to be actively monitoring your log to catch it, and in which case you already get a "Reconnect requested from Pool 0 to 127.0.0.1" message.
Note that disabling 'client.reconnect' might affect some pools that rely on the feature, like pools that you lease your rig to.
Oh and this is dry-coded. :)
The names will be used throughout the display in the program, when not set "Pool 1" will
simply be used instead. The names are not exposed through API yet, it's on my TODO list.
Use "poolname" like this:
{
"poolname" : "Example pool",
"url" : "stratum+tcp://example.com:8080",
"user" : "y",
"pass" : "x"
},
Conflicts:
sgminer.c
util.c
This may be useful in certain scenarios. However, server load from keepalive
is increased 6-fold if code is hard-changed from 30 to 5. So, provide it as
an option instead, and use the previous value as a default (30).
Explanation from
015c064396
Kevin's middlecoin fix, CURL TCP keepalive constants lowered:
CURLOPT_TCP_KEEPIDLE from 45 to 5 and CURLOPT_TCP_KEEPINTVL from 30 to
5. Before it'd trigger a keepalive packet after 45 seconds of connection
idle time and then again every 30 seconds. Now it triggers a keepalive
packet after 5 seconds of connection idle time and then again every 5
seconds.
It makes the client more resilient against coin switching pools or just
pools with connection issues in general. It will however add a tiny bit
pressure to the pool server; but a TCP keepalive probe is only about
60-80 bytes, so I don't think it is an issue.