Quote from: SgtSpike on June 16, 2011, 06:43:20 PM

Since a wallet file is really just a collection of private keys, it seems as though keeping a text file with a collection of private key/address pairs would make just as much sense, if not more sense, than a wallet.dat file itself. Send varying amounts of BTC to each address, and keep track of the addresses on another computer so you can check them for balances in blockexplorer. Then, once PK importing is implemented into the client, you can simply import the private key relating to the address that you wish to "withdraw" from your savings wallet. That way, your wallet file never has to touch the outside world, even to withdraw. The most you ever risk is the amount related to a particular savings address, which can be limited or spread across more or less addresses based on how paranoid you are.

I'm no expert, but I've made comments elsewhere about key management in the current client. It seems that in practice, this is one area of the software that has proven to be a decided weak point. It does not yet have the polish of the rest of the system or the protocol.

In the above: while your wallet file wouldn't have to touch the outside world, the private-key in question would. So in a compromised machine, the entire balance attached at least to this key would become potentially vulnerable, and I think that is what you were saying. So the object would be...keep a system of securely generated savings keys and distributed "deposit" payments such that losing the balance of any single key is tolerable.

All the "help BTC lost/stolen" posts I've read here seem to have this common thread of either getting tripped up by a non-obvious-to-the-lay-user way in which wallet.dat works, or (possibly) getting unsecured private key material pinched by malware (I haven't read the earlier posts in this thread, but what I have read does not yet include any substantial evidence of any specific attack mechanism actually in use, so I'm guessing inadvertent user mishandling of wallet.dat is far more prevalent.

I hope the dev's don't try to re-invent the wheel when addressing future improvements to wallet.dat. I guess encryption of this file is a priority for a future release. I'm hoping that's only a stopgap to calm things down while the development effort struggles to catch up to usage needs.

It's my amateur opinion that wallet.dat needs to be rethought entirely.

I much prefer the notion to key management employed by GnuPG. All key material can be independently generated and addressed. The user interface provides you with total control over all aspects of your key material. Public vs. private key material are segregated within the software and are aggregated onto separate "keyring" files, allowing discriminating treatment, if paranoia/safety concerns dictate.

Plus, they do some clever things with the private key material, like encrypting it and using a cipher with a long setup time (i think it's BLOWFISH), so that brute-force passphrase searches are made impossible (as it takes a non-trivial amount of compute time to setup the cipher after supplying a test key).

Anyway...they do it VERY well, and in much use it's proven to be quite safe and reliable. The defaults are sensible to keep newbies out of serious trouble, but the power-users have ready access exacting control without resorting to weird kludges outside of the UI.

The anonymity features of wallet.dat could (and probably ought) to be built on top of a more GnuPG-like implementation of key management. And, I don't think this should be on by default. Rather, client-software documentation or a pretty UI section could explain the mechanism and what it's implications would be, and the user can then opt-in.

I keep mentally coming back to the picture of having others sign ownership of BTC over to me by using my public key, and my spending that BTC to others by signing ownership over to them with my private key. If I want/need more accounts, I can make more keys. But let me do it. Don't keep me guessing about what the software is doing with the key material under the hood.

Anyone with experience with GnuPG or any OpenPGP platform could just sit down with Bitcoin and know what to do, and how to stay secure about it.

Again, no expert, but my understanding is it might be the case that some element of transaction history is also stored within wallet.dat. In my view, these should be separated. Something is causing me to feel that keys shouldn't mix with receipts, not because it's dangerous, but because there may be some negative impacts for proper key handling.

The current client is sort of analogous to a car where new keys for the ignition are being made inside the steering wheel as you drive, linked to the odometer. You have to be sure to take the whole steering wheel with you when you get out, or you might find yourself not just locked out of the car, but unable to ever start it again! Oh, so you have a key backup that unlocks the door? Great... But the ignition key was changed inside the wheel while you were driving. Shall I call a cab?

andrew.skretvedt

Posts

Merits