In English at least, all letters are capital letters and I've never seen the letter O, but Q is used a lot.

My payout was made. Everything seems to be in good working order.

I reset my payout threshold higher before going to bed this morning and found all rewards from round 21304 through 21331 to be correctly tallied. Just now I've reset the payout threshold back down to 0.1 and am waiting to see if payout is made. (web site is down for maintenance)

I've raised my payout limit to see if I can avoided losing any more rewards until this problem is fixed.

I'm not allowed to post on the support page; I tried to register, got the email that says I'm registered but when I try to login, it tells me I'm not registered.

I'm not sure what 'Which round was the last one to correctly post to confirmed?' means to you. All the rounds seem to post confirmed correctly, they just don't add anything to the confirmed tally, but they do remain in the unconfirmed tally for some period of time.

I became aware of the confirmed tally being frozen from a post by another user here. I recorded the unconfirmed, confirmed and total tally on my account page and after round 21316 confirmed, I went to my account page and saw that the unconfirmed and total tallies had not changed, nor had the confirmed tally. We won a couple of blocks shorty thereafter and then I saw that my unconfirmed and total tallies had dropped in value.

The first round I saw dropped was 21304 and this was the sequence:
We won a round and my unconfirmed and total tallies were reduced by my reward for block 21304.
After 15 minutes or so, the new block's reward was added to my unconfirmed and total tallies.

This sequence has now happened with every round since:

21304 dropped and 21324 added
21305 dropped and 21325 added
21306 dropped and 21326 added
21307 dropped and 31227 added
21308 dropped and 31228 added
21309 dropped and 31229 added

All the while the confirmed reward has been frozen.

Round 21329 came in and the reward for round 21309 was deleted from the unconfirmed and total tallies. The confirmed tally remains unchanged.

So far, I've seen rounds 21304 thru 21309 drop off my total rewards with no change at all in confirmed rewards. The more rounds we find, the smaller my reward.

Bingo! Round 21328 came in and the reward for round 21308 was deleted from the unconfirmed and total tallies. The confirmed tally didn't change.

When round 21320 confirmed, no changes were made in unconfirmed, confirmed or total rewards. I'll have to see if new block causes any problems.

Just finished the math again and found that blocks 21305, 21306 and 21307 are indeed deleted from the unconfirmed total but not added to the confirmed rewards.

Next block to be confirmed is 21327; I'll watch to see if block 21308 is then deleted from my unconfirmed total.

Edit: Next round to be confirmed was 21327 not 21320.

Have you done the math? That is, has it increased as much as it should have?  More than the last three blocks have not been added to my unconfirmed tally even though they show up on the statistics page.

My unconfirmed total just dropped two blocks worth of awards; confirmed award did not increase.

Same here.

Just a guess, but I would imagine Slush could avoid paying transaction fees if he limits payouts to to the blocks found by the pool.

There are many, many folks who would love to see BFL and their customers removed from the bitcoin mining scene. These folks are joined by those who just realized that a 4.5GH/S miner is not a ticket to a private jet and finally, there are those drama queens who simply love being in a state of high dungeon.

These are the folks who cut a path of havoc and destruction through anything and everything involving risk and innovation.  These risk-taking would-be ‘financial investors’ turn to ‘idiot protection’ programs such as the FTC and state AGs when they discovered risk was spelled RISK and actually had a meaning in the dictionary.

Well these proud little losers, bragging all day and all night on these forums about how badly they have been mistreated, want their money back before their product ships. Those who already have their miners are trying now to shutdown BFL before the other customers get their miners and then there are the drama queens who simply love to moan out loud how much they have been hurt by this mean old world.

Well, you perpetual children who have always used the power of government to intervene when losing your bets will probably be successful in damaging the rest of us. You’ll continue to reduce the GDP of your nations, you’ll continue to see jobs disappear and you’ll continue to see the government involved in your underwear, toothpaste and career choices.

It’s your own damn fault you ‘I’m so stupid I need somebody to protect me from my own dumb decisions’ scum-bag losers. Pull your damn pants up, buy dinner instead of a tattoo, and eat your failures like a real human being.

This happened to me when I upgraded Catalyst from 3.1 to 3.4 using only a single card (7770).  Catalyst 3.4 fixed some display problems (flickering pixels) but slowed my miner around 20%.  I wanted to revert back to 3.1 so I uninstalled all AMD software (including the driver via device manager) and then installed Catalyst 3.1.  GUIMiner failed to start after this with no error message.

I can only speculate, but I believe that the OpenCL package is not removed when Catalyst is uninstalled. Software developers frequently leave support packages, such as OpenCL in place because they cannot determine if other software not written by them may be using the interface.

So when the older reinstalled Catalyst 3.1 attempts to use the newer OpenCL from Catalyst 3.4, its probably misusing a changed interface causing an error that GUIMiner doesn't know how to handle.

I've noticed a problem that has occurred twice over the past week or so. I run two GPU miners (with GUIMiner) at approximately 160Mh/s each. Now GUIMiner reports accepted shares, accepted shares for the last hour and network connection problems in its log. These are the only indicators of miner health directly available to me and are not evidence of anything.

What I have seen is that my miners report normal activity with no connection problems and yet one of the miners has no accepted shares reported on my account log on Slush's pool. The first occasion showed over six hours since the last share had been accepted; the second occasion showed over nine minutes without a share accepted.  On both occasions, the time since the last share accepted matched the time since a block was found on Slush's pool but not necessarily the last block.  It appears as if one of my miner's shares were no longer be credited after the pool's 'block found' event processing.

On both occasions, I stopped and restarted GUIMiner for the affected miner and share accepted activity on my pool account log resumed normally. The shares lost were not recovered.

On one other occasion, I saw that all shares from both miners were reported on my account log as if they had all come from one of my miners with the other showing no accepted shares.  As best as I could determine, this also was related to 'block found' processing on the pool.  That is, after finding a block, Slush's pool merged all accepted shares from both miners into one of the miner's accounts.

I hope this information might prove useful to Slush.

Luke, I reported simultaneous crashes on two machines when my network connection to Slush's pool was lost.  I had not configured a pool rollover, so I'm not certain that a pool-switch was involved but it seems likely that one was attempted.

To answer your underlying question: yes, both machines were AMD 7770 GPUs running under OpenCL.

I had two instances of BFGMiner 3.0.0 crash simultaneously today; each was running on its own computer.  Both video cards are MSI Radeon 7770 running AMD's Catalyst 13.1 on Windows 7 64 bit OS.

There was an interruption (my ISP connection went down) followed by a new block detected message and both instances of BFGMiner 3.0.0 trapped.  Due to the trap, I wasn't able to gather any further info.

Machine #1

Faulting application name: bfgminer.exe, version: 0.0.0.0, time stamp: 0x515f07a4 (2013-04-11 17:22:45.000000000Z)
Faulting module name: bfgminer.exe, version: 0.0.0.0, time stamp: 0x515f07a4
Exception code: 0xc0000005
Fault offset: 0x000000000000bf96
Faulting process id: 0x1b28
Faulting application start time: 0x01ce3647d3d57e57
Faulting application path: (removed)\bfgminer.exe
Faulting module path: (removed)\bfgminer.exe

Machine #2

Faulting application name: bfgminer.exe, version: 0.0.0.0, time stamp: 0x515f07a4 (2013-04-11 17:22:45.000000000Z
Faulting module name: bfgminer.exe, version: 0.0.0.0, time stamp: 0x515f07a4
Exception code: 0xc0000005
Fault offset: 0x000000000000bf96
Faulting process id: 0x264
Faulting application start time: 0x01ce35ec278316ab
Faulting application path: (removed)\bfgminer.exe
Faulting module path: (removed)\bfgminer.exe

Model path names contain identifying information so I removed those details.

They weigh but a bit.