BIP32 Key Derivation Scheme
Abstract
This technical standard describes a method for hierarchical key derivation called BIP32. Hierarchical key derivation enables the generation of a large number of public-private key pairs from a single master seed, and the ability to derive child keys from parent keys in a deterministic manner. BIP32 is a widely used standard in various fields such as wallets, but has various limitations and drawbacks that should be considered carefully before further adoption.
Motivation
In many applications, it is necessary to generate a large number of public-private key pairs. However, generating and securely storing many keys can be challenging. Hierarchical key derivation solves this problem by generating an unlimited number of keys from a single master seed. This reduces the complexity of managing multiple keys and enhances security. BIP32 provides a standard for implementing hierarchical key derivation, ensuring interoperability between different systems.
Overview
BIP32 is a method for hierarchical key derivation that enables the generation of a virtually unlimited number of public-private key pairs from a single master seed. The master seed is used to generate the master private key, which is used to derive child keys. Child keys can in turn be used to derive grandchildren keys, great-grandchildren keys, and so on, forming a hierarchical tree-like structure.
Each key in the hierarchy is determined using a combination of its parent key and an index value. The index value determines the position of the key in the hierarchy, and the parent key serves as a starting point for deriving the child key. The combination of the parent key and the index value is used to generate a new private key, which can then be used to derive a new public key.
BIP32 specifies the use of a deterministic algorithm for deriving keys. This means that given the same master seed and index value, the same key will be generated every time. This is important for ensuring that different systems can generate the same keys, and for enabling secure backup and recovery of keys.
BIP32 also provides a standard for deriving hardened keys, which are child keys that cannot be derived from their parent public key alone. Hardened keys provide an additional layer of security, as they can only be derived using the parent private key.
BIP32 is a widely used standard for implementing hierarchical key derivation. It enables the generation of a large number of public-private key pairs from a single master seed, and ensures interoperability between different systems.
BIP32 Derivation Paths
BIP32 defines a hierarchical tree-like structure for generating an unlimited number of public-private key pairs from a single master seed. This structure is organized using a derivation path, which is a sequence of index numbers and hardened/not-hardened markers that uniquely identify a particular key in the hierarchy.
A derivation path always starts with the letter "m", which stands for "master", followed by a forward slash ("/") and then a series of numbers and markers that specify the child keys to be derived. For example, the path "m/0/1/2" indicates that the third child private key should be derived from the second child private key of the first child private key of the master key.
In addition to simple index numbers, BIP32 allows for "hardened" derivation, which means that the derived key can only be generated using the parent's private key. Hardened keys are denoted with an apostrophe (') after the index number. For example, the path "m/44'/0'/0'/0/0" is commonly used for generating the first receiving address of a Bitcoin wallet using BIP44 standard (discussed below).
BIP44 Wallet Addressing
BIP44 is a widely used standard for generating hierarchical deterministic wallets with a specific structure for addressing different cryptocurrencies. This standard provides a consistent method for generating and organizing addresses across different wallets and platforms.
The BIP44 structure uses a derivation path that starts with "m/44'/<coin_type>'/", where <coin_type> is a numeric identifier for the cryptocurrency being used. For example, "m/44'/0'/" is the path for generating Bitcoin keys, and "m/44'/60'/" is the path for generating Ethereum keys.
Following the coin_type index, BIP44 specifies several other indices to organize keys, including account, change, and address indices. Account indices are used to manage multiple accounts within a single wallet, change indices are used to differentiate between incoming and outgoing transactions, and address indices are used to generate unique receiving addresses.
For example, the path "m/44'/0'/0'/0/0" generates the first receiving address for the first account of a Bitcoin wallet. The "0'" after the coin_type index indicates a hardened key, ensuring that the derived key can only be generated using the parent's private key. The "0" after the hardened index specifies the first account, and the "0" after that specifies the first address in the account.
Drawbacks and Alternatives
While BIP32 is a widely used standard for hierarchical key derivation, there are several potential drawbacks that should be considered before further adoption.
One major limitation is that BIP32 lacks privacy guarantees. Since it is common for all child keys in a wallet to be derived from a single node, any knowledge of the root public key could compromise the privacy of the entire key hierarchy for the wallet — since public keys can be derived from parent public keys, there is a risk of linkability between addresses that use the same parent key.
Additionally, BIP32 is limited to a maximum of 2^31 possible child keys per parent, which may not be sufficient for applications that require a very large number of keys.
To address these limitations, other key derivation schemes adopt various alternative approaches. By incorporating a shared secret between the sender and the recipient into the key derivation process, we can protect privacy even when the root public key becomes known. BRC-421 enables this functionality, and allows an unlimited number of child keys to be derived.
References
Last updated