Regarding mining.capabilities:
The second parameter is an Object with key/value option pairs. Wouldn't this be better (example how to tell about certain mining capability + give some parameters):
mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : []])
In this case, for set_multialgo, we would use parameter list as following:
mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : [ "scrypt-performance" : 1.0, "scrypt-cost" : 0.001, "neoscrypt-performance" : 0.3, "neoscrypt-cost" : 0.001 ]])
This way, miner can tell to the pool exactly what kind of algorithms it would like to work on and what kind of speeds (performance) it has and costs related to it - pool can then take these factors and make proper calculation and assign miner to algorithm that is best for the miner.
Isn't this something you can have users configure on your website?
I would think that when costs are known to BFGMiner, it (and not the pool) should be making the decision about which pool to be mining on based on costs.
I suppose it makes sense to tell the pool as well, so it can try to offer the best deal...
Perhaps more importantly: those options are independent of support for the set_goal method - they're parameters for each algorithm.
How about we take your idea, but with some minor changes to these options?
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}})
This way if methods have specific parameters, they don't need to be duplicated, but each algorithm is considered an independent option.
Note it's set_goal rather than set_multialgo for a reason - I'm hoping to add support for non-blockchain non-PoW goals at some point
As long as it doesn't bring any ambiguousness to future possible extensions of this method, it is fine for me. But I would still rather "group" all supported algorithms together.
So maybe:
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}}})
Also, what should be considered is the possibility to omit 'cost' - in that case, cost is considered as being 0. Following this logic, omitting performance, sets algorithm speed to 0 which means "don't ever send me jobs for this algorithm".
Well, that wouldn't work. Most of the time (at least right now, all of the time), cost and performance are unknowns - so BFGMiner has nothing to send for those.
In practice, I was thinking of sending:
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":[],"SHA256d":[]}})
Another thing maybe we need to consider is how you would want to handle rigs that have a set of scrypt+SHA256d devices (CPU, OpenCL, maybe DualMiner in the future), and also SHA256d-only devices...
Miner should send mining.capabilities as soon as it establish connection with pool (before any other subscription or authorization) - that way, pool can properly assign miner for the first job already.
Yes, this is already the case.
If you send empty parameters without performance and costs, then pool cannot know what kind of performance of each algorithm is reached, thus cannot make decision which algorithm work to provide. Giving performance parameter is mandatory. I suggest to get performance by doing "benchmarking" of each algorithm prior actual connection to the pool - this is good also because people don't have to do manual measurements any more as they have to do it now. Cost should be still just optional and by default 0 - rare people actually set cost factors (looks like most GPU miners use free electricity).
When it comes to multiple miners that are capable of mining more algorithms at the same time; certain resource (let's assume GPU) is in most cases saturated 100% - if it is not, algorithm is not well coded. I suggest to simply run multiple instances of miners (one that takes CPU resource, one takes GPU resources,...) and establish multiple connections - of course, with each one having own list of supported algorithms with proper performance factors.
