Give it one more try for good luck.

Please try again nick.  I keep track of your confirmed rewards vs your "donation confirmed rewards" separately, they're just added together on the interface so it's less confusing (when it works correctly!).  When fixing the huge scientific notation negative that Nythain posted, I made it round very small negatives/positives to 0.  It ended up setting your confirmed rewards to 0, when they are actually NEGATIVE (because you've been paid out more than your confirmed rewards due to donations).

Fixed .

author=nicksasa link=topic=7760.msg115882#msg115882 date=1305121672]

Weird ... I did receive the 1.55 tough.
[/quote]

Fixed your problem nick.  Try again for the remaining amount.  Your confirmed rewards were being temporarily double counted when I was correcting the display.

Those of you with 2.5%+ donations should now properly be seeing your rewards go directly into confirmed (with payout available) for any blocks solved while your donation was at 2.5%+.

Thank you for your support, I'm working hard to earn my current slave wages  .

Just woke up, and fixed the problem.  Pretty sure I was dreaming about the code last night.  It should be completely fixed this time, not just a bandaid type fix.

Regarding instant payouts, there is a minimum payout of 0.01 BTC.  I'll take a look at the users who said their rewards are not going directly to confirmed with 2.5% to see what happened.

Thank you for the support all.  It has been stable since the last crash (although it normally crashes about 1 minute after I say that).

It will go down for about 3 seconds shortly so that the auto-restart script can run during the night.

Worker rename and password resets are working in testing, but there's no nice way to fit them in the current page.  Tomorrow morning I will be splitting workers into two pages.  "My Account" will show the current worker stats table (with reset buttons).  Then you will have a "Manage Workers" page which has the ability to add, hide, rename, reset, and change the passwords for your workers.

Looks like we still have one worker that has caused a crash every time they try to communicate with the server...they're causing something completely different from the others.  Back to running a fully logged version to see what they're doing differently.

Oh I know that one.  Problem was I just finished setting up the password hashing on the website (PHP) when I added it to the pool (C).  So my habits of PHP carried over.  Worked fine with standard data, but C doesn't fail quite as softly when passed bad data as what PHP allows.  The curse of higher level languages!

The hash rate shown by the pool is your average hash rate over the past 15 minutes, and is calculated based on submitted shares in that window.  It is only an ESTIMATE.  Your luck on reporting getwork results will always cause some variance over what is shown by your client.  Since you only recently started, the rate will be much lower until you've been running for 15 minutes.

The crash should now be fixed!  All my time working in PHP/MySQL the past few years, I forgot some very basic memory management in good old C.  The crash was caused when somebody forgot to send a password with their worker.  Because I added a function to combine the password with the salt, and then hash it, I was trying to work in unallocated memory (the password was a NULL value).

Running in a debugger for the next hour and a half to make sure it got caught (I can only test it so many dozens of ways).  If it looks stable again, the pool will be down for about 3 seconds in an hour when I switch it out of gdb and run it through the auto-restart script.

The bug causing all these crashes has finally been identified.  Pool will be resuming in approximately 10 minutes and should not be seeing any more crashes related to the problem.

A few of the new features were added to the website, but meanwhile the pool is getting crashed during a user authentication again.  Just added a massive amount of debug lines (it's quite beautiful to see the spam of log strings) to pinpoint exactly where it crashes next time, because the backtrace wasn't being particularly useful.

Currently added:
  Hide Workers (and Reveal)
  Block Statistics include your share count, reward, and donation amount


Almost finished:
  Worker password reset
  Worker rename

You found the most recent one.  I'll follow deepbit's format of bolding the blocks found by you when I add personal statistics to the block listing.  Should be up in the next hour or so!  Looks like the server itself is running great (no crashes in the last 14 hours).  Haven't had any new miner idles/RPC comm errors since the issue which BitLex mentioned.

Can you send me a PM with the worker name you used?  I'll take a look at the shares log to find out why the server was rejecting them all.

I will be home and ready to resume looking into any pool issues that rise.

The high rejection rate is VERY odd, it looks like there was a spike in rejected shares about 20 minutes ago (all my miners jumped about 15 rejects recently), as well as a communication error.

I'd recommend resetting your worker stats and/or restarting your worker just to get a fresh count.  Until the spike, my 12 workers were averaging 0.29% rejected/invalid shares over the past 8 hours.

BitLex: What settings are you using on phoenix (queue size, worksize, etc)?

Not that long actually.  At current difficulty with the pool hashrate rounds should AVERAGE around 16 hours (due to that 50% difficulty spike the other day).  This round (AVERAGE) would be slightly higher since the pool was not running at the current speed this whole round.  The pool is only currently operating at 11.7 gHash.  It's been creeping up all day though, so rounds should get faster and faster.

UPDATE:  Average speed has gone up another 400 mHash since the above figures were posted!

RealVNC on my windows machines, the rest all use linux and SSH.

Hi netxshare,
  I'd love to get my pool supported by your gadget.  Please send me a PM with what information/format you'd expect, or you could register on my pool to take a look at the current JSON-API output .  Thank you.

At this point all that can be done is extrapolation and guessing for difficulty jumps.  The probability of the network continues to grow at 20-40% every 10-14 days is very small.  Right now it can and will happen due to the small / new nature of BitCoin, but that kind of growth simply can't be sustained for a long period of time .  Eventually you'd hit the point where your rate of growth is faster than the speed at which new computing power is created on the assembly lines.

I think (and hope) that the network speed levels out to a gradual growth rate in a few more months (so probably around 500-600k difficulty), at which point the growth would likely be linear rather than exponential.