Assuming the network as a whole is constant isn't entirely accurate though.  Looking at the charts at bitcoinwatch can show you the network can vary quite a lot.  One pool's up/down does not mean another pool is having the opposite.  However, the odds of consistently solving blocks faster than expected at a difficulty are the same as consistently taking longer.

I spent the last week going over the changes I had made to pushpool, trying to find some simple change I made that would've caused it to not push valid shares upstream to bitcoind, and I've come up blank.  I replaced the pools with stock pushpool [outside of db-mysql.c and a long-poll disable bit] the other day and it changed nothing.  Other pools are running JoelKatz's patches so I have no reason to believe that is causing any issues either.

Software side issues are ruled out.  The only thing itching in the back of my mind is the way the servers have been split up to run against their own bitcoind + wallet, but that shouldn't mean anything, especially when we've been doing the same thing for a long time and have shown ups/downs regularly in luck.  Splitting miners [and making sure they come back to the same server with results] across 6 smaller pools should have no difference in variance from all using one large pool as long as each pool is running different headers [receiving addresses] for the hashes.

Right now BTC Guild is forced to do some very awkward things to get pushpoold to scale to 1 TH/s per server.  I'm very interested in this project, but until the source is out I won't be able to give it any real-world testing since my DB Schema is very customized for faster reads/multi-server support.

Level3 in LA and Dallas are showing some packet loss on traceroutes to the server, which is causing a few idles for people who connect through those nodes.  Hopefully it will clear up shortly.

Just for the record, thats bad advice .  If the current price means mining is a loss, it would be 100% stupid to continue mining.  It would be smarter to spend the money buying coins and leaving the miners off, since I'd be getting more coins for less USD.

I sold off a large chunk of my miners a few weeks ago because I knew that this state would be one of the first places to become unprofitable.  I sold early before the mass hardware sales began .  Now I'm just running enough to make sure the pool is still running.

My silence on this matter has been the result of having 0 control over it.  I made my posts last time these threads started [which went away immediately when a few days later our luck surged the opposite direction for ~34 hours].

BTC Guild uses the following:

  Pushpool 0.5.1 [only modifications are adding in a long-poll disable bit to specific workers, and DB Schema changes].  6 smaller pool servers each running against their own bitcoind/wallet.dat file, so there is never "duplicated" work across the servers.

  Bitcoin 0.3.24 with JoelKatz's patches [upgraded to his 0.99 patch on Saturday]


So unless somebody finds a flaw in one of those two (pushpool or JoelKatz's patch), I can only shrug it off and wait for better days.  To those leaving over it:  I'll see you again after our next positive streak, just like what happened during the +54% day.

Regarding the 11m share round, within 24 hours of that round completing DeepBit reported a 16m round, just for reference regarding extremely long rounds.

Just impacted in my personal mining.  You'll notice User ID 1 (me) has almost vanished off the block rewards list.  I'm now just using 2 5870s to mine, at a loss.  California at top tier usage (my house AC alone puts me in top tier basically) is 40 cents/kwh, which is a loss before counting the cost of extra cooling.

The pool still operates at a profit, mostly thanks to the Google AdSense for people under 0.5% donations.


It's also throwing a wrench into my plan to offer some very good VPS servers at even BTC intervals.  Was planning on a ~$12 / 24 / 36 per month (or 1 / 2 / 3 BTC) set of VPS servers, with the BTC price only adjusted when the value went below 10 or above 15, with integrated billing with BTC Guild so you could automatically have your miners pay off your servers each month.

Pool had about 1-20 minutes (depending on which of the internal servers you were connected to) of downtime/restarts this morning, so if you received a huge chunk of rejects that is the cause.  I was setting up a dynamic sync script that can add/remove servers without a restart.  This was done as a backup in case the price of BTC continues to tank, I'll be able to move US West onto a second colo'd server in Texas if needed to save some money on server costs.  It would lose redundancy (both servers in the same data center), but it would allow me to cut back on costs instead of getting forced into a mandatory fee to keep the servers running.

The negative share counter is fixed, and the backlog of blocks were pushed out.  Looking into the logs to find out why the server block checking script exited without turning off the switch that prevents a duplicate of the script to run if it takes too long.  Essentially one copy of the script ran, and somehow it stopped running mid-script without removing that switch, stopping future copies from running.

Problems communicating with bitcoin RPC 0 2 isn't going to cause you much harm unless it ends up happening just before a long poll causing a stale.  It simply means poclbm tried to talk to the server and it didn't get a proper response, and tries again shortly after.  poclbm grabs work in advance, so you're still hashing away until the idle shows up (meaning it couldn't get new work in advance and eventually ran out).


I just re-routed a couple new botnets that showed up on both US Central and US East which were adding about 15,000 long poll connections worth of overhead/stress per server, so the comm errors should start to go away.  I'm also getting ready to re-implement my inefficient miner auto-ban for miners that are requesting tons of work but sending back only a tiny amount of shares.

All I can suggest is switching servers from Central/West to the other, and/or upgrading your miner.

Those look like per block averages?  Pool speed has been steadily increasing, meaning we make more blocks, but you make less per block.

Looks like there were some routing problems between Level3 and Corexchange in Texas.  Nothing that we can do about that, only lasted about 10 minutes from what I can see in my miner logs.

The 24H luck is slightly skewed right now due to the difficulty change.  We are definitely still positive, but not quite 70%.  We are certainly off to a nice start this difficulty though.

I'm looking into it, but I'm not rushing for the chance.  I personally feel that namecoins are a waste of space.  Their adoption will be limited to a subset of users even smaller than TOR.  At least TOR serves a purpose.

That said, I'm waiting to see if anybody modifies pushpool to work with merged mining.  Merged mining with pools is going to be very tricky to implement, especially when a pool is already up and running.

Slushes pool had bad luck, steady for most of the last week.  His response to you was accurate:  random chance.  No pool, regardless of size is immune to luck.

If a server sync fails, it means the old server is still recording shares on the prior round.  The sequence of events would be like this:
Server A and B are working on Round #1500.
Server A finds the block, updates to Round #1501, and tries to update Server B but fails.
Server A is now recording Round #1501 shares, while Server B is still working on Round #1500.
Server A finds a block before the fallback sync script executes, and updates to Round #1502, and updates Server B to the new round, skipping 1501 on Server B.

The rewards for #1500 would not be recorded until after server B had moved past that round, so Server B users didn't lose any shares, but they were applied to the Round #1500 instead of #1501.


This was only a "problem" when we were running with 7+ servers, where connection issues could easily occur between round synchronization.  It only happened a few times, normally between euro and US servers.  

Since consolidating to two servers, this has not happened.  The sync script is much more aggressive at retrying.  However, there is always a chance of it happening if something prevents the two servers from communicating a new block with each other, so I've left the warning there.

I guess they just couldn't let us have our record breaker .

It ended with a record breaker (for BTC Guild, I would bet someone out there has a higher one though).  Happy Block #2000 all.  Now lets not get stuck on one like that again.

The bitcoin gods really don't want us to get our 2000th block .

sharky:  All I can say is it's nothing I can do to fix it.  When idles do pop up, its because pushpool/bitcoind are generating a ton of work after an LP.  Normally an idle only shows up when two blocks are found rapidly on the network, and two long polls go out less than a minute apart.  Even in those cases, they normally don't show up.  Like I said, I have 4 miners split 2 per server, and have not had one idle today.

If you're getting them regularly, all I can say is go elsewhere.  I can't fix a problem that seems to be only be affecting you.  If the problem was with our servers at least 1/8th the users would be experiencing it, since the pools are roughly split up to be 1/8th the total load per internal server.