Just posting in anticipation for those who just experienced miner idles:  Added another index to the shares database to speed up the calculation of worker hash speeds (was taking way longer than it should), which caused new work to be slowed for about 90 seconds.  It cut the time it took to calculate hash speeds down to less than 1/20th what it used to be, which will be noticeable as more and more workers enter the pool.

Will do.  Current list of improvements to be implemented tonight (PST time zone, so morning for some of you):
  1) Hide Workers
  2) Rename workers
  3) Reset worker password
  4) Optional email field for password recovery [and eventually for idle miner warnings]
  5) Optional SMS # field [will be used for password recovery and idle miner warnings once implemented]
  6) Personal block statistics included in the block listing [shares and reward]
  7) API settings to set what information the API reports

I'll be adding those stats to the block statistics this evening, as well as a hide worker.  Hidden workers won't appear in the list, or in the API, but their data will still be present if you wish to re-enable them.  That way the historical data is kept intact for all work done since the pool started.

I know bitcoinpool had quite a few invalids early on when they first started but haven't had as many recently.  Deepbit offers the same invalid protection as part of their 3% fee as well, and I doubt Tycho would keep running it if he was losing money.  As a smaller pool the risk is greater for me, but I think by offering these services at competitive rates I can make the pool grow fast enough to reduce that risk.

If the invalid rate is causing me to lose money to the point I'd have been better off mining personally at Deepbit/slush, I may adjust the instant rate higher (to cover myself on invalids), and then add a lower tier donation to receive payouts at 2 confirmations.

Your confirmed total includes the complete reward from your 2.5% blocks (example:
  A block is completed and your total reward for the block was 4.  You had a donation set at 3% (0.12), so the total amount you will receive is 3.88.  You can withdraw the full 3.88 immediately, without waiting for 120 confirmations.  The amount is put directly into confirmed rewards, and is available even if the block is later found invalid.

  When you click the 'Pay Me Now' button, your entire confirmed balance is sent to you, so if you had another 15 BTC in your confirmed balance before the 3.88 block, your payout will be 18.88 when you click the button.

  This weekend I'll be setting up an hourly automatic payment script so you can receive your BTC whenever it reaches 'X' amount, or every 'X' hours, depending on your preference.  The feature will be another "premium service" for anybody with donations over 1% in the previous 24 hours.  This won't be an additional 1%, so if you're already donating 2.5% you will get this service as well.

Caught that, it's now fixed .

Another update: Instant payouts are now available for any blocks which you donated at least 2.5% of your reward.  I can't access my personal wallet from my office to seed the pool balance beyond what I left in there for testing.  If you get an error regarding your payout, you can try again once Block #123066 is confirmed.  Once #123066 is confirmed, instant payout will be available on all future blocks for 2.5%+ donators.

My pool must have performance anxiety when I'm watching over it .

New update is live for the JSON API.  You can now get all of the information from the my account and my workers pages via JSON.  It's quite a large chunk of data currently, so tonight there will be customizable settings made available for the API (defaulting to only basic data) so you can tweak what data you want your app to receive.

Looks like the pool didn't have too many problems overnight.  Found two blocks!  I'm finishing up the code for instant payouts for donations over 2.5% right now.  If you look at the pool stats and they look weird (odd donation amounts listed in Payout Stats) don't be concerned, I'm just modifying my personal (user id 1) btc_earned/btc_donated values to make sure nobody is going to lose BTC or be paid more than their share.

Auto restart script is running and will keep running all night.  Will be back to work on figuring out why the process is crashing in 6-7 hours.  First thing tomorrow morning is linking the payout buttons to the My Account page in case we get lucky in all the chaos tonight.

I've applied a few more bandaids, including an auto restart script for the night, so if the pool crashes it's back up in about 1/10th a second.  I've got it creating a dump after each crash so when I wake up I can try to fix it while I'm at work.

It's still accepting shares, and submitting PROOF-OF-WORK to bitcoind, but you may lose some mining time during the brief pool restarts.  Consider this a 'caution' sign.  Hopefully after a good night's sleep I'll be able revive my old C debugging skills that have been dormant for so many years.

I need to make a button that auto-posts:  Pool crashed, bandaid applied and fingers are crossed!

My previous fix looked logical to me.  But I put it about 4 lines past the function call that crashed the process.  My brain/eyes didn't want me to read it properly after working about 18 hours straight .

UPDATE:  Got a response from the person who has the bad miner client crashing the poor pool.  Should be resolved shortly.

Are the errors occuring RIGHT NOW (as of about the last 30 seconds)?  My miners have resumed working since the block was put in place on the bad worker.

I sent a message to the owner of the worker, trying to find out what miner they're using and if there's anything strange in the settings.

One particular worker has been causing the crashes.  I've blocked them from the pool temporarily while I try to figure out what makes them so special.

Thank you all for the continued support.  As Sukrim stated, it is a great idea to have a second miner running low priority on another pool in case BTC Guild crashes in this early period.

Getting a huge flood right now, adding debug log printouts into the code to find out exactly where the crash is coming from.  It's a memory leak issue, looks like it's related to that hashing I mentioned previously.  Also checking network logs to see if this flood is legit or not (although it looks like something slush mentioned with his pool over the weekend).

UPDATE:  Found out which worker is triggering the crash, now trying to figure out why.
UPDATE 2:  Back up and not crashing at the moment.  Gotta package some items that sold today for shipment, we'll see if it's stable or not soon.  Sorry for the inconvenience, but some bugs just can't be found until you open up for the whole world to play with.

Pool is crashing instantly upon restarting right now, trying to figure out the cause.

Will update that tomorrow evening.  Since the "Since Reset" can be done at any time, there is no guarantee that "This Round" will be more or less than "Since Reset".  I'll have to move the calculations to be prepared before printing (right now the calculations are done and printed into the table as generated), then order them based on which was larger.

The API is now active for "My Account" information.  You can find your API key and the URL in "My API Settings".  "My Workers" information will be added in the next few minutes.  Tomorrow there will be a configuration screen on "My API Settings" to configure what data you want to include.

Transaction fees have been added for the additional transparency.


Reset All button added to workers.

Transaction fees are currently kept by the pool, which is the only "reliable" income generated by the pool.  To my knowledge no pool splits transaction fees among the miners at this time (correct me if I'm wrong!).  Once transaction fees are more common, and the BTC generated by blocks shrinks, they will get included with the total block split among the pool.  I'm working on setting up the conditions for when that switch will take place.