Bitcoin Forum

Bitcoin => Mining software (miners) => Topic started by: Xian01 on May 02, 2013, 01:15:38 PM



Title: Best Practices: Stratum Mining Proxies ?
Post by: Xian01 on May 02, 2013, 01:15:38 PM
 I have a farm of getwork GPU's funneled through BitHopper 2.6.2 to give me an "at-a-glance" view of what's happening with each of the miners in my farm by HTTPing to a local stats page.

 With pools starting to phase out getwork, might anyone recommend a solution for proxying/managing multiple miners over Stratum ?



Title: Re: Best Practices: Stratum Mining Proxies ?
Post by: Zanatos666 on May 02, 2013, 01:31:51 PM
Im pretty sure that is one of the main reasons why pools are going to stratum, because its supposed to be pool-hoping proof.


Title: Re: Best Practices: Stratum Mining Proxies ?
Post by: Xian01 on May 02, 2013, 01:38:30 PM
Im pretty sure that is one of the main reasons why pools are going to stratum, because its supposed to be pool-hoping proof.

To be clear, I am not looking to hop; looking for a central place to get an at-a-glance view of what's going on with my farm rather than having to rely on site stats to manage my miners.

To my understanding, pool-hopping-for-profit is pretty much infeasible, presently.


Title: Re: Best Practices: Stratum Mining Proxies ?
Post by: Zanatos666 on May 02, 2013, 01:53:39 PM
Im pretty sure that is one of the main reasons why pools are going to stratum, because its supposed to be pool-hoping proof.

To be clear, I am not looking to hop; looking for a central place to get an at-a-glance view of what's going on with my farm rather than having to rely on site stats to manage my miners.

To my understanding, pool-hopping-for-profit is pretty much infeasible, presently.

I see, well the combating of pool-hoping may have unfortunately for you also, for the time being, hamstrung your ability to do this as well.


Title: Re: Best Practices: Stratum Mining Proxies ?
Post by: ahitman on May 11, 2013, 09:54:59 PM
Stratum has nothing to do with pool hopping. A pool is susceptible to hopping if it uses a proportional payout system (some other system may be affected to a lesser degree). This is not based on if they use getwork or stratum to give out work to the miners.

One way the stratum mining proxy is valuable is to allow a client that does not support stratum to mine at a stratum only pol via the proxy.


Title: Re: Best Practices: Stratum Mining Proxies ?
Post by: ahitman on May 25, 2013, 12:10:49 AM
I have a farm of getwork GPU's funneled through BitHopper 2.6.2 to give me an "at-a-glance" view of what's happening with each of the miners in my farm by HTTPing to a local stats page.

 With pools starting to phase out getwork, might anyone recommend a solution for proxying/managing multiple miners over Stratum ?



Sorry that this thread was killed, but I am too looking for a software that will allow at a glance view of your farm, but I also would like to keep track of workers shares as well so I know how much each gpu mined seperatley. Did you find a solution for your problem Xian01?


Title: Re: Best Practices: Stratum Mining Proxies ?
Post by: Nemo1024 on May 27, 2013, 05:23:19 PM
I use mining-proxy (https://github.com/CryptoManiac/stratum-mining-proxy) for getwork-base pooler's cpuminer against stratum-only Give-Me-LTC
This proxy supports both sga256 and scrypt protocols, so it might come in handy for your needs, in conjunction with your existing software.


Title: Re: Best Practices: Stratum Mining Proxies ?
Post by: HellDiverUK on May 29, 2013, 07:44:06 PM
Another query - I use the mining_proxy from slush's, but I'd be happier if there was a mining proxy that did failover.  I used pool failover on cgminer, but when cgminer is running through a mining proxy, it doesn't fail over when one of the pools craps out.  I use the proxy to keep rejected shares down due to a lumpy internet connection.

So, mining proxy with pool failover?  Or am I missing something.


Title: Re: Best Practices: Stratum Mining Proxies ?
Post by: Nemo1024 on May 31, 2013, 09:51:37 AM
I have an idea how this can be achieved. Run 2 or more mining proxies against different pools on different ports and configure cgminer to fail-over to a proxy on another port, thus effectively switching to another pool. Here is mining_proxy help (use different -sp and -gp values for each proxy instance):
Code:
D:\local\Bitcoin\cpuminer>mining_proxy.exe --help
usage: mining_proxy.exe [-h] [-o HOST] [-p PORT] [-sh STRATUM_HOST]
                        [-sp STRATUM_PORT] [-oh GETWORK_HOST]
                        [-gp GETWORK_PORT] [-nm] [-rt] [-cl CUSTOM_LP]
                        [-cs CUSTOM_STRATUM] [-cu CUSTOM_USER]
                        [-cp CUSTOM_PASSWORD] [--blocknotify BLOCKNOTIFY_CMD]
                        [--socks PROXY] [--tor] [-t] [-v] [-q] [-i PID_FILE]
                        [-pa POW_ALGO]

This proxy allows you to run getwork-based miners against Stratum mining pool.

optional arguments:
  -h, --help            show this help message and exit
  -o HOST, --host HOST  Hostname of Stratum mining pool
  -p PORT, --port PORT  Port of Stratum mining pool
  -sh STRATUM_HOST, --stratum-host STRATUM_HOST
                        On which network interface listen for stratum miners.
                        Use "localhost" for listening on internal IP only.
  -sp STRATUM_PORT, --stratum-port STRATUM_PORT
                        Port on which port listen for stratum miners.
  -oh GETWORK_HOST, --getwork-host GETWORK_HOST
                        On which network interface listen for getwork miners.
                        Use "localhost" for listening on internal IP only.
  -gp GETWORK_PORT, --getwork-port GETWORK_PORT
                        Port on which port listen for getwork miners. Use
                        another port if you have bitcoind RPC running on this
                        machine already.
  -nm, --no-midstate    Don't compute midstate for getwork. This has
                        outstanding performance boost, but some old miners
                        like Diablo don't work without midstate.
  -rt, --real-target    Propagate >diff1 target to getwork miners. Some miners
                        work incorrectly with higher difficulty.
  -cl CUSTOM_LP, --custom-lp CUSTOM_LP
                        Override URL provided in X-Long-Polling header
  -cs CUSTOM_STRATUM, --custom-stratum CUSTOM_STRATUM
                        Override URL provided in X-Stratum header
  -cu CUSTOM_USER, --custom-user CUSTOM_USER
                        Use this username for submitting shares
  -cp CUSTOM_PASSWORD, --custom-password CUSTOM_PASSWORD
                        Use this password for submitting shares
  --blocknotify BLOCKNOTIFY_CMD
                        Execute command when the best block changes (%s in
                        BLOCKNOTIFY_CMD is replaced by block hash)
  --socks PROXY         Use socks5 proxy for upstream Stratum connection,
                        specify as host:port
  --tor                 Configure proxy to mine over Tor (requires Tor running
                        on local machine)
  -t, --test            Run performance test on startup
  -v, --verbose         Enable low-level debugging messages
  -q, --quiet           Make output more quiet
  -i PID_FILE, --pid-file PID_FILE
                        Store process pid to the file
  -pa POW_ALGO, --pow-algo POW_ALGO
                        Proof of work function