Static keypool (key cycling, dated files, isolated from config) #286

Summary: Static keypool (keypool cycling, new keys in new dated files, isolate keys from config)

Use cases: (1) Backup once (trust fund for next of kin) (2) Iterative backup (fullest anonymity, expanding wallet).

I propose: (1) An optional flag: -keycycle=true|false (2) A wallet directory with dated keypools

• (1) suppose we want to hold the entire fortune of an estate in a wallet. While alive, we may need to (infrequently) use this wallet (send/receive transactions) but hope to pass the wallet on to next of kin when we die. We should be able to leave a single static copy of the wallet to our estate (password in escrow). Anonymity may be less important than a guarantee that the wallet does not change over several years, regardless of the number of transactions.

We either create a wallet with an impossibly large keypool, or simply cycle through keys, or both. Once created, the keys in this wallet should never change.

• (2) On the other hand, we may have the highest anonymity/laundry requirements. We may be making an enormous number of transactions to unique addresses. We may be a merchant using unique keys for each customer/vendor/transaction. We need our wallet to expand. We need to be able to backup our wallet in predictable iterations.

For those who prefer the risk of loosing keys over the risks associated with reusing keys, we can pre-generate a keypool inside a wallet. The keys in previously generated keypools never change and thus need not be backed up again.

Suggested implementation:

• A wallet is a directory
• Keypools are dated
• Keys are separated from related transaction and configuration data
• Key files are write-once-never-change
• Addresses can be optionally recycled
• Wallet can be optional fixed sized (required recycling)
• Subsequent keypools should be (geo/exp) larger than previous keypool

Example wallet directory:

/wallet /keypool.20110101120000 size: 10K /keydata.20110101120000 /keypool.20110201123451 size: 33K /keydata.20110201123451 /keypool.20110302345678 size: 100K /keydata.20110302345678

I'm going to close this-- the current thinking is to implement "deterministic wallets," because they're much easier to backup and are much more flexible (e.g. you can give one public key to somebody and they can generate a series of public keys that they can use to pay you without ever knowing any of the private keys).