I'll take a look at it for you. Can you PM me your ABC username and the logging output of your mining client?

Thanks. Strange thing is that on our end it was only us.ozco.in, all others were running at normal levels . Should the issue return we'll take a closer look at it.
Quite right

Hi Graet, welcome in our thread!

The abovementioned issue is not related. It had to do with an upstream pool, but not Ozcoin Let me elaborate on the Ozcoin incident:
Ozcoin has two servers (au and us). The stales you were noticing were occurring only on one of Ozcoins servers. We took that ozcoin server out of rotation for a day. Now it seems to be functioning OK again, so it's back in. You mentioned some backend problems around that time? We attributed it to that and did not pay further attention to it. Overall our experience with Ozcoin has been excellent.

Now for all the ABC miners that might have become worried by a mention of 30% stales:
ABC miners were in no way impacted by those ozcoin stales. share accounting for ABC miners is completely seperated from what upstream pools like Ozcoin are reporting. If ABCPool determines a share to be valid the user gets credited, even if an upstream pool reports it as invalid.

Why is that? Well, the promise we make to our miners has nothing to do with the performance of third parties. Therefore we think it wouldn't be fair to ABC miners if we shifted problems with third parties to them. Our miners have a 'contract' with us, and we have further 'contracts' with third parties. Seperate.

That's also where ABCPool improves on services like Project #2 or GPUMAX. Their users are experiencing a fluctuating amount of stales, because they apply the upstream result to the user instead of doing their own verification. IMHO, such an approach can never provide miners with a predictable experience.

A 5970 should definitely be getting more than 280Mh/s even on its own. If you PM me your ABC username I'll investigate your case.

Has your miner been idling? I'm asking because we noticed (and fixed) an issue that caused some of the work packets to be potentially incompatible with some mining clients for the last ~3 days. It can only have impacted a very small amount of users because overall hashrate did not change.

We create our own blocks sometimes, and you'll be working on work that other pools provide. From the ops' point of view, a PPS pool is just an enormous solo mining operation because the ops take over all risks from its miners. And what does a solo miner usually do? Join a pool to reduce variance We actually join multiple pools.

ABCPool is not the so-called Mystery Miner. If there are transactions, ABCPool blocks are likely to contain them. I'd been following the Mystery Miner story in it's early days (now not so much), and the most likely explanation seemed that it's a large botnet that minimizes calculations, load and/or traffic by not including transaction data.

Hi Greatwolf, thanks for asking. I'm assuming that with 'current block' you mean 'current round'. Just in case you're not: Information on the current block and loads of other Bitcoin network info can always be found at http://www.blockexplorer.com.

As for ABC-specific stats, everything we publish is available in the Stats section of ABCPool.co. A subset of the sitewide stats is available through our API, and personal stats are available after logging in and again through our API.

However, you won't find the stats you're asking for on our site!

ABCPool is all about predictably high mining rewards. The stats are focussed on helping (potential) miners manage their rigs and optimize their rewards. ABCPool is a PPS pool, meaning our miners always get the same high amount for every share submitted, no matter when (or even if) any blocks are found. Current or historical round information, while interesting, has no impact on earnings. There are also some practical barriers to providing round info, because we offload part of pool risk to third parties to be able to offer you such a competitive rate.

Besides generating steady rewards, the PPS mechanism also makes these rewards completely independent of (the hash rate of) other users. The sitewide hashrate we publish is mostly useful so miners can easily verify whether the pool is running smoothly. I don't know if anyone is graphing it; we'd be happy to reference such a graph.

If you are missing any info/stats that would help you achieve better performance at ABCPool, we are always open to suggestions! Just recently we've added a page continuously reporting the performance of the various mining clients people are using. Use it to your advantage

Happy Hashing,
MC

Sorry guys, turns out there's an unfortunate interplay: When a backend hickup occurs it can mess with the efficiency monitoring. We'll be adjusting the algo's soon so they won't penalize users under such circumstances. For now, accounts with an excellent track have been whitelisted until this is resolved.

I've sent you a PM with a new PW.

ISSUE RESOLVED: A server crash caused the pool to be offline for several hours earlier today. The stats section was the last to be brought back to life, and service has now been fully restored. No data was lost, and all submitted shares have been accounted for.

Sorry for the inconvenience!

MC

Hi all,

We are currently working on a page that shows the performance of the clients in use at ABCPool.co.
 
To make this as useful as possible for our miners, we would like to ask you to help identify some clients. Please let us know if you know which client(s) may be using the following identifiers :
Java/1.6.0_26
Java/1.6.0_10
Java/1.6.0_29
Java/1.6.0_24

Watch the ABCPool thread for further announcements if you're interested in these kind of stats; like when you're looking for the perfect mining client 
 
Regards,
MC.

Welcome to ABCPool jme.

And.. done! Enjoy!

...and you know you've just committed yourself to mining at ABCPool for at least the next couple of months, right?

NEWS: The new 'Reputation' section on the stats page

Hi all,

We've added a 'Reputation' section to your stats page. It uses live data. Can't connect to the pool? Check the reputation section to see if there are any problems with your account. By the way, as a normal user you shouldn't ever get blocked.

Well-behaving users deserve excellent service from their pool. Therefore ABCPool sometimes blocks low efficiency miners temporarily when they endanger the overall service level. Low efficiency is a sign that someones software/hardware is malfunctioning or he/she is running resource-eating CPU miners or even a botnet.

If you encounter any problems with your account, contact me or Chlorine and we'll try to help you out.

Happy hashing everyone!

MC

FYI: Blocking rules have been relaxed this afternoon. Nobody was blocked during (at least) the past few hours.

Hi Phants,

I'm sorry but I may not fully understand your question. I think you are saying that all your machines are blocked together because they are at the same IP?

That is possible, because blocking is based on IP addresses, not on device or worker. You can check if you are blocked on the 'Stats' page.

After 30 minutes blocking will stop. If you continue mining with low efficiency you will quickly be blocked for another half hour. To prevent blocking, only mine with GPU or FPGA devices. You can have as many as you want on the same IP.

We sometimes block low efficiency (CPU) miners because they hurt pool performance for other users. Electricity costs for CPU miners are higher than their mining income anyway, and they are mostly used by botnets.

Callius' situation was resolved. Turns out he had some problems with his rig; there was no block.

Sorry to hear that Callius! I'll investigate the situation and see if we can do anything about it. I've sent you a PM for some more info to get the ball rolling.

This kind of rule enables a new kind of transaction spamming attack.

When a block is found, the set of transactions it covers could have been determined up to 120 seconds earlier, because that's the work-expiry period most pools employ. So if an attacker would want to prevent currently outstanding work from being able to find a valid block, he could just inject 3x the current amount of transactions into the network. Nodes will then reject any block found by the 'old' work.

Newly distributed work, on the other hand, will include the spam-transactions. That makes it eligible for a block again, so the attacker needs to repeated his strategy for lasting effectiveness. This causes an exponential growth in spammy transactions. Depending on the goals of the attacker and the transaction costs of the spam-transactions this may or may not be worthwhile.

Thanks for the info. It's certainly different from how most GPU miners operate, and less efficient too.

I guess they'll improve some of this stuff eventually, especially the 'waiting to submit' part. Every 6 seconds you wait to submit a share that's also a block there's an additional 1% chance someone else has beat you to it. This reduces the effective hash rate.

The efficiency threshold is currently lower than 10%. There are currently two accounts that are causing problems: They are generating 50% of the load on the pool while only contributing 1% of the hashrate. These are the accounts that are currently affected.

I'm curious about the efficiency FPGA's get. You suggested it may be quite low, why do you think that is?

We fully intend to support FPGA miners. Any insight into their behavior is appreciated so we may adjust policies to let them through