On a side note, I got the client to continue updating again. I restarted the stuck backup and for now it's updating again.
Not sure if it was a coincidence that I shut it down the moment it was maybe done with the block, or if the restart made it skip the block in question.
A few blocks took several minutes (like 181917) but eventually completed. 130 blocks left right now.

I don't want to accuse the devs of the alternative clients of anything, but when it comes to money-related things I prefer sticking to the original; probably others think in a similar way. Maybe it would a good idea to release the original client "optimized" (thin client) for the ordinary users and add the options to switch to a "full" node in the options tab.

52GB/yr is still a lot. Is the idea of a distributed blockchain where each node only holds 1-2GB out of question for a reason I'm missing? With such a "storage cluster", space would be less of an issue. Out of curiosity, what happens when the growth would exceed 52GB/yr?

I ran into that with the 0.6.2 client released by Luke-Jr (https://bitcointalk.org/index.php?topic=82581.msg910320#msg910320) and I verified the checksum. Ran it on a XP-VM with 1.5GHz and 512MB RAM. Blockchain is accessed via a share. Most blocks were processed rather quick; usually just a few seconds per block, sometimes a minute or three. But when I noticed that the VM was eating up CPU constantly, I took a closer look; and block 181868 was being processed until I gave up after ~15 mins.

My bad then. I was working with an old 0.3.x client until recently and there I needed pywallet. Seems I didn't check if the 0.6.x releases already added that. Sorry for the confusion.

First of all, I like Bitcoin and the whole concept behind it. But there are some problems which need to be addressed if it's meant to succeed. This rant is not only based on my experience, but also on results of introducing Bitcoin to other (non-tech) people.

1. Blockchain size
(I'm using the sizes of the snapshots starting Sep/2011, provided by Bitcoincharts for my estimations)
On a rough average, the chain grows by 10% each month, although that may be too low, seeing that in May, it grew by 20%. Even if we just assume 10%, the chain reaches 2.6GB Sep/2012, and 8.2GB Sep/2013. On Sep/2014, it should be around 23GB. With a 20% monthly growth, the Sep/2014 chain will need 220GB. At this point, nobody will bother anymore. The initial blockchain download will become impossible. This needs to be fixed before users start dropping Bitcoin because of that. If each client would only provide 1GB local storage, that too adds up. Even with only 10,000 users there would be 10,000GB combined storage which is enough to store each block multiple times to provide redundancy (think of it as a p2p-raid).

2. CPU load
Some of the large blocks hog CPU, making it a pain to catch up. While waiting for the update to complete, I got stuck at block 181868 (526 tx) for more than 15 minutes with 100% CPU. It got so annoying that I stopped the client after that time. As a result, I'm currently stuck with an outdated chain. It's become easier to just download a nightly snapshot and do a rescan than letting the client update a few days; even though this takes ~5 hours on my connection. Yet with the next big block, the problem arises again. People should be able to skip verification, maybe in exchange for a malus like less frequent updates (e.g. every 30 mins instead of 10mins). Or only verify max 20 random transactions per block. Or a button to skip verifying the current block. This is not only a problem for users of older PC's, but also for lightweight hardware.

3. Simple management tools
While most of the users won't have to deal with internals, it still should be possible to manage wallets easily. I can extract keys via the pywallet tools after setting up Python, but a simple standalone tool should come with the client itself. Having said that, the devs of the various clients should agree on a wallet export/import format (XML?) to make it dead simple to switch between different clients.

4. Merge coincontrol
This is not a problem but a feature request. I've used the 0.6.2 release with coincontrol merged in recently. You quickly get used to this great extra and miss it in the official releases.

</rant>

I'm interested too.

So if I understood correctly, it's 6.9%/week with compound interest, right?

Got a #bitcoin-otc rating by any chance? Or someone with an otc rating backing you? Nothing personal, but I'm curious after your "no guarantees or insurance" reply (even though I understand your point).

Instead of requesting a payout, is it possible to agree to a fixed term? Like, automatic payback in 3 weeks? Less for me to remember, and easier for you for planning.

You can PM me an address so I could send 20btc either today or tomorrow.

In case you are running a Linux system, there's a thread about a recovery tool which scans for private keys on formatted devices.

To make the scan quick, you could create a small file (~10MB), partition+format it and then loop mount that as another device. Copy your wallet onto that device and try to scan this device.

If you're on Windows, maybe one of the trusted members here would take a look at your wallet.

Granted the thread is a little old, but maybe the tool still works:
https://bitcointalk.org/index.php?topic=25091.0

Nothing changed for me; except it's 0.0025 instead of 0.005 now.
I still have to disable adblock to see anything but a grey box.

So you don't keep track of your transactions?

It's an address you've used before, so check email, PM, IRC logs to see who sent it to you. I understand that it would be close to impossible to find out who owns a randomly created, valid address, but if you used it, it should be trivial. That's why you tag your addresses.

Only? If those are peanuts to you, feel free to give me some 

Assuming that the owner of the address is a member here, maybe you could ask Maged if he would send out a newsletter to everybody for a small donation.

I don't think everybody will read your thread.

Might be the way you name things: http://www.fanboy.co.nz/adblock/opera/urlfilter.ini

It does not block each and every ad. For example, coinad and dailybitcoin work just fine with the plugin enabled.

If you have Opera installed, you might want to give it a try. I'm using the main blocklist and the tracker block.
Having Ghostery installed is also pretty common and might affect it too.

Works if I disable Opera Adblock.

You might want to work on that since this plugin is very common in both Firefox and Opera.

Looks still the same in Opera

HTML validates now successfully, except for 5 warnings
CSS hasn't changed

Btw, on w3.org you can do the checks

Looks the same for me.

You might want to fix your errors:
HTML: 28 Errors, 8 warnings
CSS: 4 Errors, 112 warnings

Your source is overloaded with JS includes (27 if I counted correctly) which will have a negative impact on performance.
There are many empty div/span tags too.

You can create a new, empty wallet and use eg pywallet to extract the private keys from your old wallet and import them into your new wallet. Try it with just a few keys (or one only) first, use that temporary wallet with a rescan and send the coins to another new wallet.

Should work to get around this problem; however, a fix of the source to avoid that would be nice.

Also, not seeing the source/destination address in a transfer to yourself is not helpful either.

I can't really offer a fix, but I ran into the same problem: https://bitcointalk.org/index.php?topic=81473.0

Perhaps it's possible to narrow down the cause. For me, the bug appeared when I played around with im/exporting keys. Everything was perfectly fine until the client picked up confirmations for the "to self" transaction.

What?

Anyway, the dump is nothing but a text file which can be opened with any standard editor.
I already erased the dumps I played with before, so I cannot look up the prefix for the private keys.

But I remember that it wasn't very complex. Create a new unencrypted wallet and just copy+paste a string into the key field and it'll tell you if the import was successful.
Also, I think I had to switch the format option from base58 to hex.

getbalance() returns the wrong balance, lacking 0.018btc in my case
getbalance("*") returns the correct value, just like summing everything up in a spreadsheet does

However, the blockchain is up to date and the transaction is confirmed.

Since I wasn't too clear about it in my first post, I sent more than the 0.018btc. Sorry if that caused a confusion.

Is "(n/a)" instead of the target address in the transaction window normal?

Blockcount doesn't really matter. As said, I checked without a blockchain and network access. The sums are just listed as unconfirmed instead.

I've been playing around with pywallet and dumped a private key of one of my addresses. Then I imported it into a brand new wallet and ran a rescan which worked just fine. From that wallet, I sent everything to a new address in my main wallet (via the newest client), closed the client and started my old client with a rescan again which ended up with a "Payment to yourself" entry. Looking at the transaction details, the debit and credit values are identical, without any fees.

At that point I noticed that my balance was less than before.

So I started a XP machine without network and opened the backup wallet and the current wallet in the 0.6.2 client (without a blockchain). The difference is exactly 0.018btc.

To investigate this, I exported all transactions of both wallets into two csv files, opened them in a spreadsheet and summed up the transactions: both results are identical, not missing the 0.018btc.

It seems like the client has a bug when it sums up transactions which contain a transaction to yourself. Also, it does not display the receiving address/account, making it impossible to keep track of the target. Even if I search for the address I sent the coins to in the transaction list there are no results. However blockexplorer.com/blockchain.info show the address; it would be really handy to have the official client diplay it too.