An HD (Hierarchical Deterministic) wallet is a type of cryptocurrency wallet that generates a hierarchical tree of public and private keys from a single master seed. This structure enables efficient management and organisation of multiple cryptographic keys.
The keys within an HD wallet are organised in a tree-like structure, where each “node” can generate child nodes. This allows for a well-organised hierarchy of keys, facilitating easy access and enhanced security.
Each node in the tree holds either an Extended Private Key (xPrivKey) or an Extended Public Key (xPubKey):
Extended Private Key (xPrivKey): Combines a normal crypto private key with a chain code. The private key is used for signing transactions, ensuring security and ownership of the assets. The chain code allows for the deterministic generation of child keys, expanding the tree structure without compromising security.
Extended Public Key (xPubKey): Contains a public key and a chain code. The public key is derived from the corresponding private key and is used to generate public addresses where funds can be received. Similar to the xPrivKey, the chain code in xPubKey enables the generation of child public keys, facilitating the creation of multiple receiving addresses for enhanced privacy.
The term “extended” indicates that these keys include both the standard cryptographic components (private or public keys) and a chain code, which is essential for generating further keys in the hierarchy. This dual function of the extended keys is fundamental to the operation of HD wallets, allowing for a scalable and secure management of a vast number of keys from a single master seed.
Master Extended Key
The Master Extended Key is the first extended key generated from the master seed and is the root key from which all other keys are derived.
Generating the Master Extended Key
The steps to generate a the Master Extended Key from the Master Seed is as follows:
1) Start with the Master Seed: The master seed is typically generated from a mnemonic phrase according to BIP39. This mnemonic, a series of easy-to-remember words, is converted into a seed through a hashing process.
2) HMAC-SHA512 Hashing: The master seed (from step 1) is passed through an HMAC-SHA512 hashing function. The HMAC-SHA512 requires two inputs: a key and a message. For generating the Master Extended Key, the master seed is the message, and the key is often a static value, such as the string “Bitcoin seed”.
3) Split the Hash Output: The output from 2 is a 512-bit (64-byte) hash. This hash is split into two equal halves:
- The first 256 bits (32 bytes) become the master private key.
- The second 256 bits (32 bytes) become the master chain code.
4) Forming the Master Extended Private Key: The master private key and the master chain code together form the Master Extended Key. This key is not just a simple private key but an extended key because it includes both a key component for signing transactions and a chain code for generating child keys.
The first 256 bits (32 bytes) become the master private key.
The second 256 bits (32 bytes) become the master chain code.
The Importance of Securing xPubs
A single public key is associated with a specific address, allowing anyone to send funds or view transactions for that address. This is a basic operation in cryptocurrency transactions.
The situation with Extended Public Keys (xPubs) is different. An xPub doesn’t grant access to funds, as transactions still require a private key. However, it does affect the privacy of a wallet. Knowing an xPub allows anyone to see all transactions and future addresses because it includes the chain code needed for generating those addresses.
Protecting an xPub is important but for different reasons than a private key. Since an xPub can’t be used to authorise transactions, the main concern is privacy rather than theft. Sharing an xPub should be done carefully, considering that it gives visibility into the wallet’s activity.
The level of security needed for an xPub is not as high as for a private key. It’s less about preventing unauthorised access and more about controlling who can see your transaction history. Nonetheless, being cautious with xPub sharing is a good practice to maintain financial privacy.
Hardened vs. Non-Hardened Keys:
When deriving a child key you have the option to generate that child key as either a hardened or non-hardened key with the choice between depending on your security needs and operational requirements.
Hardened Key Derivation
Hardened key derivation uses the parent’s extended private key including the private key and chain code to derive the new key.
The use of hardened derivation means that even if someone has the xPub, they cannot derive the addresses or public keys of the hardened children. This adds a layer of privacy and security, as it prevents external observers from mapping out the entire structure of a wallet from the xPub.
If you have an xPub and want to generate a specific address within a wallet, you can only do so for non-hardened child keys. To generate addresses or keys that are hardened, access to the corresponding extended private key (xPriv) is necessary.
Non-Hardened Key Derivation
Non-hardened key derivation uses the parent’s extended public key, which includes both the public key and chain code, along with a derivation index to generate child keys.
This method enables the derivation of non-hardened child public keys from the parent’s extended public key, allowing for the creation of public addresses without accessing the private keys.
This approach is chosen for its practicality in certain situations, such as when an application needs to automatically generate public keys for receiving funds.
It’s useful for servers or applications where private keys must remain secure and undisclosed, but public keys are needed for transactional purposes or watching transactions.
Deriving an xPub from an xPriv
Converting an extended private key (xPriv) into an extended public key (xPub) is a standard procedure within hierarchical deterministic (HD) wallets.
Here’s how it’s done:
1) Start with the xPriv: Your extended private key contains both a specific private key and a chain code.
2) Generate the Public Key: Utilise the private key component of your xPriv to calculate the corresponding public key. This step involves elliptic curve cryptography, where the private key is mathematically combined with the generator point defined by the cryptocurrency’s protocol, such as secp256k1 for Bitcoin.
3) Maintain the Chain Code: Pair the newly generated public key with the unchanged chain code from your xPriv. The chain code is crucial for the subsequent derivation of child keys and is carried over directly to the xPub.
4) Create the xPub: The xPub is formed by merging the fresh public key with the retained chain code. This extended public key can now be used to derive public addresses within the wallet’s structure, providing a secure way to receive funds and monitor transactions without exposing your private keys.
Deriving a Child Key
You can derive a child key from either an extended private key (xPriv) or an extended public key (xPub). While the derivation steps are quite similar, only an xPriv allows for the derivation of both non-hardened and hardened child keys. In contrast, an xPub supports the derivation of non-hardened child keys only.
to Derive a child key:
1) Start with xPriv or xPub:
- The xPriv contains a private key and a chain code.
- The xPub contains a public key and a chain code.
2) Choose Index:
- Select an index within the range of 0 to 0x7FFFFFFF.
- For a hardened key, add the value of 0x80000000 to the chosen index.
3) Prepare Data:
- Non-Hardened: Use the parent’s public key and index.
- Hardened: Use the parent’s private key (prepend with `*0x00*`) and index.
4) Hashing:
- Apply HMAC-SHA512 using the parent’s chain code as the key and the prepared data as the message.
5) Split the HMAC Output:
- Divide the 512-bit hash into two halves; the left half for the child key and the right half for the new chain code.
6) Derive the Child Key:
- For xPriv (Both Non-Hardened and Hardened): Add the left 256 bits of the HMAC output to the parent’s private key (modulo the prime order of the elliptic curve, typically denoted as `*n*` for secp256k1).
- Formula: Child Private Key = (Parent Private Key + Left Half of HMAC Output) mod `*n*`
- For xPub (Non-Hardened Only): Perform elliptic curve point addition using the parent’s public key and the point generated from the left 256 bits of the HMAC output.
- Formula: Child Public Key = Parent Public Key + (Left Half of HMAC Output * G), where `*G*` is the generator point of the elliptic curve.
7) Form the Child xPriv or xPub:
Child xPriv: Combine the derived child private key with the new chain code from step 5 to form the child xPriv.
Child xPub: Combine the derived child public key with the new chain code obtained from step 5. Include other relevant metadata such as version bytes, depth (incremented by one from the parent), and the index of this child key.
Derivation Path
A Derivation Path is a notation that specifies how to derive a series of child keys from the master seed in a hierarchical deterministic (HD) wallet. It outlines the sequence and hierarchy of key generation, allowing for a structured and organised way to access a wide array of keys within the wallet. The concept of a derivation path is fundamental to HD wallets, as defined by Bitcoin Improvement Proposals like BIP32, BIP44, BIP49, and BIP84, which standardise the structure of these paths for different purposes and cryptocurrency types.
Structure of a Derivation Path
A derivation path typically looks like this: `m/44’/0’/0’/0/0`
m: Represents the master seed.
44′: The purpose field, set by BIP44 to indicate a specific structure. The apostrophe indicates hardened derivation.
0′: The coin type field, indicating which cryptocurrency the key is for (e.g., 0′ for Bitcoin).
0′: The account field, allowing users to separate funds into sub-accounts within the wallet.
0: The change field, distinguishing between keys used for receiving payments (0) and change addresses (1) when spending from the wallet.
0: The address index, specifying the individual address within the account and change category.
Importance of Derivation Paths
Organisation: Derivation paths provide a systematic way to organise and manage the vast number of keys that can be generated within an HD wallet, making it easier to categorise and segregate funds for different purposes or accounts.
Interoperability: Standardised derivation paths (like those defined by BIP44 and its derivatives) ensure compatibility across different wallet software, allowing users to recover their wallet and access their funds using any compliant wallet application.
Security: By structuring the derivation path and using hardened derivation at certain levels (indicated by the apostrophe), users can protect higher-level keys from being compromised if a lower-level key is exposed.
Recovery: The entire wallet structure, including all accounts and addresses, can be regenerated from the master seed if the derivation path is known. This feature is crucial for wallet backup and recovery.
Human Readable Extended Key
The encoding of an extended key into a human readable form adheres to standards like BIP32 and its derivatives (BIP44, BIP49, BIP84, etc.), additional information beyond just the chain code and the private key is indeed required.
This information ensures that the extended key can be used correctly within the hierarchical deterministic (HD) wallet structure, facilitating key management, recovery, and interoperability across different wallet implementations.
The process adds layers of usability and security features, such as error detection capabilities and a compact representation that excludes confusing characters.
Base58Check Encoding
Base58Check is a modified version of the Base58 encoding algorithm, designed to produce alphanumeric characters that are easily distinguishable by humans. It excludes characters that might look similar, such as ‘0’ (zero), ‘O’ (uppercase ‘o’), ‘I’ (uppercase ‘i’), and ‘l’ (lowercase ‘L’), to reduce the risk of mistyping or misreading.
Components of an xPub/xPriv
An xPub or xPriv is composed of several pieces of information:
- Version bytes: Indicate whether the key is public or private and can also specify the network (mainnet or testnet). For example, Bitcoin’s mainnet xPubs usually start with ‘xpub’ and xPrivs with ‘xprv’.
- Depth byte: Represents the depth in the hierarchy of the key, with ‘0x00’ for master keys.
- Fingerprint of the parent’s key: A short identifier for the parent key.
- Child number: The index of the key if it is a child.
- Chain code: A 256-bit number used in child key derivation.
- The key itself: For xPubs, this is the ECDSA public key. For xPrivs, this is the private key data.
Encoding Process
- Concatenate Components: The version bytes, depth, parent fingerprint, child number, chain code, and key data are concatenated to form a single byte array.
- Checksum Generation: A double SHA-256 hash is performed on the byte array, and the first 4 bytes of this hash are used as a checksum.
- Append Checksum: The checksum is appended to the end of the byte array.
- Base58Check Encoding: The entire array, including the checksum, is then encoded using Base58Check, resulting in the final human-readable xPub or xPriv string.
Example
An xPriv might look something like this:
xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPcbCpJs42nJbH4RuzVSTPVpQtpL4RkhVHWVYY1EJj6oEwEMAGZ9j57iAGWPCvXSmAnd an xPub might look like this:
xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8These encoded strings provide a secure and error-resistant way to handle and share extended keys, crucial for managing hierarchical deterministic wallets.