A 6 month criteria would mean basically no pools get listed if they're small.  The only pools older than 6 months are Slush, Deepbit, bitcoinpool (barely), and possibly Eligius.  BTC Guild opened only 5m 2w ago, and I think Eligius came out 1 week before us.

The problem is that the way many miners work is very similar to a DDoS if they're targetting your mining port while the server is unresponsive.  It's amazing how many people still use old miners that will reconnect with almost no delay, making it effectively a mini DDoS client when the pool is being attacked and having stability issues.

There's an issue with Awknet (I used them).  Their DDoS protection is okay, but the problem is their filtering kicks in based on high volume packet situations.  BTC Guild started at Awknet, and we had to request they turn the DDoS filters off back when we were much smaller because if the pool went down for even a few minutes, the PPS rates due to miner reconnect spam would kick in the DDoS filter, making the server practically impossible to connect to.  I'm sure it would work fine for some traditional DDoS tactics, but all the DDoSer has to do is spam connections to port 8332 as if it were a bunch of miners.  There is no easy way to decipher what traffic should come through and what shouldn't in that situation.

I have made a post on the front page of the website, identifying the current plan for future steps with BTC Guild.

Until the change is made, the pool will continue to operate normally (as best as it can).  I simply am not willing to continue to invest money buying new servers to fix the current temporary stability issues.

No ETA on pool stability at this time, losing 40% of our public facing servers has caused some major issues.  Everything seems to work fine an hour or so but then it comes crashing down.

Changing difficulty won't affect pool traffic as much as people think.  Your miner will ask for work exactly as often as it already does.  It simply will submit fewer shares.  The vast majority of pool traffic is obtaining new work, not submitting shares.

The biggest issue of pool overhead is in longpoll connection handling.  When you have large numbers of active connections, things start to randomly slow down.

The intent of the notice seems to not be that IRC is bad, but that botnets/trojans are.  My reading of that is that having a botnet/virus/trojan on your computer means you're violating their AUP due to potentialy illegal activities, not that the IRC connection itself is against the AUP.

It's most likely trying to notify you that you may have a virus, and you need to take a look.  The notice itself doesn't seem to be mentioning anything about a potential suspension of service if it isn't "fixed" on your end.

Like Tycho said, we use the same ISP.  I know he dealt with them heavily back in June when the first round of attacks (that I know of, but I only started in April) hit.

They've nullrouted 3 of our frontend servers already, its just a matter of putting up new IPs in front and contacting the ISP telling them whats happening so they hopefully dont' nullroute every IP on your account.

The only reason we were hit the least in the last round is because we were able to get a large chunk of IPs blocked prior to the attack.  That's helping this time, but as anybody can see, it isn't doing much for BTC Guild's pool servers at the moment (website is back up mostly though).

Copied from my post on Slush's thread, relevant to this topic:

Better yet, everybody should hop to a small pool.  Everybody jumping to BTC Guild ends up screwing over our regular users.  I've been removing servers from our clusters the last month due to shrinking speeds/profits.  We cannot handle 2+ TH/sec like we used to, because it isn't worth keeping up the hardware at this time.  That's why I'm looking at cancelling signups (private pool) or a major payout structure change:  Get the botnets off and keep our regular users with a stable pool.

So please:  If you mine on Slush, Deepbit, or BTC Guild, set your backup to a SMALL pool.  Not only is it more reliable (the major pool outages are often related), but it avoids putting unexpected heavier load on an already large pool.  And of course it's safer for the network to have the hash split between a larger number of nodes.

Copied from my post on Slush's thread:

Better yet, everybody should hop to a small pool during major outages/downtime.  Everybody jumping to BTC Guild ends up screwing over our regular users.  I've been removing servers from our clusters the last month due to shrinking speeds/profits.  We cannot handle 2+ TH/sec like we used to, because it isn't worth keeping up the hardware at this time.  That's why I'm looking at cancelling signups (private pool) or a major payout structure change:  Get the botnets off and keep our regular users with a stable pool.

So please:  If you mine on Slush, Deepbit, or BTC Guild, set your backup to a SMALL pool.  Not only is it more reliable (the major pool outages are often related), but it avoids putting unexpected heavier load on an already large pool.  And of course it's safer for the network to have the hash split between a larger number of nodes.

Better yet, everybody should hop to a small pool.  Everybody jumping to BTC Guild ends up screwing over our regular users.  I've been removing servers from our clusters the last month due to shrinking speeds/profits.  We cannot handle 2+ TH/sec like we used to, because it isn't worth keeping up the hardware at this time.  That's why I'm looking at cancelling signups (private pool) or a major payout structure change:  Get the botnets off and keep our regular users with a stable pool.

So please:  If you mine on Slush, Deepbit, or BTC Guild, set your backup to a SMALL pool.  Not only is it more reliable (the major pool outages are often related), but it avoids putting unexpected heavier load on an already large pool.  And of course it's safer for the network to have the hash split between a larger number of nodes.

Not my thread but try again on the website, it was instantly reporting a failure because I had to shut down and power back on the server.

It means I would provide 500 BTC so the pool has a sufficient buffer to start.  If the pool had good luck and built up some good luck after the switch I would slowly pull out the initial funds used to start the buffer.

I've not yet posted the poll.  I've been working overtime this week so I only have a few hours each night to get any other work done.  I have been in conversations with some of our oldest (and some of the largest) miners at BTC Guild before I open up any polls.

There is nothing wrong.  Hasn't been outside of the one problem I edited into my post, and its affect on our total luck has been negligible.  Play around with standard deviation all you want, it doesn't provide anything other than a benchmark.

Edit for clarification from one response in IRC:
DDoS's don't affect our luck.  Botnets don't affect our luck.  Anytime the pool is down, it means that there are no shares being counted, so it doesn't affect the end total on the round.  If the network connectivity is bad, at worse it will increase the frequency of invalid blocks, but the shares/round data will still reflect "actual" luck.

I like how your same stats show Eligius having the opposite (4% positive vs 4% negative).  People seem to think luck can only be positive and never negative unless there is either a technical problem or sinister force at work.

The only technical issues which had a negative effect on luck were about 3 months ago, where for about 1 week there was a period where work was being accepted on multiple servers as valid, even though it could not solve the block unless it went to the original server (so multiple shares being counted).  Maybe a fraction of a percent effect over the course of the pool.

The poll will be up tonight.  It will be a separate page, not a simple poll.  The options will be randomly ordered on each page to escape the problem where people tend to pick the first option.  The page will offer details on exactly how each system works.  The following is a brief summary to get some more conversation going on in this thread.  Obviously the poll on the website will not be the sole determining factor of which system we use, but it will weigh heavily on the final decision.



SMPPS (Shared Maximum PPS):  It's basically PPS, but capped at what the pool has earned to date.  When the pool has good luck, the extra BTC is added to a buffer.  When the pool has bad luck, it continues to pay PPS rates as long as the buffer has any balance remaining.

SMPPS is basically no variance, unless the pool experiences significant bad luck streaks without any good luck streaks to rebuild the buffer.  I will set the initial buffer to 500 BTC.  Details on the buffer will be visible on the stats page if this is the system we end up using.




PPLNS (Pay Per Last N Shares):  It's much more like proportional rewards.  On any block solve, the last N shares submitted are allocated rewards proportionally.  This is completely hop proof, and the rewards fluctuate with luck.  During periods of good luck, you may see the following:

N = 1,000,000
You submit Share #900,000.  A block is solved at #1,100,000.  Shares #100,001 through 1,100,000 get paid just like a proportional pool.  Then another block gets solved at #1,200,000.  The previous 1 million shares get paid out.  Since 1m shares have not elapsed since the last block, Shares #200,001 through 1,100,000 get paid a second time.  A higher value for N means each share is paid less, but it has a higher chance of being double paid, and a lower chance of not being paid at all (if a block lasts more than N shares, some shares are not paid). 

In the end, a 24/7 miner would see essentially no change from proportional.  A part-time miner will see more variance (since it's possible to get paid many times for 1 share, or not at all, depending on luck after you turned your miner off).

No.  I'm hoping to get it on the PPS pool this week/weekend.

Unfortunately I don't feel the same way about the issue.  About 3 weeks ago the pool was cut down to just 2 servers with PoolServerJ, with stale rates averaging 0.2% and no idles in sight.  Then last week everything started to have hiccups, and as the DDoS happened the pool began breaking down, even when I added back 5 pushpool VPS nodes to help last night.  It's a problem that is making me wonder if this is all worth it anymore.

I'm looking at some major shifts with the pool in the next 1-2 weeks.  PPS merged mining tests are a big part of it.  Odds are I will be closing down the primary pool and bringing up a "new pool" in its place so I can implement a much better frontend (6 months of updates/added features have not been kind to the pool) with a fresh database.

I'll be putting up a poll this week on the BTC Guild website to see what the users want:  

A) Payout Change
  1) Proportional
  2) SMPPS
  3) PPLNS
  4) Straight PPS [will require a much larger fee due to risk]

B) Fee Change
  1) 0% Fee - I'll deal with the pool randomly failing/idling
  2) 1.5% Fee - Still cheapest of the "Big 3", with all current perks [120 block wait for confirmations (no invalid protection)]
  3) 2% Fee - Tied for lowest of the "Big 3", with all current perks [with no waiting on block confirmations (includes invalids)]


Right now, it looks like SMPPS or PPLNS and a 2% fee without 120 block confirmation waiting.  The SMPPS will start with a couple hundred BTC as a buffer.   Either way, merged mining will be a part of the new BTC Guild when its done.

Testing of merged mining is expected to begin on the PPS pool later this week/weekend.

Small outage just now was completely unrelated to the pool servers, something happened at the ISP (couldn't get into the shell of the pool servers either).

On a non-technical side:  Yes, the updates from me in the forum have been delayed a bit.  Work is taking up far more time, and the pool itself is becoming a drain on time and resources.  For miners, the drop in price is a reduction in profitability, but you don't have to do much work for a miner.  For running this pool, it went from rivaling my day job's income, to now making about 1 day of my day job salary per month.  That's how drastic the difficulty/price ratio has affected large pool operations.  Risking an extra 3-4 hours of time at my day job to work on the pool is simply not an option anymore.

EDIT:  Yes, this is a long round.  It is not broken.