With automatic payout we pay out in rounded figures, and the unrounded part remains as balance on your account. That way we keep your wallet a bit cleaner. This is how it works exactly:
If your balance exceeds the minimum amount set by you, we pay out in increments of that minimum amount. So if you would have had 0.51234BTC, we would have paid 0.4BTC and the remaining balance would be 0.11229BTC (because of the 0.00005 tx fee)

This means your remaining balance is still in 8 decimals; we just subtract the amount that has been payed out. By paying out using these rounded numbers it is easier to gauge your earnings from your transaction overview in the bitcoin client. If you want to withdraw your full balance you may initiate a manual cash out at any time. Manual cashouts are always for the full remaining balance.

NEWS:
Dear members,

As mentioned earlier, certain clients are submitting huge numbers of invalid shares while the incompatibility of certain mining clients remains. As this practically means these clients are DOSsing our servers, we are forced to start blocking their respective users in order to ensure service quality for those that are submitting normally.

1. Users that submit more invalid shares than valid (valid + stale) shares (ie. >50% of total is invalid) will be blocked on IP-basis.
2. You will only be blocked after submitting at least 1000 shares (ie. it is no problem if you start with submitting 42 invalid shares)
3. Blocked users will not be able to continue mining
4. Blocked users can still withdraw their funds.

If you are blocked, you may request an unblock by sending us a PM explaining what steps you have taken to mitigate the problem.

Some tips:
We noticed that especially the cgminer client sends a lot of invalid shares. If you are using this client, switching to another client will probably solve the invalid-shares issue.

If you have any questions, feel free to contact us.

I think cgminer is retrying all shares that it thinks it previously failed to submit. It does not report them as invalid yet, because it has not yet given up on them. When i look through the logs, I see you submitting boatloads of 'unknown-work' shares, each for a different block. These are all very, very old shares that cgminer is constantly re-submitting. The original submission attempt might have even been successful. I suspect cgminer wants to see a certain kind of error message before it gives up, and that ABCPool is sending a different one. Each resubmission counts as one invalid share, although in most cases it's the same shares over and over again.

In the next release of our backend the error messages have been changed so they look more like those of the original pushpool. We are still testing this version, and expect to have it ready in a few days.

UPDATE: We are currently investigating the high invalid counts for non-Phoenix clients.

Going through the logs, the high invalid rate is for the most part due to 'invalid-time' submissions. We were seeing some of these before, that's why a few days back we added the HTTP header to all getworks. This header indicates explicitly that time-rolling is not allowed. It seems that some clients are taking the presence of this header as a sign to enable time-rolling instead of disabling it. That's why we've just turned the header off again. At first glance it seems to have eliminated the bulk of time-invalid submissions.

Thanks for letting us know about this. We did heavy modifications of pushpool to obtain low stale rates. We've only tested these mods with Phoenix, that's why we recommend it on our site. It now appears that some other clients may experience problems.

I looked through the Diablo code, and I'm fairly certain this is caused by ABCPool timing out the LP connection with a '200 OK' after 50 seconds to get rid of disconnected clients. Most pools don't do this, but it is one of the reasons ABCPool can keep the stalerate low. Phoenix handles this excellently by silently reconnecting; just what we want. Diablominer might expect a different response than 200 OK. I've posted the issue in their forum.

That would be most helpful. Can you PM them?

I have a technical question for the developer; At ABCPool we have at least one user experiencing problems when connecting with Diablominer. Part of it pertains to Long Polling; ABCPool times out LP connections with an empty HTTP 200 response after 50 seconds to prevent defunct LP connections from causing delays when a new block is found.

When this happens, DiabloMiner prints

Is it possible that DiabloMiner gets confused by these timeouts? I'm wondering, is there another way for ABCPool to gracefully timeout the connection in a way that DiabloMiner remains happy?

BTW: The way Phoenix handles such a timeout seems OK: It silently reconnects. Is there a way to get similar behaviour from DiabloMiner?

We're sorry to see you go. We don't have the resources right now to look into this very deep. When we have the chance we will do some tests with cgminer ourselves to see where the invalids may be coming from.

It would help if you can share two more things with us:
1) The MH/s each of your cards normally produces
2) Whether the rate displayed in your account at ABCPool is lower than what you experience at other pools.

Regarding 2): Last week a user reported lots of invalids, but said it didn't affect his reported rate of valids. If your valid hash rate is affected, you should have seen a reported hashrate of +-16% lower than normal (ie 24479 / (24479+126914)).

Apoligy accepted
I don't really understand what you mean by not reporting them. Sure, our statistics are pretty basic now but the valid/stale/invalid counts that we have been reporting are (1) reflecting the share submission results we returned to mining clients and (2) accurate. (1) can be proven by miners themselves, if they keep a detailed log of sharecounts. (2) is never provable I guess.

That's right. There definitely is a reputation incentive, and not a financial one. Non-PPS pools have both.

We rewrote every line of code that had to do with LP, because it was horribly inefficient, so I understand a thing or two about LP. However..
you're right about this. My mistake. In NB2 I should have written 'invalid block' where i wrote 'stale'.
There's nothing magical about it. Deepbit is also quite good at it as I understand.

On a general note, thanks for your inquisitiveness, it's good to ask the hard questions once in a while . I really do want to focus on improving ABCPool now, so I won't be giving this kind of detailed replies any more on this topic.

PPS is the only reward type that trick wouldn't work for. For a full rebuttal, see https://bitcointalk.org/index.php?topic=33586.msg465303#msg465303

There are definitely pools that do this. Actually, *all* non-PPS pools that purport to be paying for stale shares, actually don't. I do understand the confusion, since it also took Us some time before I realized that pay-for-stales claims can not ever lead to extra earnings at non-PPS pools.

Slush's pool for example has no LP, so it can not possibly notify its workers of a new block. Practically this means those workers do stale work ~3% of the time, although Slush accepts most of these stale shares as valid shares. They therefore report a 0.3% stale rate. Total block reward will be the same 50 BTC in the end, and since everyone has approx. 3% extra shares, payout per user is still the same. Only everyone thinks they get payed for stales.

On the other hand, any PPS pool would shoot itself in the foot if it was reporting a lower stale share amount than was actually the case: It would mean they now also have to pay the promised per share amount for those 'fake valids', whereas normally those would be worthless. The aforementioned dilution effect does not exist at PPS pools, since there is no 50 BTC block reward to be distributed (just the pay per share).

For ABCPool, this goes even further: since we pay as much for stale shares as we do for valid shares, your earnings would be exactly the same if we report 0% stales, 0.5% stales or 100% stales.

For more info, see http://www.abcpool.co/stale-shares.php.

NB: SMPPS, ESMPPS, or other PPS-like reward methods are just as vulnerable to this issue as Prop or PPLNS pools. Even Solo mining has a stale rate, which is reflected in the number of orphan blocks found over time.

NB2: The 'secret' behind real low stale invalid block rates is having a highly connected bitcoind running so you are quickly notified of new blocks, wherever they may come from.

It could be an LP issue, since the amount of invalids is around the 3% people see when mining without LP.

I know of a bug in Phoenix, where it reports that it is doing longpolling but has actually lost the LP connection. Since it fails to time the connection out regularly, it doesn't know it will never receive new-block notifications through LP. This can be witnessed in its logs around the moments a new block is reported: There would be no message indicating Long Polling was responsible for pushing new work, but just a message that a new block was found. Restarting Phoenix solves the problem (until it happens again).

Maybe something like this happens with cgminer?

The root cause of the problem was found: A bug had triggered an infinite loop. This caused the backend to become stuck without crashing. A crash would have restarted the backend automatically, but being stuck is more difficult to recognize. We have since fixed the bug and are evaluating options for automatic forced restarts in case a similar bug should arise.

ABCPool is now fully operational again. Please verify that your miners have reconnected.

This is not normal. Our users typically see less than ~0.5% invalids.

Shares are invalid if they fall under any of these categories:
* if their hash does not meet the difficulty target for a share (ie: computation error on client)
* if they are duplicates (ie: client resubmits; this does not affect your earnings)
* if they were handed out to a different worker than the one submitting a solution for them (ie: client programming error)
* if they were handed out more than 120 seconds ago (ie: expiration; happens when using slow GPUs or multiple workers per GPU)
* if they are based on a different timestamp than the one supplied (ie: 'time rolling' is not supported)

NB: Shares are considered 'Stale' if they would have been valid for the previous block and arrive within 6 seconds of noticing the new block.

Which client are you using? And do you use a proxy?

Our backend got stuck around 07:00 UTC, and has just been forcibly restarted. As a consequence, ABCPool has been out of operation for approx. 5 hours. We are doing a post-mortem on the incident now.

ABCPool is currently operational again. Please restart your miners if they have become disconnected.

I hate it when sites do that.. And you're absolutely right: I've also noticed it myself a couple of times on ABCPool. I'll have a look at it tomorrow to see if I can extend the session expiration time.

The fees are intended as a deterrent from spamming the blockchain (and our ledger) with micro-transactions. As soon as the exchange rate gets sufficiently higher we will consider lowering the fee-boundary.
But do these pools also offer 0% PPS with paid stales?  

I'm sorry to hear that.
I've found your transaction. It was included in a block within 10 minutes of initiating it. I have just PM'd you your payout history, I hope it clears things up!
Payout history is one of the features we are working on this week. We've heard your request

Interesting suggestion gigasvps. We don't actually have a fixed buffer; we rebalance the system wallet periodically to align it with outstanding balances and future member earnings.

Your posts have me thinking about adding some kind of solvency indicator and a failsafe that shuts down the pool in case wallet balance threatens to creep below the member balances. That way miners can be confident that they can withdraw their earnings; even if the entire pool management should die in an air disaster while on corporate retreat.

Regardless of any promises made by us or any other pool, we advise our miners to withdraw their earnings regularly. For reasons mentioned in another thread, https://bitcointalk.org/index.php?topic=34282.0, ABCPool does not intend to be a bank. We don't want to be holding on to large amounts of BTC for our members.

We know that our stats are currently pretty basic. We plan to introduce extra stats on the individual level, so users have more insight into their performance. We expect to work on that after this week.

ABCPool is accepting new users again!

After a growing very fast in a few weeks we closed registration for a while to verify everything was running smoothly. ABCPool is now ready for more growth, so registration is open again!

rTech, these are very good numbers. Mostly our miners see around 0.4% invalid shares, but in your case it seems to be 0.2%. Congratulations!