That is correct. And the backed up 'vault' idea is also correct. But we are not all hoarding money. I assume you have a bank account right? You deposit money and you EXTRACT money to pay bills. When you die, the account can be liquidated.

Most people are not so fortunate that they can dump money in one direction entirely (never dipping into those funds ever again) for the benefit of their estate. At some point, most people will need to use the money (that is not STORED, but) BACKED UP on the bottom of the ocean.

BitCoin presents no good analogy to the current system. I can backup money (vault) while still having access to money (copy). I am only advocating that a backup actually be a reliable backup. Anonymity through obfuscation is not the only use case. Control is another.

"If transactions coming in are to the same address, then you don't have to worry, because it will only create one new address."

i don't understand this statement.  with an incoming receive tx, where is the new address created other than the one you've given to the sender?

For clarity, at least when in dumbed-down mode, it should maybe not take dumbed-down to mean hide all the details like a knowledgeable user might prefer due to knowing all the details very clearly but rather, to be dumbed down like a "wizard" or even a "guru" routine.

That is, walk you through it step by step asking for confirmation of each step ("wizard") and possibly even (a la "guru") actually attempting to explain what it is all really about despite those who prefer the "wizard" approach wanting very very much not to ever ever have to understand anything about anything and most certainly not anything even remotely related to computers or computing.

So maybe something like:

You have asked to pay #.## bitcoins to [alias or address of intended recipient].

Due to the precise denominations of the coins currently in your wallet, this
will be done by sending them # coins, and in addition will require "breaking" #
coins to attain the precise amount to send, resulting in #.## change which
can be sent to any of the following addresses:

[ ] A new never before used one of your own that you have not yet backed up due to it has not been invented yet.

[ ] An old never before used one of your own created on ##/##/####, which might exist in a backup if you made a backup since then.

[ ] A (or the) default change-address you configured for this wallet in the wallet configuration section (see help etc etc)

[ ] The default charity you have configured for this wallet in the wallet configuration section (see help etc)

[ ] Some other address, in which case please input said address now: _________________________________________

-MarkM-

(I left out [ ] Send the change to the same address the payment is being sent from, because it seems unclear why, or even whether, it is apparently necessary at least in some circumstances to send it elsewhere. Does the protocol prohibit the sending address(es) appearing in the list of recipient addresses maybe for example or what?)

I endorse this idea.

Add to the client an automated backup system.  You click a button to back up, it encrypts your wallet file with the password of your choice and uses a file system browser to ask you where you want to store it.  You select your thumbdrive, have a nice day.  It warns you to back up again when you are down to 25 and 10 and 0 remaining keys.

Also add a restore button that allows a person to easily and quickly import a wallet file provided they know the password.

That isn't what happened to him at all. I question your copy/paste ability based on reading comprehension.

I would like to second Charles P. Bianchi suggestion.

By default the change generated from an outgoing transaction should just back loop to the emitting address.
This is the most simple behavior and avoid surprises.

I would argue this is actually what new users (like me) wrongly assume to happen if they don't pay too much attention to the address number.
Would allow to backup my wallet right after installation and forget about it.

If my day-to-day client always use the same address, I can restore anytime from the initial backup. The only thing really valuable should be the private key. The rest is stored on the network.
Otherwise even the most contrieved scheme of splitting and backing up wallet files into physical drives inside hidden buckets as I read in another thread would only work reliably up to 100 outgoing tx.

Then there should be a more powerful mode where you can opt-in to have the change sent back to a newly generated address each time.

Greater control over your addresses list would be desirable if they are more persistent. A nice thing might be the possibility to create aliases locally. Since each address is like a little account, it would ease management.

Surely at some point I will need to transfer coins from my savings to the spending address ? I will have to count how many times I'm doing it to check if I need to do a new backup. With persisting address, I need backup only once.

Anyway the remark was more about foolproofing the default behavior of the client, lower the surprise effect and improve data loss prevention.

I understand there is a tradeoff between built-in untraceability and having persisting addresses for the sake of simplicity and managing one's accounts.
Right now I don't care too much about traceability of my transactions, since it is still hard to match an address with a physical person. I know others will care and will use a different address for each tx. Should it be on them to opt-in ? Could I at least opt-out ?

With the keypool of 100 addresses created at initialization, I will have plenty of room to segment my wallet for different usages. I could have a spending address dedicated to food, another for books, etc. all within the same wallet.

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