Mike, thanks for the pointers.
Stefan Thomas' WebCoin project provides the sort of thing you imagine as being a "gateway". WebCoin servers are full Bitcoin nodes that expose an API to WebCoin clients allowing them to find transactions relevant to them, download them, and upload signed spends. WebCoin is implemented in JavaScript and allows web browsers to store and manage keys/transactions. WebCoin servers are not a P2P network, but you can use them interchangeably as they are (as I understand) stateless.
Yes, I had seen this project back in May shortly after Stefan released it. I wasn't able to get it working at the time, but I'll try it out again. I just looked over it again and I am quite amazed. The approach Stefan is taking is exactly the same as proposed in the paper. The send bitcoin transactions are created and signed by the browser based client and passed on to the Webcoin server; thus only the client has access to the private keys stored in the wallet. That's perfect. The wallet is encrypted and stored locally as well as on the Webcoin server. This is headed in the right direction. The next step would be to have the Webcoin servers connect with each other to form a structured P2P network to provide a distributed hash table (DHT) for true cloud storage. Once the DHT is in place it can hold all kinds of mappings to facilitate additional features like sending bitcoins using email addresses or sending a bill.
Startup time on todays software has been known to be an issue for over a year. The fix is complex and the people who have the skills to do it are largely on vacation at the moment. It'll come.
I think the Webcoin client should already have a fast startup time. As long as the client does not have to download and process the block chain and can make a request to the server (that processes the block chain) to get transactions for just the addresses it cares about, the client should be fast. The Webcoin client and server seems to be operating this way.
A 1-1 mapping of email addresses to public keys has poor privacy: it means anyone can see the payments you've received without access to your wallet. There is a patch floating around that provides an email-to-key mapping scheme that (if I recall correctly) doesn't have that problem. But I haven't found the current scheme to be so problematic, because before sending money to somebody you almost always communicate with them beforehand and they can then simply include an address in one of their replies. That's better for them because they can label it, so they can easily keep track of where payments are coming from.
The privacy is not degraded, because the email address does not map to a public key that represents a bitcoin address. The mapping is more like this:
email -> public_key
public_key -> [list of bitcoin addresses supplied by the client]
getAddress(public_key) - gateway returns only one unused bitcoin address from the list for someone that wants to send coins to email
getMyAddresses(public_key) - gateway returns the complete list of bitcoin addresses and payments received to them, but only if you can prove that you own the public_key
So this actually enhances privacy since a different address is used for each payment and no one knows who is associated with the receiving addresses.
In my opinion the use case for sending money to an email address without any prior contact turns out to not be that important, given practical experience.
We could use IP addresses instead of domain names, but most people prefer domain names. Likewise, millions of people have been trained to accept sending money using an email address thanks to PayPal. When these people give bitcoin a try and find they have to use cryptic addresses to send money, they think this stuff is not ready for prime time yet and move on. Features which enhance the end user experience can make or break a product even though they may seem insignificant from a technical perspective.
Aside from the ease of use issue there are practical cases where sending money to an email address without prior contact is necessary. For example if WikiLeaks wants to receive donations they have no choice but to post their bitcoin address. It would be great if they could give each person that wants to send a donation a unique bitcoin address. If instead they asked people to send bitcoins to their email address the gateway would take care of dishing out a unique bitcoin address for each donor.
Wallet security in the face of compromised hosts is a problem you can't solve without some kind of secure path to trusted hardware. That, in turn, is infrastructure that would have to be provided by a kind of "bitcoin bank". Yes, it means a bit more centralization, but it's optional if you're confident you can keep your computer virus free (eg because you only ever use it for Bitcoin and not general web browsing). And there's no other way to do it. You can't do finance from only a compromised host, period. The constant stream of massive thefts reported by Krebs is strong evidence of this.
Since the wallet file is encrypted using a long computer generated password rather than a human generated password then even if the host is compromised and the encrypted wallet file stolen the attacker will not be able to crack it using brute force. So the wallet file encrypted this way is about as safe as you can get. The issue then is how do you store and keep the computer generated password safe. The solution is to encrypt the computer generated password so that you need the user's private key to decrypt it and store it on a different host. Even if this host is compromised the attacker will not be able crack it using brute force. Then it's a matter of how you store and keep the user's private key safe. This is encrypted using the user selected password and stored on yet a different host. If this host is compromised and the user did not select a strong password then you've got problems. It would be ideal to store the user's private key on secure trusted hardware. In the end the weakest link is the human generated password, but keeping this safe should not require centralizing bitcoin.
[/list]
