Quote from: h2odysee on September 03, 2013, 04:28:10 AM

Quote from: cryptopi on September 03, 2013, 04:18:33 AM

I'm guessing, bit it sounds like you are saying that while mining coin A, you decide to keep mining coin A by comparing (every minute?) the price of the buy order for A that is X coins from the top of the buy order list (where X = on hand plus estimated proceeds from several minutes of mining), combined with coin difficulty, to determine if the current coin is better to continue to mine than other coins at their respective price/difficulty, using the same price methodology for the other coins? Is this correct?

Yes, that's right.

One thing that is not factored in this method is that others are also going to mine and sell the current highly profitable coin, likely causing you to not capture 100% of the high buy orders, so you might need some kind of moderate scaling factor for X. Although if you recalc every 1 minute, but use 3 minutes of mining proceeds in determining X, you already have a scale factor of 3. Other than that, seems like is a credible method in my opinion that shouldn't overmine, subject to thresholds and "change penalties" (i.e., the coin to change to must be Y% better than current coin before viable to mine to avoid thrashing), which I understand that you already use. It would be important to have a good feel for the "estimated proceeds" for several minutes of mining of each coin, as underestimating will cause loss of profitability.

The phenomenon that I reported observing while the pool mines low difficulty coins must relate to inaccuracies/volatility regarding reported coin pricing, which seem surprisingly large.

If you aren't already doing so, in my opinion it would be good (at a minimum) to have the code log the two key inputs to the algorithm - "expected number of coins mined in Q minutes" and "expected price" (using the X coins down in the order book method described earlier) each time a decision to change or stay is made, and compare manually (as time permits on a spot check basis) to the actual mining rate and eventual exchange transactions for all coins mined in the next few minutes of that coin to make sure that the calcs are fairly predicting the eventual volume and market prices, since either could be off for a given coin at a given point in time with obvious negative effects. Automated comparisons with exception reporting would be much better, but that might take a while to implement.

Quote from: h2odysee on September 03, 2013, 04:28:10 AM

Quote from: cryptopi on September 03, 2013, 04:18:33 AM

Also, what price do you use when reporting the freshly mined coin value to miners?

You mean, on the webpage stats, for the BTC estimates? I use the last sell price.

As you are likely aware, this will arguably tend to overstate values of thinly traded coins (when you hold inventory that you will be selling very soon) and be accurate for coins with deep markets. Not a big deal, but not factoring market depth into pricing unexchanged thin market coins will cause increased volatility in webpage stats, but of course will wash out when finally in BTC.

You should be able to measure the amount made/lost by your "wait for a better price" logic vs always "sell now at the current best buy orders". No need to guess, other than the time required to code up the calculations, which I understand may be in short supply.

Keep up the great work, I'm sure that there is a lot to do.