us3.eclipsemc.com is open for testing.  Port 8337.

Let me know if anyone encounters any problems. 

Yes, it would be a disaster to manage and adds complexity where none is needed.  The solution:  Don't mine on a proportional pool.  Problem solved.  No mathematical magic or acrobatics needed.

Definitely switch to US2.  US1 is just overloaded.

I will likely be rolling out a US3 shortly as well.  I want to make sure US2 is working properly before I add the code for the third server.

Payout difference was about 1% per user between the invalid and next block, which would account of decay time if you did not factor in the invalid block.

I will consider how best to handle (if at all) an invalid block insurance plan.

Well, I can institute something like an "invalid block insurance" at 3% "fee"... I hesitate to call it a donation, though, since a donation implies of someones free will.  But like a couple pools have done in the past, they insure against invalid blocks with a forced donation of x amount.  I'm certainly open to this if there's enough demand.


Nope, there's no less than normal pay on invalid blocks, unless you mean 0 pay?  As much as I'd like to pay out on invalid blocks, I can't afford to pay 50 BTC out of my pocket.  I'm not really making money on running the pool and my Ferrari is sadly still on layaway.  Actually, I'll settle for an Lotus Exige or Ariel Atom at this point. 

I'm not sure I understand your question with regards to the block chart being wrong?

As far as the averages, there's a few different ways you can look at an invalid block and each are equally valid but produce very different results.  The convention, perhaps set by Deepbit and Slush et al in the beginning is to acknowledge invalid blocks as being a separate legitimate entity.  From a purely continuity standpoint, this should not be so and invalid blocks should never be acknowledged as existing in the first place as far as pools go - thus they should just be passed over and the current block continues as normal.

Convention and technical limitations make this more difficult in so far as it takes time for a block to be realized as invalid, so unless the pool delays the stats, an invalid block shows up in the chart until it's invalidated by the network. 

So, as far as luck goes for both the invalid and current block, since it's acknowledged as a separate entity from the current block, it takes with it it's luck.  It's ultimately a semantics game, and through convention and technical limitations, you get what you see.  If people would prefer another method/display/semantic convention, I am happy to oblige, I just chose the current method because that's what people are already familiar with and I am definitely not trying to hide anything.

I would like to point out, with this latest invalid, we are right under the "average" as far as invalids go, since the start of the pool (400 blocks * 1.5% = 6 invalids).

I'm not going to touch the servers again tonight, so reset your miners if it's not too much of a hassle and see how the stale count tracks.  If I do happen to have to restart the server(s) or if there is a problem with them, I will post here when the problem/reset occurred.

That might have been about when I reset one of the servers ... but I thought it was a bit longer.  In either case, it shouldn't have been down for more than a few seconds and both servers (us1 and us2) are up and taking requests right now.

I did make a DNS change, but it was just to add us1 to the dns table, I did not remove or change any existing records.

Not for awhile now (an hour at least) - why?

No, the My Workers page stales is not calculating right.  I wanted to get the stales under control before I looked into what was going on as far as why it's not calculating right.  

In addition to that, when I restart the server, your client counts all the rejects and the server doesn't, so you'll get less listed on the server vs what's listed on your client.

And lastly - I think most clients increment the reject counter for any reason - the server only increments the counter for actual stales.  So unknown, duplicate, etc... does not get counted.

DGM is completely hop proof.  There are only two pool that have DGM.   EMC and OzCoin.  The only other one that was around closed up shop (and OzCoin is now running their software) so either you mined on EMC or on OzCoin/yourbtc.  If you mined elsewhere, you did not mine on a DGM pool.  While I can't speak for OzCoin, I can speak for EMC and the hashrate does not change at the start of a round much to speak of on EMC.  Even if it did, there is no benefit (or drawback) to hopping a DGM pool - you simply get paid a fair reward for what you put in.

There's a common misconception about the rationalization of hopping as "helping to complete a block."  The number of miners attacking a block does not change your chances of solving a block.  It's still 1 in 1.25 million or so at the current difficulty.  Whether you have 10 people or 100 people mining, your chances are still the same.  Each share has a 1 in 1.25 million chance of solving the block.

The *only* thing hoppers do, other than enriching themselves, is reduce the income of people mining past ~40%.  There is absolutely no added benefit to hoppers on a pool.  When they are there in the start of the round, if you find a block, they are like any other miner.  When they leave after ~40%, they take them them an additional profit not realized by the miners who stay.  They add no positive benefit to the pool.

Sorry, US1 and US are synonymous at the moment.  US2 is the only new hostname available.

I'm not familiar with the Phoenix miner ... does anyone know what that error indicates?

Ok... I made some changes to US2.  Let me know how that affects stales on US2 specifically and also possibly US1.

Ah, yeah... that's right.  LP was having problems on all severs. 

I am going to disable port 9009 at some point, so switch over to port 8337 on either US1 or US2 as soon as possible.  US2 will be replacing 9009, and I may add a third server, depending how things work out.  All severs will be on 8337 though.

I am going to be making some changes later today that should help with the problem.  I will have to bring US2 down for a brief period of time to make the switch.  Probably won't be a for a few hours yet.

Yes, there was a problem with LP on US2.  This change should also address that.

Yeah, I'm going to blow away the stale code and rewrite it for reporting... just as soon as I figure out why the stale rate is so high for some people... but I think I have an idea now.

I'm still evaluating the options and trying to pin down the specific bottleneck.  I think I have a bit of a lead.

ocminer: The last few days are going to show a higher reject rate simply because I've had to start and stop the server so many times.  There is definitely something very wrong with the stale count on the My Workers page.  I just reset my workers several hours ago, and for example, I have a Reset sharecount on a worker at 2095 and a round count at 2590.  But my stale count on round is only 8 and it's 51 on reset - this is impossible, heh.

For the life of me, I can't figure out how the reset count is getting out of sync with the round count.  The round count seems to be correct, or at least more correct, though I'm not sure it reflects reality either.

I'm going to reset some of my miners tonight and see how they match up with what the My Workers page is telling me.  Maybe that'll give me something to go on. But for now, you can and should totally discount the stale count under My Workers. 

Can you guys tell me how your rejected share counts compare to your stale counts on the My Workers page?  I think there may be something wrong with the way stales are being counted - as in they are being incremented even when no stale was received.

I'm showing a higher stale count since reset than for round, which should be impossible if the reset happens after the round starts, yet it seems to be happening and I can't quite figure out why.  I have a few suspicions though.

I just swtiched the pool back to the original bitcoind to see if that fixes the stales issue.  I'm not sure why it would have increased stales and perhaps it's unrelated, so I'll monitor it over the next 24 hours and see where we are at.

Coblee: Sure, I will see what I can do to get that in.