Again, this can be achieved by using a password to seed a deterministic wallet. It's literally the same thing you're trying to do, except that the "wallet" is stored directly in the blockchain. (more precisely, the wallet would no longer exist, or need to exist, since it's generated by a password)
Of course, it would be incredibly insecure unless your password was as long as an address and had a good amount of entropy.
Yeah, we're splitting hairs. I was just thinking about how to use the current system with a wallet. It maytake more dev work to do it your way, and its less robust.
On the contrary, deterministic wallets are already on the roadmap to be added to the Bitcoin client (don't quote me on that, since I'm not completely sure that's true), so this would require significantly less work than your idea. With your idea, we need to implement a side-channel for distributing and storing encrypted wallets. With my idea (well, it's not really
my idea...), the password
is the wallet.
Also, your 'deterministic' way requires you to remember every password/address.
On the contrary, a single password can generate a large number of addresses. Do a forum search for "deterministic wallet" and be prepared to have your mind blown. I know mine was.
encrypting the current wallet lets you maintain lots of addresses and reduces the chances that some one will target you . Remember blockexplorer will tell every one which address should target for a big payoff. It would be harder to find the "fat" addresses along with the specific wallet to attack. B/c username is not associated with an address, just a an encrypted wallet file that can access unkown addresses.
While it's somewhat true that you would more likely be
targeted under the deterministic wallet system, under your idea, you are also more vulnerable to untargeted attacks since attackers would know that most encrypted wallets would contain at least
some bitcoins. I do concede, though, that bruteforcing all deterministic wallet at once would be easier, since you just need to check if an address exists for each password instead of testing each encrypted wallet. Maybe your idea of using usernames as a salt might fix that, though.
That being said, it would be hard to actually target a deterministic wallet. The reason for this is that you can only know what addresses you cracked
after you crack them, not before.
As far as entropy. I propose doing it the wallet way b/c you can control the complexity of the encryption perhaps with a bit more granularity. Sha256 followed by blowfish, then aes etc...
You can do that same thing for deterministic wallets. Your password can go through encryption before being hashed by encrypting it with itself. After you hash it, you can again encrypt it with either the password, the encrypted password, or the hash of the encrypted password, and then hash it again just for the hell of it. As you would anytime you are dealing with passwords, the user could set the strength of the key by requiring any part of the process to run more times (they'd need to remember what they set the strength to, though). They could make it so that it'd take 10 minutes for an average computer today to generate their master private key if they wanted to, regardless of what the password is. Of course, the same can be done in your idea.
If we use a username as a salt (eg like paypayl), require 9+ character pws with punctuation, and tack on a special date (Dec 25 0000). It would be very hard for an attacker to break it. We lost hashes on this site. the pws were salted by username. I bet even a simple 123456 password got broken. Salting destroys the rainbow attack.
Sound about right?
That would likely be secure enough, yes. Whichever way you do it, though (either encrypting the wallet and sending it off or using seeded deterministic wallets), I still wouldn't trust my life's savings in it.
