Oh, man. Why did you send the 1? Were you just testing to see how the backup worked? Why with so many coins?

That sucks.

It sounds like you have wallet.dat that contains the private keys for Address1 and Address2, but not Address3.
(Although the numbers in your story don't add up.)
What were the Bitcoin addresses? (If we know these we can do some more in-depth block chain research)

Do you still have the wallet.dat that once "contained" the 9000 BTC? I might be able to help you.

The value of BTC has risen a lot in the few days I've been here. I notice lots of prices that are high now because people aren't used to adjusting downward quickly. Obviously the increase in value will slow down, but in a longish auction you might end up getting bids in the beginning and then no more because the BTC are more deal at the end of the auction than they were at the beginning. I'm not really saying much here, just that I'd expect people to prefer short auction lengths. Of course not too short because you want enough people to see it before it goes offline.

...
If I generate an average of 13 blocks a month at the current difficulty, BTC 650, that puts my cost at about US$0.005/BTC.

In short, I'm better off buying BTC from the exchange than generating them on this particular machine.  Food for thought.

I added a new answer to the FAQ about the value of Bitcoin.

You can't, read the rules:

Internally, bitcoins are bundled into packs of 50.00 or however many get sent over the network. Bitcoins usually have to be re-bundled each time they get sent. If a certain very large number of bitcoin bundles have to be re-bundled, there is a very small fee which the sender has to pay. The fee goes to the bitcoin client (yours in this case) which verifies the large re-bundling. It's not a well known behavior and I hope that future versions will display a warning or confirmation before such a fee is charged.

There is a post somewhere with more specific details. I'll look for it for a few minutes and I'll edit this post if I happen to find it. As always, the source code, which is open source, will reveal the exact behavior. I haven't examined the code and my description of the behavior is based on my poor memory, so it might not be exactly correct.

Edit: Here's the explanation I mentioned. It seems that if more than 500 bundles of bitcoins are re-bundled, there's roughly a 0.002% fee. So during that ten minute period, one or more people each re-bundled 500 bundles of bitcoins, totaling roughly 132,000 bitcoins.

Since the sender pays the fee, I'd like to know what happens when a person sends all their bitcoins. I would expect that if there weren't enough bitcoins to cover the fee, then the amount of the fee which can not be paid would be subtracted from the payment. If this is not the case, then the fee could be avoided by sending all your coins to yourself before sending a large payment.

AFAIK, there are no "useful" computational problems that have the properties necessary to be used as a proof-of-work.  

The hash function is used because it is irreversible, easily checkable, small in size, and probably some other things I'm forgetting.  Even if you could, for example, encode the transactions as a polypeptide (chain of amino acids), and then made folding the polypeptide into a protein the proof-of-work, such a proof-of-work could not be checked without redoing the entire computation.

Even if you could come up with a suitable problem, due to the economics of BC you would never actually generate any additional value by using a "useful" problem.