Moved the develop code to master. Moving forward all updates will be
done on master unless it's work on a major feature.
This update contains all previous develop code as well as a few new ones
that weren't pushed yet:
* Added neoscrypt compatibility for xintensity/rawintensity
* Neoscrypt now uses correct TC if not specified or set to 0
* Reworked the application of pool settings on algorithm switch which
should resolve TC/Intensity changes between algos such as X11 and
neoscrypt
Fixed an issue where the GPUs would be initialized on first pool alive,
but the mining threads would end up being initialized on another pool
because it was selected right away.
From curl CURLOPT_ERRORBUFFER docs: You must keep the associated storage available until libcurl no longer needs it. Failing to do so will cause very odd behavior or even crashes. libcurl will need it until you call curl_easy_cleanup(3) or you set the same option again to use a different pointer.
Might have introduced a memory leak, don't have time to check. :(
Should the other hex2bin()'s be checked?
Thanks to Mick Ayzenberg <mick.dejavusecurity.com> for finding this.
Thanks to Mick Ayzenberg <mick@dejavusecurity.com> for reminding
that this existed and highlighting the offender.
Also to Luke-jr for actually fixing this in bfgminer. :D
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. :)
