Topic: Development of a Stratum Proxy/Balancer/Gateway (Read 2262 times)

Slush's stuff is indeed fairly useful, being the creator of the protocol and all
I've started tinkering with this, although my time is currently quite limited, and
I haven't yet managed to set up a proper testing environment How would I
go about this? Getting a miner to work isn't much of a problem, but I haven't yet
had to setup a pool and all that.

I was searching if this piece of software exists and maybe all could be done with slush's stratum proxy available @ git repository https://github.com/slush0/stratum-mining-proxy. I will try it.

Platform independence would be a plus.

I'll be interested too.

I like the ideas. I'd be interested.

I would like to see a few different features in something like this.

The proxy should be able to have a full configuration object, meaning that it contains a worker password, name, pool data, etc.  The miner username/password should be irrelevant to what gets passed to the real server.

A load balancing system would be nice.  If I wanted to dedicate say 3GH/s to one pool and 5GH/s to another I should be able to configure this in some way and have some type of balancing engine in the proxy just fetch the shares and send them to  the miners as work becomes available.  Should track actual work units and apply the basic conversion rate when deciding which pool to fetch work from to make configuration parameters in hashes/second as opposed to having to specify the work units.  There should be a default parameter where all the slack goes.

The proxy should be completely stateless so that if desired a HA system could front end it.  

It should support stratum in a way that does not tie it to a specific crypto algorithm.  I realize I cant mix coin types but I could have a SHA256 one on port 1234 and a scrypt one on port 4321 where the only difference is the config files for which pools it will proxy  to.

A dynamic configuration would also be nice so that the proxy does not have to be killed and restarted to reconfigure things.  

I would be willing to contribute to a bounty if there are any interested people in developing this.  Since the framework is HTTP+JSON and some stratum libraries already exist it should not be terribly complex to do this.

Hey everybody,

I'm going to describe a development idea that occured to me today, and I'd like some feedback on whether this would be something miners could be interested in.

If I'm not mistaken, the current mining scenario looks something like this:


             +-------+
             |Worker1|+-------------------+
             +-------+                    |
                                          v
             +-------+  stratum+tcp  +--------+
             |Worker2|+------------->|  Pool  |
             +-------+               +--------+
                                          ^
             +-------+                    |
             |Worker3|+-------------------+
             +-------+


So the mining pool controls your workers (which is fine), but all your workers are completely tied to the pool, and you have no way of getting live statistics of your workers performance, other than what the pool may report to you (delayed as that may be). So I had the idea to develop the following piece of software, that acts as gateway between your workers and the mining pool:


             +-------+
             |Worker1|+-------------------+
             +-------+                    |
                                          v
             +-------+  stratum+tcp  +---------+   stratum+tcp   +------+
             |Worker2|+------------->| Gateway |+--------------->| Pool |
             +-------+               +---------+                 +------+
                                          ^
             +-------+                    |
             |Worker3|+-------------------+
             +-------+


Having a gateway between your workers and the pool has, in my understanding, a couple of advantages compared to being directly connected to a pool:

1. Your worker configuration can be pool-independent. For example lets say you have 10 workers of which you'd like to have separate performance statistics, but you don't really care if the pool you're mining in sees them as different workers. In this case, you could simply connect your 10 workers to the gateway and let them all seem like a single worker for the target mining pool. This is especially advantageous when switching pools, because you'd only have to change a single configuration parameter in the gateway in order to switch all your workers, no matter how many, to a new pool. Stuff like failovers can also be handled by the gateway, without the need to change your miner's configuration. An additional possiblity would be advanced routing capabilities for assigning certain subsets of your "mining force" to certain pools, e.g.: "Workers with name rad* -> stratum.goodpool.com"

2. The gateway should be able to provide all the graph-goodness you could possibly desire. This could, for example, be implemented through a web-interface. Said web-interface could also be able to configure your workers.

3. E-Mail or other notifications of certain events involving your workers.

So in summary, you'd move the configuration away from the machines actually doing the work, and put it in the gateway. I haven't been able to find something like this yet, but if it does exist please let me know

Thinking about this concept, I was wondering about the worker password mechanism. So a question for the miners: Do you actually have separate passwords for all your workers, and if so, why?

Cheers,
x3ro