HD Wallets | Hierarchical Deterministic Wallets (2024)

BIP 32: Hierarchical Deterministic Wallets

A hierarchical deterministic wallet (or "HD Wallet") is a wallet that generates all of its keys and addresses from a single source.

• Hierarchical – The keys and addresses can be organized in to a tree.
• Deterministic – The keys and addresses are always generated in the same way.

So basically, an HD Wallet allows you to generate billions of private keys using a single seed. So as long as you remember the seed, you'll always be able to recover the same keys and addresses.

This makes them much more user-friendly than early bitcoin wallets that generated and stored private keys individually.

The most interesting feature of HD wallets is that you can generate new public keys without having to generate the private keys for them at the same time.

Examples

Here are some examples of popular HD wallets that I like:

• Electrum (Desktop)
• Sparrow Wallet (Desktop)
• Trezor (Hardware Wallet)
• Coldcard (Hardware Wallet)

Almost all modern wallets (since 2013) are hierarchical deterministic.

m/44'/0'/0' <- 1addresses (P2PKH)m/49'/0'/0' <- 3addresses (Nested-P2WPKH)m/84'/0'/0' <- bc1addresses (P2WPKH)

Benefits

What are the benefits of a HD wallet?

1. Single backup

In a basic wallet, you would generate pairs of private keys and public keys independently each time you want to receive bitcoins.

This works perfectly fine, but it means that you would need to back up your wallet every time you receive a new payment.

However, with a hierarchical deterministic wallet, you can use a single seed to create a master private key, and you can use this to generate billions of "child" private keys and public keys.

So now all you need to back up is the seed, as the master private key you create from it will always generate the keys for your wallet in the same way (deterministically).

2. Organization

Another cool thing about hierarchical deterministic wallets is the hierarchical part.

Each child key in the wallet can also generate its own keys, which means you can create a tree structure (or hierarchy) to organize the keys in your wallet.

You then use different parts of the tree for separating the keys in to different "accounts".

3. Generating public keys independently

But the really cool thing about a master private key is that it has a corresponding master public key, and this can generate the same child public keys without the private keys.

So you could send the master public key to a different computer (e.g. a webshop server) to generate new receiving addresses, without worrying that the private keys will get stolen if the server gets hacked.

This may seem like magic, but it's all just mathematics.

This is also useful for things like hardware wallets – you can keep your private keys on a secure device, and generate new addresses on a different computer for receiving payments.

How do HD wallets work?

The following is a visual overview of how HD wallets work.

For technical details, see extended keys.

1. Seed

To create an HD wallet, you start by generating 64 random bytes. This is our seed.

2. Master Private Key

The "master key" is created by putting the seed through a hash function (called a HMAC) to generate another set of 64 bytes.

HMAC-SHA512

We use these 64 bytes to create our master extended private key.

• The first 32 bytes is the private key.
• The last 32 bytes is the chain code.

The chain code is just an extra 32 bytes that we couple with the private key to create what we call an extended key.

An "extended key" is just a normal key coupled with a chain code.

Why do we hash the seed? We could directly use the 64 byte seed to create the master extended private key. However, future child extended keys are created using the HMAC, so it's good to be consistent with how we create both.

3. Child Keys (Basic)

Deriving private keys and public keys

New child private keys are generated from an extended private key by putting it (the private key and chain code) through the HMAC function.

We also include an index number each time, which allows us to create multiple child keys from a single master key.

So essentially, new private keys are generated by hashing the master extended private key with an index number.

There is an extra mathematical step when calculating the child private key after hashing the parent extended private key. So that's why you won't get the correct results by simply putting the (32-byte private key | 4-byte index) and (32-byte chain code) through the HMAC. See extended keys for details.

An extended key can generate 2,147,483,648 of these "basic" (hardened) child keys.

4. Child Keys (Advanced)

Deriving private keys and public keys, and also public keys independently

Now this is the fun part.

What if we want an extended private key to create child private keys and public keys, but also want a corresponding extended public key for it that can generate the same child public keys?

In other words, how can we generate public keys away from the private keys?

1. Extended Public Key

First, we need to construct the extended public key.

This is just the public key from the extended private key, coupled with the same chain code:

Public Key

2. Extended Private Key Children

The master extended private key creates child private keys by putting the contents of its corresponding extended public key through the HMAC function, and adding the result to the original private key.

3. Extended Public Key Children

The master extended public key creates child public keys by putting its contents through the HMAC function, and adding the result to the original public key.

Now, because this time the child keys have been adjusted based on the parent private key and public key, the magic of elliptic curve mathematics means that the child private keys and public keys will correspond.

It seems like magic, I know, but it's just mathematics.

FAQ

Why do we use a chain code?

Adding a chain code means that child keys are not derived solely from the key.

For example, we may use one of the public keys in the tree to receive a payment, which would make it visible on the blockchain. If we didn't use chain codes, anyone could take this public key and derive all the children for it:

But by using chain codes (which do not hit the blockchain), other people are unable to derive the children from the public key:

So in other words, the chain code is additional secret data that prevents other people from deriving the children of a key.

Are the keys in an HD wallet connected?

No.

You cannot tell that any two public keys (or addresses) in the tree are part of the same wallet (i.e. derived from the same master extended key).

Even though child keys are derived from the master extended key deterministically, the actual private keys and public keys themselves do not share any resemblance to each other.

So to the outside world it's as though all the private keys and public keys were generated completely independently.

Are the keys in an HD wallet secure?

Yes, all of the private keys and public keys you get from an HD wallet are as secure as if you generated them independently using a random number generator.

However, extended keys used should be kept extra safe, as anyone who has access to them can derive all their children.

For example, if you revealed your master extended public key, other people would be able to find all the addresses in your wallet. They can't steal anything because they cannot generate the private keys for them, but they can still see how much bitcoin you own.

Address

The extended private keys and extended public keys in an HD wallet have their own address format.

Address (Extended Key)

For example, this is what our master extended private key looks like when serialized:

We can then make this in to an address by base58check encoding it:

This is now a more useful format for our extended private key, as it's easier to share between computers and import in to wallets.

See extended key address for details.

History

Who invented HD wallets?

1. Gregory Maxwell came up with the initial idea that you can tweak public keys to get new public keys without knowing the private keys for them, otherwise known as hom*omorphic derivation.
2. Armory was the first wallet to implement this hom*omorphic derivation, and also introduced the concept of using a chain code.
3. Pieter Wuille came up with the idea to use a hierarchical structure, and built upon the scheme used by Armory to create the BIP 32 specification.

Summary

A hierarchical deterministic wallet provides a useful method for generating new private keys and public keys.

It's deterministic because all of the child keys are generated from a single seed in the same way each time, and it's hierarchical because you can organize the keys in to a tree structure (or hierarchy). The additional benefit is that its possible to derive the public keys in the wallet without having any knowledge of the private keys, which is pretty amazing.

Here are some more technical explanations if you're interested in the details of HD wallets:

• Mnemonic Seed – Generating a user-friendly seed for your HD wallet.
• Extended Keys –Creating a master extended key, and deriving children from it.
• Derivation Paths – Common hierarchies used by wallets for organizing keys.

Resources

• https://bitcointalk.org/index.php?topic=19137 – Discussion about deterministic wallets by Gregory Maxwell
• https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki – BIP by Pieter Wuille
• https://iancoleman.io/bip39/ – An amazing web tool for generating HD wallets
• https://github.com/lian/bitcoin-ruby/blob/master/lib/bitcoin/ext_key.rb – A clean implementation in Ruby
• https://www.youtube.com/watch?v=OVvue2dXkJo – Talk by James Chiang
• https://www.cs.cornell.edu/~iddo/detwal.pdf – Gregory Maxwell slides on Deterministic Wallets
• https://eprint.iacr.org/2014/998.pdf –Interesting paper by Gus Gutoski and Douglas Stebila