Skip to content

Commit 37796b2

Browse files
committed
[docs] Add doxygen comment for CKeyPool
1 parent ef2d515 commit 37796b2

File tree

1 file changed

+50
-3
lines changed

1 file changed

+50
-3
lines changed

src/wallet/wallet.h

Lines changed: 50 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -135,14 +135,61 @@ enum WalletFlags : uint64_t {
135135

136136
static constexpr uint64_t g_known_wallet_flags = WALLET_FLAG_DISABLE_PRIVATE_KEYS | WALLET_FLAG_BLANK_WALLET | WALLET_FLAG_KEY_ORIGIN_METADATA;
137137

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+
*/
139182
class CKeyPool
140183
{
141184
public:
185+
//! The time at which the key was generated. Set in AddKeypoolPubKeyWithDB
142186
int64_t nTime;
187+
//! The public key
143188
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;
146193

147194
CKeyPool();
148195
CKeyPool(const CPubKey& vchPubKeyIn, bool internalIn);

0 commit comments

Comments
 (0)