Quote from: joan on May 31, 2011, 06:28:51 PM

To sum it up:
- keypools = great. If I backup on day one, I have a hundred of addresses backed up.
- using a new address to send the spare change of a transaction = should be opt-in or disabl-able. Otherwise my backup dies at tx 101 without me noticing it.

Yeah, I love this and want to amplify the thought. Primary devs take note.

I understood roughly what the official client does with the wallet.dat when I began experimenting with it, but learning "specifically" what it does took concerted research effort trolling the forums on my part. It is not clearly written on the box, so to speak. So, because I'm curious, and I understand that I'm working with "experimental" software and need to be careful, I am aware of the need to have an ongoing backup strategy tailored to the needs of the wallet.dat and my spending habits when using the client.

Some of we tinkerers, e.g. myself, come from a background of experience using OpenPGP and X.509 to accomplish secure/authenticated communications. In this world, you, the user, have and must have total control of the creation and maintenance of your private key. Learning these systems taught me what I know so far about public-key crypto. I learned it would be a pain if you lost control over your personal private key and had to revoke it, then go out and accumulate signatures on a new key. Because of this we tend to attach ourselves mostly to just one key, and keep it carefully secure. It takes on a meaning then where it comes represent our official self digitally.

Coming into Bitcoin with that attitude is kinda dangerous without some more education. As it stands in the client currently, key management is automated and effectively comes with the label, "no user-serviceable parts inside."

Wallet.dat is a black-box to most of us. We can ask the client to generate new addresses (which causes new keypair generation within the wallet.dat), but this is all the control we have.

To avoid value destroying mistakes of the one this thread is all about, I think key management should be reconsidered. I'm going to vote for a more OpenPGP-style default design. This is essentially what you would start to get within wallet.dat if Joan's ideas (quoted above) were implemented as defaults.

I understand the benefits of using new keys as fluidly as they are in the client right now, it massively bolsters anonymity, a property I think valued highly at least by creator Satoshi and the development team working closely with him.

But bitcoin is starting to become viral, with n00bs arriving daily. User experience and easy access to education to help them bootstrap and go competently forward is going to become more important for the system's long-term health, when it expands beyond the tech-heads (yes, and cue the idea of most folk using an online wallet provider a-la Mybitcoin. Fair enough. Some will desire personal control, yet still with a safe and easy use experience. I don't think that's asking a lot.).

Perhaps I care less about the obfuscation of my transactions within the sea of the block-chain, and would rather everything come to/from a single key I make. I can still get more creative and make special-purpose keys to denote bitcoin received from different sources, or to obfuscate my transactions (as is the default now). The point it this aspect of the way bitcoin works should be controllable and transparent, and as easy PGP.

Finally...I'm beginning to come around to the notion that perhaps bitcoin will not become a major value store for day-to-day transacting, as we're often envisioning its future. But through developing systems like OpenTransactions, becomes the missing mechanism allowing more customary media of exchange to be tied together in a way that confers the benefits of bitcoin to the convenience and instantaneous-finality of more familiar forms of money.

For more on that, I highly recommend these mind-blowing shows:

http://agoristradio.com/?p=234
http://agoristradio.com/?p=246