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
The API and UI functions to change intensity would update the gpu
settings directly without updating the config option strings. This
resulted in the intensity updates not saving in config files. This
update should resolve that problem.
Also added API functions to change xintensity and rawintensity.
Reworked how the config writer works to properly save the config file.
Sometimes settings would get lost in profiles.
Also changed algorithm switch to only perform a soft reset and lowered
the verbosity of the algorithm switcher.
Added X14 and cleaned up the X13/X15 kernels so all 3 offshoots are in
sync. New option "--hamsi-short" or "hamsi-short":true to add a small
boost. May not work on all GPUs.
Updated Algorithm switcher to change on pool rather than on algorithm.
This way if, for example, 2 pools use the same algorithm but different
GPU settings, the settings will be applied when changing pool.
Additionally:
* Included a "common" algorithm type in API pool/profile listing. For
example using "marucoin-mod" will return "X13", "darkcoin-mod" will
return "X11", scrypt + nfactor != 10 will return "NScrypt", etc...
* Added "kernel" config option to be backwards compatible with other
miners' configs.
* Added a few algorithm aliases: x11mod -> darkcoin-mod, x13mod ->
marucoin-mod...
* New config keyword: "includes", which holds an array of include files.
This is to counter the JSON limitation not allowing multiple values with
the same name, thus preventing inclusion of multiple files.
Fixed addpool to specify a profile or algorithm and sets defaults if
nothing specified. Also added a new API function to change multipool
strategy.
Conflicts (resolved):
sgminer.c
Config writer now supports profiles and pool specific values. In
addition, the config writer now makes use of the jansson library to
create proper json objects and save them to the config file. This is
much better than trying to write our own json code.
Conflicts (resolved):
sgminer.c
Updated the config parser to provide better readability and flexibility
in config files. The latest features introduced a really messy way to
handle config files and this update alleviates this by adding the
ability to create profiles and associate them to pools.
Todo: Update the config file writer, in-program options and continue to
break off the config parsing/command line option code out of sgminer.c
to reduce clutter.
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.
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
Closes#116.
This is trivial and shouldn't be so hard: it required modifying
functions in both sgminer.c (for NCurses stuff) and api.c. There is
much code repetition, since the NCurses interface is hard-coded in.
Removing it would simplify things greatly.
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. :)
troky