You laugh heartily, or you hardly laugh?

http://www.youtube.com/watch?v=D1hC0nIagH4

Well the hardware error indicates not necessarily a 'hardware error', but a bad hash was detected outside the running OpenCL kernel by the first validity check:

In __init.py__:

 if not hash.endswith('\x00\x00\x00\x00'):
                        self.interface.error('Unusual behavior from OpenCL. '
                            'Hardware problem?')

So to get this error, either the SHA hashing math or the hash checking in OpenCL was corrupted, and an invalid hash was returned as a valid share. If this happens, then it is also possible that a hash that would be a valid solution could be corrupted and not returned or sent.

Diapolo's 7-17 kernel is also more sensitive to overclock than previous ones, and will start returning the 'hardware error' at overclocks where 7-11 doesn't. Either a different stream core instruction on the die is being used that doesn't overclock well, or the higher utilization causes some failure. My way of thinking is you don't want to overclock to the point where any bad math is happening in any stream processors. If you have to overclock 5% less on a kernel that is 1% more efficient, then you lose any gains.

BTC could be six dollars in three hours...

Have you done any port-forwarding in the router, or do you have multiple IP addresses from your ISP? It is my understanding that if you port forward 8333 to one computer, you will completely kill bitcoin for other computers on your local network.

I am referring to the case of the original poster, not your followup posts which may or may not be the same issue. At this time I have not reviewed what you have posted closely, but it is important to note how the Bitcoin transaction fee policies come about:

-0.01 BTC fee per kilobyte of transaction, but:
  -If the blocksize (size of all transactions currently waiting to be included in a block) is less than 27 kB, transactions are free.
  -If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.

-If the blocksize is over 4kB, free transactions in the above rules are only allowed if the transaction's priority is above a certain level.

-Transactions within each fee tier are prioritized based on several factors. Most importantly, a transaction has more priority if the coins it is using have a lot of confirmations. Someone spamming the network will almost certainly be re-using the same coins, which will lower the priority of their transactions. Priority is also increased for transactions with more BTC, and reduced for transactions with more data.

You can see the more factors in play, the lower the priority. Version 0.3.23 requires a minimum of .0005 BTC for low priority transactions.

This means there are several factors involved whether the bitcoind that p2p network members and miners are using relays a transaction or includes it in a block, and the newer version of bitcoind have different rules.

I can deduce from the screenshot that the original poster's bitcoin address is 1NUd7YZYkVYoue7BgY6URsfKCLDRnu7CgL. Here are the transactions that were picked up:

http://blockexplorer.com/tx/fc7f3b9b37ebd99a5c4479938f017425457aa392478dae4deed20382cf7a0778#i621162
fee paid: 0

http://blockexplorer.com/tx/4b66d56b8b9fed33f94c21082b6f0756c407c6f41e967dcf94b304c67210b3cb#i727079
fee paid: 0

http://blockexplorer.com/tx/400f321bf6d058d5ed59acc18a25cbf16976fc96bf13f7009c435f307c637209#i872806
fee: 0

http://blockexplorer.com/tx/e995efbd5e993293e393f4b92e3d082f6be4bfa3f05bb7bfc0681dcdd2fd8d4f#i888845
fee: 0

(un-relayed transaction here)

http://blockexplorer.com/tx/cdce1cf30ab041015ae5150eaa8702bf1d37ab1d27c50030bcbc8f6cc4184951#o0
fee: .1

As we can see, there's a lot of no-fee paying. If you read the rules above, you see that several factors affect whether a free transaction gets forwarded or included in the block chain - how many other transactions are already waiting to be included in a block, how recent the coins are that are being used (note the original poster just received a payment the day before, new coins could have been used in the transaction), the size of the transaction, etc. The current bitcoin client will evaluate these rules and indicate the fee to be paid on the transaction, and the other clients know these rules and can decide to toss it in the bit bucket if it doesn't qualify to be free. Note that the client version of other clients on the network gets updated, so previously lenient rules may be more enforced.

While you can set the TXFEE=0 in the newest client's config file, it will not allow you to send transaction that would require a minimum fee (at least not without some hacking or using a non-official version). If the newest mainline client doesn't prompt for a fee, that's because you are in the rare position of using old coins, there are low transactions waiting on the network, and the size of the transfer in KB is small (mainly because you are spending just coins from a single input.)

If I keep my $100 without spending it, how long until that $100 is free?

Loosing coins? Don't you mean losing coins? I'm not afraid of coins on the loose!

Bitcoin counters this by having a unit so small that currently 100,000 of them = $0.01. When one Bitcoin is worth $1,000,000 then we may have to re-evaluate, but probably not, because for the currencies to be off by that much, a loaf of bread would probably cost $1,000.

You must shut down the Bitcoin client and confirm it is not running before making a backup of your wallet. If you do not do this, it is likely your backup will not work correctly. This is a good way to lose many coins.

In addition, if the Bitcoin client does not find a wallet.dat file in the data directory when it starts, it will silently create a new one. Again, you cannot restore a backup over the newly created one with the bitcoin client running.

I would first be checking the 'recycle bin' if this is windows, to see if you can restore the wallet as it was when you pressed 'delete', or use other undelete/file recovery utilities at your disposal.
You should completely shut down your bitcoin client (or even restart your computer), and then see if it can be restored and check it's operation. If there is nothing to be found from deleted files, then place the wallet backup into the bitcoin directory and see if it will run. Do you have error messages when bitcoin runs?

If the wallet.dat file will not allow bitcoin to run, but bitcoin will start up and create a new wallet.dat if there is no wallet.dat in its data directory, then you need to attempt data recovery on the wallet.dat file, either using a repair utility to fix a corrupted wallet database, or an import/export tool to attempt offline export of the private keys out of the wallet. Do not directly repair your USB backup; keep the backup file untouched, as it now appears to be your only copy and you don't want to mess it up further.

Fees are required in most cases, it is part of the design of Bitcoin to compensate miners for the work they do making it cryptographically difficult to attack the blockchain. If you sent without fees, then you would have used an altered client that doesn't comply with the fee rules, and you get to eat your humble pie.

Older bitcoin clients (in bitcoind at least) have this option to remove unconfirmable cruft, but this does not seem to be present in .23 onwards:
deletetransaction <txid>
Normally used when a transaction cannot be confirmed due to a double spend.
Restart the program after executing this call.

It isn't luck, if you look at that site, the instant hashrate is now calculated over completely different blocks than yesterday, 139689-139809, and it is still at 94% of difficulty.

It sounds like your data directory may have a corrupted blockchain or other files.

The data directory is %APPDATA%\bitcoin, which typically resolves to C:\Users\username\AppData\Roaming\Bitcoin. Before we get started, copy your wallet.dat file in that directory to a USB stick and store it away, and copy the entire data directory to a new location, name the folder bitcoin-backup or such, so you can always put things back as they were before you attempted repair.

The easiest way to rectify this situation is to remove all files from the data directory except the wallet.dat, download a nightly version of the the blockchain from http://bitcoin.bluematt.me/bitcoin-nightly/blockchain-nightly/ , unzip these files into the bitcoin data directory, and launch bitcoin again and let it update to the latest block.

Here are your excellent chaps then:

Unless you use the -v flag for verbose logging in phoenix, set your console window so it has a log of thousands of lines you can scroll back through, and look for the "Result didn't meet full difficulty, not sending" error message, you wouldn't see any difference.

AMD Catalyst™ Control Center / AMD Vision™ Engine Control Center 11.8 Driver Preview for Windows 7 64-Bit Edition.

So sorry if you are using 32 bit anything...

Look here: http://dot-bit.org/tools/nextDifficulty.php
You get to see over which blocks the 'instant' calculation of hashrate was done. Right now for blocks 139509-139629 block rate is 90% of difficulty, which is more than you can account to mere luck or variability.

The output that I pastebinned is the standard console output of phoenix in -v verbose mode, I just highlighted the screen output on my console (with a 3000 line buffer) and copy-pasted it. It includes the first eight bytes of the hash in the results as you can see.

Actually when I said that it was unmodified phoenix that I was running, I lied, by forgetting I had done this modification at line 236 in KernelInterface.py (because of a difficulty bug in a namecoin pool I was previously using):

Original:

        if self.checkTarget(hash, nr.unit.target):
            formattedResult = pack('<76sI', nr.unit.data[:76], nonce)
            d = self.miner.connection.sendResult(formattedResult)
            def callback(accepted):
                self.miner.logger.reportFound(hash, accepted)
            d.addCallback(callback)
            return True
        else:
            self.miner.logger.reportDebug("Result didn't meet full "
                   "difficulty, not sending")
            return False

Mine:

        formattedResult = pack('<76sI', nr.unit.data[:76], nonce)
        d = self.miner.connection.sendResult(formattedResult)
        def callback(accepted):
            self.miner.logger.reportFound(hash, accepted)
        d.addCallback(callback)
        return True

All I've done is remove the second difficulty check in phoenix, and trust that the kernel is returning only valid difficulty 1 shares. Now, instead of spitting out an error "Result didn't meet full difficulty, not sending", phoenix sends on all results returned by the kernel to the pool. Without this mod, logs of your kernel would just show a "didn't meet full difficulty" error message instead of rejects from the pool, which would still be a problem (but the helpful hash value wouldn't be printed for debugging). We can see from the hash value that the bad results are nowhere near a valid share.

This code mod only exposes a problem in the kernel optimization code, that sometimes wild hashes are being returned by the kernel from some bad math (or by the kernel code being vulnerable to some overclocking glitch that no other kernel activates.) Are these just "extra" hashes that are leaking though, or is the number of valid shares being returned by the kernel lower too - hard to tell without a very long statistics run.

I am running two miners per GPU not for some random reason, but because it works. With the right card/overclock/OS/etc, I seem to get a measurable improvement in total hashrate vs one miner (documented by using the phoenix -a average flag with a very long time period and letting the miners run days). The only way my results could not be true would be if the time-slicing between two miners messes up the hashrate calculation displayed, but if this was true, such a bug would present with multiple-gpu systems running one phoenix per gpu too.

With only a 1% improvement from a kernel that works for me, reducing the aggression or running one miner would put the phatk 2.1 performance below what I already had. Putting back the diapolo kernel, I'm back to below 2500/100 on my miners.

My python lib versions are documented here.

Joulesbeef:
I don't like the word 'stales' for rejected shares unless it specifically refer to shares rejected at a block change because they were obsolete when submitted to a pool, as logged by pushpool. The results I have above are not stale work, they are invalid hashes.

Maybe you like not having your wallet cluttered up with new bitcoins that take transaction fees if they get used...

Using bitcoin on a virtual machine is not a problem, it just adds one more layer of things that can break, like the day you can't mount your virtual hard drive.

The data directory is %APPDATA%\bitcoin, typically C:\Users\username\AppData\Roaming\Bitcoin. If you don't know where this is, you probably haven't backed up your wallet, which should be the first order of business - copy the wallet.dat file there to a USB stick and store it away, or 7-zip it with a strong password and email it to yourself, etc.

If the rescan option didn't work, then we next must suspect a corrupted blockchain database in the local client. Before starting copy the entire data directory to a new location, name the folder bitcoin-backup20110804 or such, so you can always put things back as they were if you screw it up.

You can then remove all the files in the data directory and the 'database' subdirectory except the wallet.dat. If you were to re-launch bitcoin now it will have to download the entire blockchain off the p2p network again, which can take many hours. To give it a head start, you can unzip the files from the bitcoin_blockchain_120000.zip file at http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/  into the bitcoin data directory. This download includes the blockchain up to April 2011, but still will require a normal p2p download and rescan of blocks 120000-139580, which is probably where your missing transactions are.

If after removing all old blockchain and database files the bitcoin client and letting the bitcoin client bootstrap from the network again, you are still getting an error about missing transactions and versions (and you've re-installed the client), then the wallet.dat is the only thing left that could be giving you problems. Were you ever running a different or forked version of bitcoin? Perhaps running that old client software will make it work correctly and you can get the bitcoins out. If you do not have a wallet.dat backup, then the only way to proceed after that is to look at corrupted wallet repairs.

Maybe you should complain to pools that are raking in the BTC in pool fees but paying 0 transaction fees when sending out payments to users.