I missed this post earlier, so I'll reply to it now. I don't think it has anything to do with excluding CPU miners. Although a CPU has less power than a GPU, CPU miners still contribute to the network security. Maybe even significantly, because there are so many more CPUs out there than GPUs. It just wouldn't be healthy to exclude CPU miners.

I also don't think long-polling changes the situation regarding the age-limit.

A much more logical reason is that old work causes the pool to miss out on transaction fees. How is that? New transaction (and their fees) keep coming in over time, and make the next block more valuable with every second that passes since the previous block. If someone hands in work that is 120 seconds old, that solution will not contain the transactions from the last 120 seconds. Remember that there are on average only 600 seconds between blocks. This means that work that is 120 seconds old misses out on (on average) 20% of possible transaction fees. Those 20% are passed on to the finder of block n+2 however, so the effect cancels out. Unless there is some pool that decreases or increases its age-limit, because that will shift the fees in favor of one of the parties.

Since most pools seems to use 120 seconds, ABCPool will do the same. This keeps the whole ecosystem in balance.

No-one likes to see too many 10mill share rounds, that's for sure. In the long run however, they are offset by those 100k rounds. Our buffer protects us from streaks of bad luck.

NB: please don't double-post. Use either this thread, or our newbie discussion thread.

Thanks for the compliment ccbiker Getting (payed!) stales down is our first priority, and after that we'll add some extra stats for you!

No-one likes to see too many 10mill share rounds, that's for sure. In the long run however, they are offset by those 100k rounds. Our buffer protects us from streaks of bad luck.

NB: please don't double-post. Use either this thread, or our main discussion thread.

Thanks for the suggestion Sigg. Our stale rate has been rising along with pool hashrate, and that's a concern. Time rolling is indeed one of the ways we are considering for lowering our stales. As a miner that doesn't have to keep you awake at night, because we pay for stales anyway

We're experiencing some growing pains. We will focus on minimizing stale and invalid shares in the coming days. Until levels are back to normal we have closed registration.

The unknown-work error code means that the work you are submitting has either never been handed out to that specific worker, or that the work was expired because it is older than 120 seconds. This error should only occur for workers below 100Mh/s, and when we restart our backends for updates (ca. two times daily).

This is by design. Your donation is already being subtracted from the PPS amount each time we process incoming shares. Since last week we've been keeping track of those donations, and we plan on displaying them in your stats.

Oh, and have we thanked you yet for your donations? Thanks!

NEWS: ABCPool was offline for several minutes, and is now operating normally again.

We're sorry to see you go! ..but did you know: Your miners were last seen mining two days ago. The changes made less than 24 hours ago have drastically improved the valid and stale rates for many users.

Over the last 14 hours, cgminer 1.5.8 users have obtained a very low 0.48% invalid rate. However, previous versions of cgminer are currently the worst performing of all clients on ABCPool with 1.5-2.0% invalids.

Overall invalid rate is only 0.55%.

We still have 0% fee. Since difficulty went down last week, the price per share has been raised to 0.0000276900796620 at that moment.
If you were actively mining on august 20 or august 21, your reported shares may be out of sync with your balance. See my earlier posts for more about this issue.

We are constantly monitoring the servers to try to get the highest valid percentage possible. Over the past four hours the pool has rewarded 99.45% of incoming shares.

If your stale rate stays high there may be something wrong with your setup.

This was due to the maintenance that we were performing, and should have last +-30 minutes. Stale/invalid counts should now be incrementing normally.

NEWS: 23:40 UTC: ABCPool RPC server is temporarily down for maintenance.

UPDATE 00:15 UTC: RPC server has been restored to service. We introduced changes to the RPC server that should make it more compatible with the original pushpoold. Since most clients play nice with pushpoold, these changes to ABCPool should benefit compatibility with mining clients.

NEWS: We are welcoming new miners again!

Ars (and Eligius) have the concept of a buffer, from which miners are paid. If the buffer is empty (or negative) due to bad luck, you will receive payment at a later moment or not at all, depending on the specifics.

ABCPool has no such thing. You always know in advance what you'll get, even if the pool has bad luck.

NEWS: As of a few hours ago we have been gathering statistics on mining client performance. Based on these statistics we have expanded our range of recommended clients:

Supported clients: Phoenix 1.48+, guiminer/poclbm

Clients that are known to be incompatible with ABCPool at this moment: DiabloMiner, Bithopper, cgminer.

You may try clients not listed here, but we can not guarantee good results in that case.

We continue to investigate the reasons some clients do not work well with our pool.

Because blocking bad behavior is quite straightforward and something we'll need anyway to protect the pool from attacks. Having said that, we're also planning on making cgminer work with ABCPool, but that's less straightforward.

Resolved: The lock that prevents multiple executions was not properly released, causing the pipeline to stall. All shares gathered between 03:25 UTC and 10:21 UTC have now been properly accounted for.

NEWS: As you can read above, several users have reported issues over the weekend: Sharecounts that are too high, sharecounts that are not consistent with reported balances,
and highly fluctuating hashrates. We'd like to start by thanking you for bringing them to our attention. Your comments helped us a great deal in resolving.

We have finished our investigation on the issues, and confirmed they arise from the same root cause. Due to the explosive growth of ABCPool in combination with the misbehaving client software, our systems were at full capacity. Our bookkeeping scripts run every minute, and take only a few seconds to complete under normal conditions.

Due to the high load however, execution time grew such that executions started to overlap. This caused submitted shares to be counted multiple times before they could be marked as counted. In fact, it caused a cascade of executions that crippled the system at times.

We have mitigated the issue by making sure that only one instance of the bookkeeping scripts is running at a time.

We will leave the inflated share counts as they are for now; they might be corrected downwards in the future.

In incidental cases, account balances have also increased more than they should have. As a token of gratitude to our early users we will leave these balances as they are. Cheers!

Blocked members are only blocked from mining; they may still withdraw their balance whenever they want. They have full access to the website.

This is due to the extreme load non-Phoenix clients are generating.

Thanks for pointing this out; we also see this discrepancy in our detailed accounting overview. Due to the high load experienced on our servers the balances have not fully updated. We will adjust any skewed balances once the load issue has been resolved.