Need a post writing up some things users should know

I’m not sure what to call it, but we could use a post that lists these things users should know.  If someone has time to write it, here’s the list:

• Make sure your clock is set correctly.

• Microsoft Security Essentials.  This never got written up proper.

• Warning not to mess around with your wallet.dat file.  It’s a database file, it’s not as simple as you think.  In this Beta version, we haven’t had time to try and tinker-proof it yet.  It may not work as expected if you start swapping it around.

mizeryderia, you just copied and pasted satoshis post without adding any value.

You could have tried to address the points he raised, or at least put up a note explaining why this page was on the wiki and what you wanted people to do with it.

The clock part will be covered in the next release (0.3.11 or higher).  SVN rev 141 pops up a message box if your clock is too far off.

Quote from: satoshi on August 19, 2010, 08:14:01 PM

• Warning not to mess around with your wallet.dat file. It’s a database file, it’s not as simple as you think. In this Beta version, we haven’t had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.

So how simple is it? I’m just now thinking about foolproof backups on the lottery site I posted about yesterday, and I’m struggling to find information on this. Can bitcoind dump it in a safe state, or at least flush it on request? If I backup the file mid transaction, do I loose the whole thing or just the update in progress? When do I need to backup? Every outgoing transfer is obvious, there are key pairs created automagically, but what about transfers received? the key pair we already had, no new address needed to be created afaict. Or does bitcoin do the same change dance on the receive side too?

This part is, I believe, the most critical of them all. While MSE and clock skews may prevent normal program usage, the wallet backup issues have made people loose a bunch of coins which, obviously, sucks and doesn’t do much on supporting continued usage.

Any backup process/procedure would just be a stopgap until there’s time to properly work on coding solutions in software.  We can try to use words to help the situation until code gets there.

The main backup improvement will be pre-made pool of keys, and a rescan at load to scrape missed transactions from the block history.  Then a backup will last forward for a long time.