I can't believe I'm the first person to ever mention this idea, but I can't find reference to it anywhere else on the forums. Perhaps I just suck at searching. I found a few similar posts, but most are based on remember-able passwords, which I
am not proposing. Sorry I've mentioned this in a few different posts, but I wanted to start a dedicated thread for wider feedback.
I would like to see the current address pool technique in the wallet replaced with a process of deterministic key generation. The idea is that when a user first fires up Bitcoin, it will either generate a random 256-bit key for them, or the user can supply their their own random bits (flip a coin 256 times, put results in a file). The point is for them to have a full 256-bits of entropy in this "generator," so there is no need for key stretching or any kind of salting, nonces, etc. This would be the "master" key for that user
forever (or until they decide to change it). After that, every time the user needs a new address, the client calculates it via:
PrivKey[i+1] = sha256(sha256( GenKey XOR PrivKey[i] ))
This provides a semi-infinite number of private keys that can always be recreated only from the original generator key. Then
the user only has to backup one file, ever. Save it to paper in a safe-deposit box, or get it tattooed to the underside of your eyelid, because you never need to update your backup.
I only see three potential problems:
- (1) Weakest link would be the random number generator.
- (2) If master key is compromised, so is every wallet address.
- (3) Weaknesses due to "relationship" of keys via SHA256
Problem (1) is "easily" addressed. If the client creates the generator key for the user, it could go through a process of pulling entropy from mouse and keyboard events, or known physical processes that can be measured from the user's computer, such as thermal/voltage oscillations in CPU/PSU, RAM cell values after reset, etc. The client could be set to reject anything that isn't exactly 256-bits or contains too much human-esque entropy. The user would have to either use the client dialog for creating the generator, or figure out how to supply real entropy.
Problem (2) doesn't actually seem like much of a problem to me. I can't think of any attack that would compromise one private key of a user and not all of them. They're all stored in a single wallet file, and any attacker is going to copy the whole file if they get access to it. So, by reducing your entire wallet to one private key, I'm not sure any security is lost.
Problem (3) is a problem only if double-sha256 hashing is broken, and if so, all of BTC is screwed. It could be replaced by sha256^10 if it makes anyone feel better, or a mixture of hashes, and self encryptions (perhaps use itself as an AES password to encrypt itself before hashing).
Simple, secure, and useful. Thoughts?
