Topic: [ANN] profit switching auto-exchanging pool - www.middlecoin.com - page 460. (Read 829908 times)

h2 my adress is: 1Mrabmk8ptVFwA2Ca28o8vnP9X5hGDMmtF

Can you please check why I have coins stuck?

It made sense to me.. If BTC =  $100 and you get here at Middlecoin say 0.05  and then BTC goes up to $150 and you get here just 0.03, while it "Looks" like you did bad at middlecoin on the 0.03 day, you actually got the same $ amount...  But this would mean the lower the price of BTC, the more we should get payed daily at Middlecoin?  Or at least it should Avg out that way over the long term?

No, altcoin diffs grow too and their prices drop, so less BTC per day and the USDBTC growth does not compensate those.

I am reaching the 'end of the experiment' point with 13mhash as well. Yesterday's payout, after operating costs are deducted, was about $3.

I have been on the pool exclusively for about two weeks now, so this isn't a snap judgement.
Returns haven't been above average except for 3 of those 14 days. Something isn't shaking out correctly.

Yes, that would be even better.  I was just looking for a swap-out solution that would be easier to implement and solve most of the problem to save your time.

my assumtion would be that this pool would be best design for people with sub 5mhash as generally that would only be a few rigs to manage - the bigger guys would have more time to supervise as i expect they like to monitor the nuts and bolts of their rigs too - my rig has been setup and i leave it alone apart from maintenance - if i had 10 of them i'd guess that i'd need more time to monitor them all and i'd probably end up micromanaging the rigs and probably spreading them accross several mining pools instead of having the eggs in one basket of throwing 20 rigs on one pool.

Probably a wise choice.  I think this pool is better suited for a smaller hashrate.  I think if it was maintained at around 200-300MH/s then it would be more profitable for the miners... h2o naturally would like to see much more than that, though.  I hope he can develop a way to split the hashrate among coins soon, because that should increase profitability.

I think myself & 2 other 40mhash miners have reached the end of the experiment

Overall we are down ~ 5-7 % (straight LTC) and dropping .. for the 10days

I dont understand why there where times when there should have been more... but long story short its not for us

We will do our FTC\LTC shuffle ourselfs

Altcoin mining is reaching the non-profit point (even with my 0.08 USD/kwh electricity rate). BTC diff keeps climbing and altcoin prices keep dropping.

That's weird. No, I haven't implemented PPLNS.

As for the BTC estimates using the last trade price, I need to fix that to use volume adjusted buy orders, like the switching code does.

Upon further reflection, I would think that using the current top bid or ask would be far better than last sell for thinly traded coins, as the last sell will ping-pong back and forth between the buy and ask prices which may have considerable distance from each other. This price jumping causes a significant oscillation in your reported in-process figures from report to report that obfuscates the underlying mining profitability results (in the short term). I would probably select the highest bid, as you are naturally a seller so this is the true current value of your holdings. A miner that truly wants visibility to his mining proceeds at a finer level considers in-process mining balances in addition to their paid BTC, which yields a more accurate conclusion about the profitability of your pool when making short term decisions (like whether to stay after a day or 2, or how am I doing today). When you factor in the in-process proceeds you naturally get a more stable profit reporting than payouts or balance alone, but not if it's too jumpy.

For example (just to be clear),
24 HOUR PROFIT = Today's paid BTC + SUM(current in-process balances ) - SUM(in-process balances 24 hours ago)

A small point, and just my 2 cents.

On a separate note, it would appear that you have now implemented PPLNS type logic or at least logic that has a similar effect. As an experiment, I had my son point one of his rigs at your pool for a 48 hour period to a new wallet address. At the same time, he already had an identical rig mining on your pool for many prior days for which the returns had already stabilized.  When the new rig was added, hourly productivity was compared between the two identical miners. The second (new) rig's return was very low for many hours as compared to the existing rig (factoring in all balances and mining side by side), and then gradually came up to a similar level of hourly productivity of the first rig after a day or so. To complete the experiment, the new rig was then removed, and its wallet continued to earn new mining proceeds (immature, etc) from your pool many hours after it was no longer mining.  Even with the after-effect, total returns from the second rig never quite reached (in aggregate) what the first rig earned during the 48 hour mining period. This is only a single data point with other unmentioned minor factors and as such is not statistically valid, but have you implemented something that would have this delay effect? If PPLNS, how do you calculate since there are many different coins and productivity is different for different coins for the same miner?

This is by far the worst day ever. My stats right now are the same as yesterday at the same hour. This means that in last 24Hrs I have mined 0.029 BTC with 2Mhash. Seems this pool operates better when btc is down with altcoins up, gonna wait for that moment again.

Anyway h2 keep up the work!

can we NOT mine nvc or whatever it is that sits unexchangeable for a few days?

Awesome... Just need a ltc payout variant now!

Thinking gonna be a bad day. Looks like I'm gonna hit under what could have been done with litecoins.  And don't get me started on Bottlecaps. 😛

+1

Is there any data available that illustrates the daily payout of middlecoin vs simply mining LTC and converting it to BTC?

would it help IF you ran two copies of the pool on separate IPs and round-robin the middlecoin.com domain to both IPs? that way you'd halve(ish) the hashrate per pool and could separate each pool from which coins you mine with? the only issue i can see is centralising the reporting stage?

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.


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.

The price to use for determining what coin to switch to.


The value of new coins before maturity, plus mature coins that haven't sold yet.


Yes, that's right.


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