Quote from: gavinandresen on October 18, 2010, 02:17:51 AM

Backup every 30 sendtoaddress or generatenewaddress and you'll be fine-- you should always have at least 3 backup copies of all your keys.

You obviously understand that from the software perspective, the two approaches are different, right? Having a fixed trigger to backup is very easy and can be completely stateless, but backup every X whatevers means keeping a running count, harder to get redundant work with redundant data, etc.

Quote from: gavinandresen on October 18, 2010, 02:17:51 AM

If you're running a very busy service so backing up every 30 is too often, then run with -keypool=1000 and backup at least every 300 sends/generates.

I worry about bitcoin accumulating too many features and not doing any of them very well. I suppose it wouldn't hurt to add an option so it automatically creates timestamped wallet backups... but should it erase old backups? (if it doesn't, I KNOW people will forget to erase them and will be upset when their disk fills up with wallet backups and they're left to figure out how to clean up the resulting mess). Should it encrypt them? What should it do if an automatic time-stamped wallet backup fails? When encrypted wallets are implemented, what should happen to old backups if the wallet encryption key is changed?

That's why I like simple, the kiss approach, within limits. The perfect approach for me would be manual triggering of key pool refilling, because that way the backup agent makes sure that there are enough keys from the last backup and, failing that, generates a new (variable size based on the average needed in the past) batch. This is very simple on the bitcoind side and very powerful for me.

I just need a way to know if the addresses on the wallet are covered by the last backup, and if there are still leftover addresses in the wallet, without depending on running counts and persistent data not stored in bitcoin directly.