@@ -135,14 +135,61 @@ enum WalletFlags : uint64_t {
135
135
136
136
static constexpr uint64_t g_known_wallet_flags = WALLET_FLAG_DISABLE_PRIVATE_KEYS | WALLET_FLAG_BLANK_WALLET | WALLET_FLAG_KEY_ORIGIN_METADATA;
137
137
138
- /* * A key pool entry */
138
+ /* * A key from a CWallet's keypool
139
+ *
140
+ * The wallet holds one (for pre HD-split wallets) or several keypools. These
141
+ * are sets of keys that have not yet been used to provide addresses or receive
142
+ * change.
143
+ *
144
+ * The Bitcoin Core wallet was originally a collection of unrelated private
145
+ * keys with their associated addresses. If a non-HD wallet generated a
146
+ * key/address, gave that address out and then restored a backup from before
147
+ * that key's generation, then any funds sent to that address would be
148
+ * lost definitively.
149
+ *
150
+ * The keypool was implemented to avoid this scenario (commit: 10384941). The
151
+ * wallet would generate a set of keys (100 by default). When a new public key
152
+ * was required, either to give out as an address or to use in a change output,
153
+ * it would be drawn from the keypool. The keypool would then be topped up to
154
+ * maintain 100 keys. This ensured that as long as the wallet hadn't used more
155
+ * than 100 keys since the previous backup, all funds would be safe, since a
156
+ * restored wallet would be able to scan for all owned addresses.
157
+ *
158
+ * A keypool also allowed encrypted wallets to give out addresses without
159
+ * having to be decrypted to generate a new private key.
160
+ *
161
+ * With the introduction of HD wallets (commit: f1902510), the keypool
162
+ * essentially became an address look-ahead pool. Restoring old backups can no
163
+ * longer definitively lose funds as long as the addresses used were from the
164
+ * wallet's HD seed (since all private keys can be rederived from the seed).
165
+ * However, if many addresses were used since the backup, then the wallet may
166
+ * not know how far ahead in the HD chain to look for its addresses. The
167
+ * keypool is used to implement a 'gap limit'. The keypool maintains a set of
168
+ * keys (by default 1000) ahead of the last used key and scans for the
169
+ * addresses of those keys. This avoids the risk of not seeing transactions
170
+ * involving the wallet's addresses, or of re-using the same address.
171
+ *
172
+ * The HD-split wallet feature added a second keypool (commit: 02592f4c). There
173
+ * is an external keypool (for addresses to hand out) and an internal keypool
174
+ * (for change addresses).
175
+ *
176
+ * Keypool keys are stored in the wallet/keystore's keymap. The keypool data is
177
+ * stored as sets of indexes in the wallet (setInternalKeyPool,
178
+ * setExternalKeyPool and set_pre_split_keypool), and a map from the key to the
179
+ * index (m_pool_key_to_index). The CKeyPool object is used to
180
+ * serialize/deserialize the pool data to/from the database.
181
+ */
139
182
class CKeyPool
140
183
{
141
184
public:
185
+ // ! The time at which the key was generated. Set in AddKeypoolPubKeyWithDB
142
186
int64_t nTime;
187
+ // ! The public key
143
188
CPubKey vchPubKey;
144
- bool fInternal ; // for change outputs
145
- bool m_pre_split; // For keys generated before keypool split upgrade
189
+ // ! Whether this keypool entry is in the internal keypool (for change outputs)
190
+ bool fInternal ;
191
+ // ! Whether this key was generated for a keypool before the wallet was upgraded to HD-split
192
+ bool m_pre_split;
146
193
147
194
CKeyPool ();
148
195
CKeyPool (const CPubKey& vchPubKeyIn, bool internalIn);
0 commit comments