- Sep 19, 2014
This displays the idea that a static number of keys is too clumsy for the task at hand.Well, probably... My main concern about 10000 keys is that it gives kind of false feeling of safety imo. If file gets corrupted in a bad and unpredictable way due to some combination of disk and power failure then much more funds could be potentially lost there without a proper backup. I would prefer to have 1000 keys (which is already 10 times more than Bitcoin Core wallet has by default btw) and to actually force general user to backup more often. At least by restarting his wallet time to time (I would avoid messing up with wallet.dat file while wallet is running for now). Power user can refill keypool with whatever amount of keys he wants via keypoolrefill but he would need to explicitly do this via RPC so at least we can assume that he is more or less aware of such action consequences.
It makes more sense to set a rate of backup frequency based on key use. A scan of keys used compared to unused already occurs... Hell, it's a primary function of being able to tell the balance...
Most of what you need is already there. The option to use a password or GPG key could be added on.True! I completely missed that point, will have a look
Since mixing is unpredictable and continuous, it's only user-definable settings should be where to put the backup (default to the folder/directory already being used), and key frequency.
It already makes backups at initialization. Just change that to the user-definable stats, add password/gpg passthrough, all done. Wouldn't want it to hit a cloud drive unencrypted... Wallet password and backup password/gpg should not be shared... I prefer to run my wallet unencrypted for recovery reasons. But I'd like my cloud backups to be crazy encrypted. Because duh.
You might want something in the first use popup to talk about setting your backup frequency and location... Not merely disclaimer, but "do this or don't blame us."