Could you explain outputs or provide a link? The wiki Transactions doesn't cut it for me. To me, when I send bitcoins, I collect a bunch of addresses, add up their balance, and using each address, sign the fact that I am redirecting their total balance to a new set of addresses. The 'output' is just the amounts, the destination addresses, the same tiny script 99% of all transactions use, all wrapped in my address signatures. As long as I know my address balances have not changed, what state change could have happened? My understanding of 'output' must be horribly naive.

Your understanding is correct, you are the only one that can effect the state of outputs for your wallet. One though clarification when you create a transaction you redeem specific outputs which target your address so you can't make a transaction just by knowing the address balance.

Is it possible to take a minimal wallet and encrypt it with the recipient's public address and send it to the recipient side channel? In theory, couldn't the recipient use the associated private key to decrypt it? (Are elliptic keys reversible in the same way as RSA?) If this were common, wouldn't bitcoin truly be anonymous, every transaction plausibly deniable?

In theory would work, but the problem comes with distribution. To anyone other the recipient the transaction would look like gibberish so how would they know it i the transaction is spam/ddos attack etc. And then how would miners verify the transaction without the private key.

Is it possible to take a minimal wallet and encrypt it with the recipient's public address and send it to the recipient side channel? In theory, couldn't the recipient use the associated private key to decrypt it? (Are elliptic keys reversible in the same way as RSA?) If this were common, wouldn't bitcoin truly be anonymous, every transaction plausibly deniable?

In theory would work, but the problem comes with distribution. To anyone other the recipient the transaction would look like gibberish so how would they know it i the transaction is spam/ddos attack etc. And then how would miners verify the transaction without the private key.

Wait a second, today, I can PGP encrypt my wallet and give it to you. Once you decrypt the wallet, you can do whatever you want with that wallet in the blockchain or side channel again. The only additional cleverness is rather than PGP, I'm just using your public elliptic key (associated with an address in the blockchain) because I'm confident you have the private key. I encrypt an entire wallet with your public key, email it to you, and you decrypt it and do whatever you want with the wallet. The blockchain is no wiser.

Wait a second, today, I can PGP encrypt my wallet and give it to you. Once you decrypt the wallet, you can do whatever you want with that wallet in the blockchain or side channel again. The only additional cleverness is rather than PGP, I'm just using your public elliptic key (associated with an address in the blockchain) because I'm confident you have the private key.

Or just upload an unencrypted wallet.dat, SSL (https upload) will keep the contents of the wallet secure.

I encrypt an entire wallet with your public key, email it to you, and you decrypt it and do whatever you want with the wallet. The blockchain is no wiser.

That's a feature I was thinking might be useful -- a service that would import a wallet and all its keys. Because there is no easy way yet for (non-technical) people to merge wallets, those with multiple wallets (e.g, from a laptop and a separate on a desktop) are abandoning their old, empty wallets. But perhaps some payment will still arrive to one of those addresses -- that happens enough to where people are storing an archive of their wallet now, ... just in case someone sends bitcoins to an old address. If that wallet were to be imported on BlockChain.info, then all those keys from that old wallet could be retained.

At the time, I considered it to be a separate service -- a "wallet cemetary", where the service would take a cut should any bitcoins be received to those old addresses. Maybe that would just be one of the methods for moving from a local, Satoshi client wallet to BlockChain.info's Wallet.

Well, yes, I've got a wallet cemetary of my own for different reasons. Merging/importing wallets is an obvious missing feature from the C++ client (I'm frustrated by the conservative - can't confuse the idiot's - mentality of the core developers).

But that's not the motivation of my thread here. Basically, I would like to be able to send bitcoins to another individual side channel (not in the block chain). The easiest way to do that today is just to give them a copy of a new wallet. While we're at it, why not encrypt the wallet. In fact, why not encrypt the wallet with the recipients own public bitcoin key (from which one of their addresses was derived).

In theory, the recipient could pass it on to a third party, and he to a fourth, and a fifth, ad infinitum. Of course, each recipient would be taking on enormous counter-counterparty risk, but the possibility allows for plausible deniability. Whenever a bitcoin actually hits the blockchain, even with a guilty 'paper' blockchain trail, one could simply claim 'wasn't me'. I passed that along side channel to a friend to a friend to a ... who knows how many times.

That's a feature I was thinking might be useful -- a service that would import a wallet and all its keys.

This is second on my list of things to add, native import and export in wallet.dat format. Although why does the mainline client even need to use berkelydb for wallet.dat? Surely it would be better to use a human readable format to make it easier to repair in case of corruption. JSON would probably suffice.

First I want to make sure security is tight enough so yubikey and SMS two factor authentication are my priority for the moment.

That's a feature I was thinking might be useful -- a service that would import a wallet and all its keys.

This is second on my list of things to add, native import and export in wallet.dat format. Although why does the mainline client even need to use berkelydb for wallet.dat? Surely it would be better to use a human readable format to make it easier to repair in case of corruption. JSON would probably suffice.

JSON would be nice for manual editing, yes. But it may be much worse for bitcoinds used as servers (with Gb-sized wallets).

Are any incorrect or am I missing some? It could be that I cannot connect to your node, are you at the connection limit?

None of this IP is mine :-). Please try to connect to 176.31.157.133. Right now the node is on connection limit, but time to time some peers close connection. Or give me any of your static IP and I'll add it to my trusted IPs list.

I took a quick look. It looks rather costly to actually use on a website. free up to 10 users but $3/user/month after that. Doesn't sound fit for a free wallet service... except perhaps as an optional service that costs at least $3/month. I can see how it could be useful but it feels overpriced for a web-wallet unless you're keeping astronomous amounts of wealth in there.

I took a quick look. It looks rather costly to actually use on a website. free up to 10 users but $3/user/month after that. Doesn't sound fit for a free wallet service... except perhaps as an optional service that costs at least $3/month. I can see how it could be useful but it feels overpriced for a web-wallet unless you're keeping astronomous amounts of wealth in there.

Every user would create their own implementation with an API key and secret, effectively negating the need for piuk to even sign up for the service. The API key for a specific wallet is passed at runtime, and I would assume using existing Yubikey backend code with minimal modifications wouldn't be too difficult.

Next feature I'm really craving is QR codes. Any plans for them on the receiving addresses?

I was just going to ask the same question. And am I understanding this correctly: the private key is stored encrypted on the servers and the encryption is handled by my browser? So if someone were to steal acquire the data they would not be able to spend my coins?

Losing hundreds of Bitcoins with the best scammers in the business - BFL, Avalon, KNC, HashFast.

As far as i'm aware My Wallet is the only wallet service to offer two factor authentication (other than Mt. Gox). Existing Mt. Gox yubikeys should be compatible.

This is cool, but seems a little bit dangerous for this application. What happens if you lose your yubikey or drop it in the toilet? Can you order a duplicate Yubikey as a backup? With mtgox it's a bit different…if you lose your key, you can always verify your identity and get them to restore your access to your account.

And am I understanding this correctly: the private key is stored encrypted on the servers and the encryption is handled by my browser? So if someone were to steal acquire the data they would not be able to spend my coins?

Yes, correct, assuming your passphrase is strong and your computer has not been compromised.

I've been trying this out and it's working great. Nice interface and versatility.

I've kept an encrypted backup of the wallet locally but I have a question. If your site vanishes is there some tool (prefer linux) or process documented that can read the wallet.json.aes file format and decrypt it so we can get to our keys?

Wait a minute - I just saw that you now charge a 1% fee on outgoing transactions. Is that new? I thought a few days ago it was a free wallet and you were thinking about advertising for support?