Create -keypoolmin, and only top up keypool if size falls below that #294

Avoid creating a new key -every- time you use a reserve key. Instead, create them in bursts.

Currently, default is to generate 25 keys (filling keypool up to 100), if keypool size falls below 75.

Not sure if I agree with this. Im not sure if it is useful or not. After walletcrypter, creating new keys can be a bit slow (both created, and encrypted). This means generating 25 in direct succession and blocking until then can generate quite a lag. Walletcrypter will try to generate new addresses every chance it gets, as you have no idea when you will get the password again. Even if you ignore walletcrypter, Im not sure if it is a better idea to lock once per 25 uses or for 1/25th the time on each use.

If the feature is disliked, you can set keypoolmin==keypool.

But there is really no reason we need to top up the key pool every single time we remove one key, and that creates the disadvantage that you -must- backup your wallet every single time.

Normally, pools are depleted and replenished periodically; there does not seem to be a driving reason to constantly top up the keypool, one-at-a-time.

re 1. True... re 2: No, it is worse for backup, if you backup when you have 76 keys left you might lose coins sent to the 77th, whereas if you backup when you have 76 keys now...well you cant. re 3: True, and I think you are right here, however I'd like to see manual control of keypool topup (its in wallet crypter, but I might pull it into a separate commit if I get the chance). I would rather see the ability, though not required, to be able to top up the keypool and not slow down my transactions. I suppose that leads me to the answer to my original question, IMHO it is better to lag one transaction per 25, instead of 1/25th the amount per transaction.

The keypool always uses the oldest key first, on purpose. So your lose-coins scenario doesn't make sense. The keypool is by definition full of unused keys.

With pool low-water refill, old backups remain valid longer.

My point was that after your patch, if you backup when you have 76 keys left, and you use 77, you might lose coins on restore. However, if you backup when you have 77 keys left now...well you cant as the keypool will always have 100 new keys to use. Thus after your patch, by default, you only have some keypool between 75 and 100, not 100 as it used to be, potentially resulting in lost coins if you assume you can do 100 actions between backup, like you used to be able to do.

Absent tilting at windmills, the lone codger who does that can adjust -keypoolmin :)

Well maybe then keypoolmin should default to 100, and fill up to 125.

Thats what I was thinking. Im not sure what a "good" default keypool is. For a merchant, you would need some ridiculously huge amount for keypool to just last a day. For an end-user, 100 keys could very well last a month, maybe longer. Generating keys does take very little time and spend very little disk space.

Updated to 100/125 (and created named constants for those magic numbers)

I agree with Matt-- I don't see the need for this.

oh well :)