Quote from: suchmoon on June 05, 2014, 03:01:47 AM

Quote from: kenshirothefist on June 04, 2014, 07:59:12 PM

Quote from: phzi on June 03, 2014, 07:47:34 PM

If WafflePool took this same idea, but instead waited for authentication, checked the user's pre-defined algo weights, and rejected/accepted auth based on the best algo, we would have a pretty excellent multi-algo-profit-switching pool =].

I'm very glad that other pools are interested in multi-algo as well. I'm definetly interested in common brainstorming and development in improvments in either stratum protocol or mining software, or both - whatever that could lead into efficient algo switching at miners side. Let's share ideas in the new sgminer thread https://bitcointalk.org/index.php?topic=632503.0 (or somewhere else).

BTW: regarding pre-defined algo weights - well, besides the hashrate ratio which is more or less equal for all miners, the only interesting weight is electrical power consumption. Unfortunatelly, electricity power consumption is not linear to BTC/GH/Day ratio calculation (exponential function with measured staring point should be used, and since miner doesn't know the current price ratio, he can't set power consumption weights). See also this example https://nicehash.com/multialgo/power-factor-calculation_x11.xlsx ... you can play with the numbers and you'll see that it is not trivial... but if you can come out with this logarithmic formula, please, do share it with me Wink

... If we find this formula then we can introduce epp (electricity power price) parameter and evaluate it in the profitability formula.

I think you are overcomplicating the power problem. The miner knows (well - needs to know) two facts about each algorithm: hashrate of the rig, and cost to run that rig. Cost to run should be normalized to a certain period - per day would be probably most convenient since we are used to calculating earnings as BTC per MH/s per day. It doesn't have to be just power cost, it could be rental cost or whatever the miner's expense is. So for example a fairly common GPU rig of 4x 280X would be:

X11: 12 MH/s, 0.002 BTC/day
X13: 9 MH/s, 0.002 BTC/day
Scrypt: 3 MH/s, 0.003 BTC/day
Scrypt-N: 1.4 MH/s, 0.003 BTC/day

This is enough information for the pool to determine which algo is best for that specific rig. I don't think there are any exponential functions involved here. Just find a way for the miner to supply that information to the pool - two numbers for each algo - whether via stratum protocol enhancements, or via password field (hate that but whatever gets it going).

If you want to make it easier for the miner you can provide a calculator on the website where the user could enter power consumption in Watts and power cost per kWh and get the BTC per day value, and even provide a list of typical rig configs to choose from, downloadable config files etc. BTC/fiat exchange rate is not that significant, because relative cost for each algo will remain roughly the same if BTC goes up or down, only the miner's absolute profit will change.

Why bother pinning calculations to absolute currency values at all if they are guaranteed to be inaccurate as soon as the next market trade goes through? (And you even realized that by the time you finished writing your post!)

All an alternative algorithm miner would need to pass to the pool server is its own unique calculated efficiency factor, relative to Scrypt10.

The blissfully ignorant will ignore it and the pool server can use its own assumed algorithmic efficiency factors, exactly as it is doing now.
(0.50 for Scrypt11, 4.00 for X11, 3.00 for X13, etc.)

Others who are more aware of their miner's alternate algorithmic hash rate ratios can override those assumed values with more accurate ones.
(e.g. 0.48 for Scrypt11, 3.90 for X11, 2.90 for X13, etc.)

And those who understand the concept of hash rate production costs can scale the efficiency factor value appropriately.
(e.g. 0.48 for Scrypt11, 5.20 for X11, 3.87 for X13, etc.)

Miners will probably have to configure unique worker names (which would need to remain consistent across all the algorithms configured for each mining rig).

The pool server will probably have to cache each worker's efficiency factor for each algorithm for an appropriate amount of time, as each mining rig can have a different set of algorithmic efficiency factors, and the efficiency factor for each algorithm would arrive individually on separate sockets (if specified via password parameter, as has been typical so far).

Or you could just automate pool selection on the client side as I have been doing for quite some time, and will probably continue doing long after anything like this is implemented. But it would be nice to have something to fall back on when your web sites are under attack and the relevant information on them (or via api) is temporarily unavailable.