I have
proposal for stratum extension to support algorithm change without reconnects.
First, we need to normalize name of the algorithms; example:
scrypt, nscrypt, x11, x13, x15
Miner subscribes to server that it is capable of switching algorithms. It also sends parameter list. Each parameter consists of 3 parameters: algorithm name, factor and cost. Factor is speed in MH/s (it is only important to be relative to other provided factors of other algorithms), cost is daily cost of rig in USD.
Example for 2 algorithms:
{"id": X, "method": "mining.algorithm.subscribe", "params": [["scrypt", "1", "2.5"], ["x11", "4.2", "2"]]}\n
Server then calculates which is best algorithm for this rig considering provided factors and costs. Before any work is provided and on algorithm switch, server sends (example to switch to x11):
{"id": null, "method": "mining.set_algorithm", "params": ["x11"]}\n
Immediately after that server sends new difficulty and new work.
How about this extension is NOT messed up like extranonce subscription the first time around? Having a miner "subscribe" to calls that a server may or may not support makes little sense. The pool should inform the miner during connect that it supports this extension, and then allow the miner to respond with multiple algorithms if desired. Otherwise, when the miner sends your proposed "subscribe" command to a non-supporting pool, it is going to break pool connectivity (just like extranonce subscribe caused all kinds of problems for users).