I know the problems you point on bitcoins:
The fluctuation is damped down during last months, and if a seller choose a stable value for bitcoins - not tied to daily trade - it helps customers. For example, I had for 1 month and half a single key @ 0.4 btc. Then, 1 week ago, with btcs stabilized increased value [ the 30-day weighted value as showed in
http://bitcoincharts.com/markets/currencies/ ] at around 5$, I cut single key price to 0.36 btc and bulks to 0.3375 BTC @ 100 and 0.315 BTC @ 200.
Now, if btc value starts to drop, I won't change instantly price. Instead, I'll wait for the 30-day to touch 4.5$. This needs time, and meanwhile btcs can rise back to 5$: by letting the price be stable on my side, I mask to my customers the fluctuation, because they keeped buying @ 0.36 btc even during the drop, and in the end I didn't lose anything, because the value is back as expected.
I have to point that I don't cash them out until I have a real need, so until then the btcs are in my wallet and that's why I can afford to mask their fluctuations.
The risk is if I have to cash out after the drop [ not happened until now ], but I don't care, because the savings btcs give me in terms of 0 risks, 0 fees makes it worth.
Joining bitcoins is probably the hardest part. If you don't have a good ATI video card to make them, you have to buy them.
Most exchanges use bank accounts, which are very cheap in SEPA countries ( 1 - 1.50 $ flat fee to deposit and withdraw ) but I think costly in other places.
Mtgox uses dwolla, but I don't know how it works
Some use Linden Dollars as a means to buy bitcoins with paypal, as in virwox.
Then there is the otc maket, where you can buy bitcoins via moneypak, amazon codes and so on.
All this is not as simple as a paypal transfer.
However, if more people start using it in the tf2 market, it would be easier for everyone to get btcs by selling all kind of tf2 items, even weapons: due to 0 fees, trading 1 weapon for 0.009 btcs is not a problem. The transfer itself is very simple - just write your address - and the broadcast reach the client in < 1 min.
And I save a lot of time and headaches by not needing to check anything about the bitcoin buyers trust, I just ask them to go first and that's all.
For proof of identity, I'm not sure what you mean. You can still use rep threads, steam rep and all that's already used with paypal, and if really needed, you can also use a GPG identity over bitcoin otc - only I have my private key and only I can auth there with my nickname & public key.
For the fluctuations, other than that I said before, if you want to quickly convert, you just have to:
1) place a sell order before you even get the bitcoins
2) tell the buyer the mtgox adress
When the btcs are sent, they are sold, at no loss: it's just a normal trade.
Details here:
https://bitcointalk.org/index.php?topic=55921.0
For the steam part, I would say that this would not solve the problem: we see this with games today.
Let's say that you can view a 5$ tradable game as a 5$ wallet that can go around.
The game for item trade is escrowed by steam trading.
But, what happens when the original buyer of the game from the store place a chargeback on paypal? steam removes the game. The seller of the tf2 item, loses both the item and the game -> he gets scammed.
And the funny thing is, that the game can be traded many times before the chargeback of the original buyer: the last one, who gets scammed, doesn't even know if the scammer is the one who traded with him, or the one who gave the game to the one who traded with him, and so on... So he can't even report a scammer.
Now, if the wallet becomes tradeable, steam would simply remove the funds from the seller account. If there are no funds on the account, it could force to lock the account until the balance is 0. The seller loses both wallet and the item -> he gets scammed the same.
Because game chargebacks/scams already happens, wallet chargebacks/scams will happen too.
For the last part, i'm not sure on the needing of all this security, but you can achieve something via GPG, for example:
A gives public key to B
A generates a message and encrypts it with B's public key
A asks B a postal address where to send the encypted message
B needs to give real address to get his hands on the message, decrypt it and tell A the original message.
Now A knows B's claimed identity is real
B can do the same to know A's postal address.
By needing a physical access to the message, it can achieve what you said. You can add other constraints, like requesting a job's address, or tie the message to a bank transfer. That's what I can think right now that forces a real name involved - no online method can really be trusted, so offline is the only way.