I don't think the data was "destroyed". The data was adjusted, and in my opinion, for good reason.

The recent payout by Middlecoin had a large component that included the flushing out of a lot of unexchanged coins by miners that have not mined in many days, weeks, or even months at Middlecoin. This was one of the many problems with Middlecoin in that various account balances were not being flushed to the miner once they stopped mining. Large balances, yes. Small balances, not so much, as they appeared to be "stuck". That is why the unexchanged balance (blue in Middlecoin graph) was so enormous for a long time now. Finally, a couple of days ago, these small balances for thousands of these miners were all flushed out. This spike event should not be included in things like poolpicker because it distorts the graph and has nothing to do with current or even recent mining proceeds, which is the purpose of the graph.

If H2O communicated a bit, he could advise the amount that was current and perhaps a better data adjustment could be made by the person that makes the graph, but he chooses silence and auto-pilot so the current graph is the result. Some of the unusual component of the payment may have been recent and should be included if it wasn't.

H2O had a great pool. This is no longer true in my opinion. It used to have the best returns and H2O was great. For well over a month or more (since back when all the crazy hate thread postings), Middlecoin has gotten much worse and H2O has disappeared. I have mined at all the major pools for multiple time periods, comparing payouts with identical rigs, switching around only after carefully analyzing days of data. Middlecoin now has erratic and clearly lower returns in addition to the worst support by far. Like others that have posted recently, I am really surprised that folks still mine here. Many must be on auto-pilot and don't know the difference. Be aware that once you move off of Middlecoin you can get a distorted view of payments if you don't wait a few days for balances and rates to settle due to the many conversion transactions in process at both the new and old pool. Other pools also pay faster and Middlecoin frequently takes quite a period of time to flush the coins to the miner, providing a falsely inflated view of Middlecoin returns to the uninformed miner that switches over short time periods. Sometimes configurations need to be adjusted to maximize other pools. Perhaps Middlecoin still works best for some kind of miner, but none that I am familiar with.

My best to H2O; sorry to have lost him.

Really ignorant question:
I don't know how to run python scripts. Could anyone point me to a tutorial which might tell me how to run the script to see how many words I've written? Additionally, which script is it? Is it devtome.py?

Thanks.

Thanks for the info. Unfortunately, they are dead due to a lack of mining support.

Quick question:
Normally the files which keep track of word count are updated regularly (every day, usually). However, the file for round 30 (http://d.evco.in/charity/devtome_earnings_29.csv) has not been updated since the 14th of November. This might be a really ignorant question, but how can I see how many words I have written (where is there an updated file/is there one)?

Thanks

My LTC address for bonus is LM9hZr1fHSV2ehoveZ2vTthu1tacGW5Wkz

There is a lightning storm where I am right now and I have lost power. Because of this, I am not mining right now but I will power up my miners as soon as my power comes back .

EDIT: Power is back on but cgminer keeps crashing on one of my rigs so I am currently running at only 1.5 Mhash. However, I am working as fast as I can with regard to getting the other rig back online.

EDIT 2: Power died again and just came back on. One of my rigs works but one rig has a fatal problem so I will reload the OS tonight.

EDIT 3: Back alive now on all, hopefully for good..... what a mess....should be back to >4 Mhash now

Bitcointalk.org and LTCRabbit username: cryptopi
I have just started mining with >3 MH/s and we'll see how it goes!

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.

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?

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 you use for what specifically? The value of coins on hand when reporting miner proceeds? The value of new coins as they are mined before maturity? The value to compare against other currencies for mining profitability calculations? Please clarify.

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? Also, what price do you use when reporting the freshly mined coin value to miners?

The issue is not whether you only mine "1 BTC of buy orders for 1000 CGB", but buy orders at what price? Do you only take into account buy orders that are more profitable than mining the next best currency, or which specific buy orders? I would strongly argue that only buy orders that are at a price near/above the point that represents the next best mining opportunity should be mined/filled, and should be done so immediately. These represent the highest profitability available in the market, period. Waiting to sell is risky business, as the arbitrage opportunity may be fleeting as others will also be looking to correct this market inefficiency. There are additional practical implementation details, but this is the essence of what in my opinion would be a best practice.

If your calculation only takes into account the most profitable (more profitable than the next best coin) buy offers and not all buy offers, then you are not overmining, but you are gambling a bit on the future price action of the coin. Could be risky business if BTC keeps going up, as you are on the wrong side of the trade. I agree that it can win under certain circumstances, but various of these coins are volatile and why take the risk?

There are several factors at play here. 

1) As stated by others, rising BTC prices can have a dampening effect on the ALT/BTC exchange rate of the alt currencies, which may or may not balance out in fiat (generally not, I would think).

2) Another significant factor is that the size of this pool is undermining some of its success. This is due to 2 factors listed below:

2A) If you look at the moment by moment transactions in the pool, you will see that the pool's logic does not have the appearance of only mining while there are profitable open bids for a coin. Rather, it mines a bit longer and the pool's trading logic attempts to sell the coins across a longer period of time so as not to dramatically affect the price received.  As hash rates increase, the overmining (if you can call it that, more like mining in excess of the high open bids) increases, and the pool tends hold more coins that take longer and longer to dispose of.  During this time, the coins are frequently dropping in value (due to point 1 above - the rise in BTC) and so eventually must be sold at a less profitable position that originally intended.  This is the inherent risk of mining in excess of open high (profitable) bids (which for a pool of this size, can be a very short time). If you watch your value closely (adding together all columns of your mining proceeds) you will see this frequent repricing of mined coins taking place (some due to this dropping price and some due to simple overstated pricing). Some of this is unavoidable, but it happens a lot at middlecoin. Not a terrible decision on the h20's part, but it will have this very side effect, which can get more pronounced as the pool size increases. The pool, in essence, bets on the future price of the coins it mines by holding out for a better price (waiting for bids to show up). Profitabililty would be higher if this were not done (in my opinion), but it would take a bit of programming. The current "hold out for a better price" strategy might be a little more successful in a declining BTC market, but is still unadvisable from my point of view, as no coins should be mined that are not convertible for a profit immediately given existing buy orders. The pool should lock in certain profits and move on. Also, some of this "overmining" is inevitable as it takes time for the coins to mature and prices can change.

2B) Another factor is that the very nature of the pool and its size keeps alt coins from getting very far out of whack (from a mining/profitability standpoint). Any that get too profitable quickly get beat back to the common denominator (~LTC profitability) as the pool mines them, and then the pool moves on to the next. In the earlier days of the pool, these anomalies took longer to correct due to the lower hash of the pool which led to greater anomalies and higher profits; now not so much.  The newer/cheaper coins are quickly repriced and the opportunities for a large pool like middlecoin are diminished.

Middlecoin is still a great pool, and no doubt there are additional factors, but off the top of my head the above listed factors play a significant role.
 

Stats (main) page doesn't appear to be updating for an hour now.... working for anyone?

Are the MiddlePool numbers only for accepted mh/s or total? For Litecoin, accepted/total may be the same, but not on MiddlePool. I have seen that it has lots of rejects sometimes when I looked. If I solo mine Litecoin with 1 mh/s, I get .0213 BTC as there are very few rejects, but when I mine at MiddlePool with the same rig that gets 1 mh/s at Litecoin, MiddlePool frequently reports less than 1 mh/s total (accepted plus rejected), and obviously less accepted than the total. So, I always get somewhat less than 1mh/s total and considerably less than 1mh/s accepted at MiddlePool from a 1 mh/s rig, which I think means I get less than the numbers you show for MiddlePool when compared to Litecoin? Is this correct or am I missing something? Thank you. I like your pool and am using it with my rig but I don't really have numbers to compare with yours because I'm down quite a bit.

And 7950s provide an even better price/performance these days (I believe)

Yeah, I just realized why it did not work. It said it was done syncing and the I started to mine. However, it did not really sync because it discovered another 25k blocks and then started to sync those. Basically, every few minutes it discovers another few thousand blocks that have to sync. It is quite odd and at this rate, it should take roughly a few hours to sync. Is it supposed to take this long?

Also, I have another question. I just downloaded the wallet onto one of my computers and it just finished syncing. When I opened the debug console and typed setgenerate true -1, nothing happened and my CPU usage is still at 5% or so. What happened? How do we mine this from the client?

Thanks

Ok. As soon as you find an alternative method, can you please post it here?

So is the only way to mine this directly from the wallet client with CPU?