• Hash256
  • Hash160
  • Reverse Bytes
  • Hexadecimal
  • Satoshis
Youtube

HD Wallets

Using a single seed to generate a tree of keys.

BIP 32

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

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

But the best thing about these wallets is that you can generate new public keys without knowing the private keys for them.

Why use a HD wallet?

1. Single Backup

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

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

But 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.

For example, you could use different parts of the tree for 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 knowing the private keys.

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

This is useful for things like hardware wallets where you want to keep your private keys on a secure device, but also want the convenience of being able to generate new addresses on a different computer for receiving payments.

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

How do HD wallets work?

1. Seed

To start a HD wallet you need to generate 64 random bytes, which we will use as our seed.

seed: b1680c7a6ea6ed5ac9bf3bc3b43869a4c77098e60195bae51a94159333820e125c3409b8c8d74b4489f28ce71b06799b1126c1d9620767c2dadf642cf787cf36

Mnemonic Sentences To source a HD wallet we can use a more user-friendly mnemonic sentence instead of a raw hexadecimal seed.

For example, the seed above was created from the following mnemonic sentence:

mnemonic: glow laugh acquire menu anchor evil occur put hover renew calm purpose
See mnemonic seed for details.

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.

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.

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.

Extended Private Key

seed: b1680c7a6ea6ed5ac9bf3bc3b43869a4c77098e60195bae51a94159333820e125c3409b8c8d74b4489f28ce71b06799b1126c1d9620767c2dadf642cf787cf36

master extended private key:
  private key: 081549973bafbba825b31bcc402a3c4ed8e3185c2f3a31c75e55f423e9629aa3
  chain code:  1d7d2a4c940be028b945302ad79dd2ce2afe5ed55e1a2937a5af57f8401e73dd

Public Keys The private key embedded inside this extended key can be used to create a corresponding public key as normal:

  private key: 081549973bafbba825b31bcc402a3c4ed8e3185c2f3a31c75e55f423e9629aa3
  public key:  0343b337dec65a47b3362c9620a6e6ff39a1ddfa908abab1666c8a30a3f8a7cccc
But the actual master extended private key itself is just the private key and chain code.

3. Child Keys (Basic)

New child private keys are generated from an extended private key by putting its contents (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.

By changing the index you get a completely different result from the hash function.
seed: b1680c7a6ea6ed5ac9bf3bc3b43869a4c77098e60195bae51a94159333820e125c3409b8c8d74b4489f28ce71b06799b1126c1d9620767c2dadf642cf787cf36

master extended private key:
  private key: 081549973bafbba825b31bcc402a3c4ed8e3185c2f3a31c75e55f423e9629aa3
  chain code:  1d7d2a4c940be028b945302ad79dd2ce2afe5ed55e1a2937a5af57f8401e73dd

  child 0:
    private key: 0397654f8c58215da8575e495345912bd0d23545cf0017505ab6b6ae1a97eedb
    public key:  021fa96c781e4ba8a11eb6fb8a7bd3f996ad0d6461fb403b0f389605c6f35c2620

  child 1:
    private key: 38512d738064f282d7620205815fa1208258bf031dbf5b6e5887cc3dacf7ae1d
    public key:  03073e48507140bb0e57dd4008db386f554d13a8641f7e55426419af4ba71fa3eb

  child 2:
    private key: 590bfef4b951854f60e90eb24e7c690ac70165eb959b3296c3f51cb5a8a6401f
    public key:  021b323b81b998340368d8fe11496922295cbae6fcd4b8d495f2c4755cd2279d1d

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

An extended key can generate 2,147,483,648 of these children.

4. Child Keys (Advanced)

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?

Extended Public Key

Well first of all 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:

seed: b1680c7a6ea6ed5ac9bf3bc3b43869a4c77098e60195bae51a94159333820e125c3409b8c8d74b4489f28ce71b06799b1126c1d9620767c2dadf642cf787cf36

master extended private key:
  private key: 081549973bafbba825b31bcc402a3c4ed8e3185c2f3a31c75e55f423e9629aa3
  chain code:  1d7d2a4c940be028b945302ad79dd2ce2afe5ed55e1a2937a5af57f8401e73dd

master extended public key:
  public key: 0343b337dec65a47b3362c9620a6e6ff39a1ddfa908abab1666c8a30a3f8a7cccc
  chain code: 1d7d2a4c940be028b945302ad79dd2ce2afe5ed55e1a2937a5af57f8401e73dd

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.

seed: b1680c7a6ea6ed5ac9bf3bc3b43869a4c77098e60195bae51a94159333820e125c3409b8c8d74b4489f28ce71b06799b1126c1d9620767c2dadf642cf787cf36

master extended private key:
  private key: 081549973bafbba825b31bcc402a3c4ed8e3185c2f3a31c75e55f423e9629aa3
  public key:  0343b337dec65a47b3362c9620a6e6ff39a1ddfa908abab1666c8a30a3f8a7cccc
  chain code:  1d7d2a4c940be028b945302ad79dd2ce2afe5ed55e1a2937a5af57f8401e73dd

  child 0:
    private key: c41cd73a9df26db3bccfad12e9bbe66d4d619b6c9510f43a618fbef27fa78ce4
    public key:  03d7e13456af502d9767c9978aa18cb2dc8c8a7cda0751216b9f255c9da8e5e10f

  child 1:
    private key: b172c916ba6187a4ac728be3ab62451eb5a268340062ba4ff8d46e6575f95b73
    public key:  036937b07bb76d6631d2cdc462bd79f16fae8c3963a5a62b6547e6d1a439bef318

  child 2:
    private key: fc25db4963453fd715da88c98785c46be78c4d1c268fd183ababe04c5fb008a3
    public key:  039afb1feedd43508a5d9c000ab5a6268d374577d70f5fdd4be0823bfbd2d3a05c

Extended Public Key Children

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

master extended public key:
  public key: 0343b337dec65a47b3362c9620a6e6ff39a1ddfa908abab1666c8a30a3f8a7cccc
  chain code: 1d7d2a4c940be028b945302ad79dd2ce2afe5ed55e1a2937a5af57f8401e73dd

  child 0:
    public key: 03d7e13456af502d9767c9978aa18cb2dc8c8a7cda0751216b9f255c9da8e5e10f

  child 1:
    public key: 036937b07bb76d6631d2cdc462bd79f16fae8c3963a5a62b6547e6d1a439bef318

  child 2:
    public key: 039afb1feedd43508a5d9c000ab5a6268d374577d70f5fdd4be0823bfbd2d3a05c

And because the original private key and public keys have been adjusted by the same amount, the new child private keys and public keys correspond.

An extended key can generate 2,147,483,648 of these children.

Therefore an extended key can derive 4,294,967,296 children in total (2,147,483,648 advanced and 2,147,483,648 basic).

See extended keys for more details.

Why do we extend keys with a chain code?

By adding a chain code to a key, it 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 some additional secret data that protects the children of a key from being derived.

Remember: When we couple a normal key with an additional chain code, we refer to it as an “extended key”.

Are the keys in a HD wallet connected?

No, you wouldn’t know 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 in a specific manner, the actual public keys themselves do not share any resemblance to each other. It’s as though they were generated completely independently.

Are the keys in a HD wallets secure?

Yes, all of the private keys and public keys you get from a HD wallet are as secure as if you generated them in the traditional way.

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 see find the addresses in your wallet. They can’t steal anything because they cannot generate the private keys, but they can still see how much bitcoin you own.

But furthermore, leaking a master extended public key and any child private key allows someone to calculate the master extended private key. And if they can do that, they can generate all the private keys in the wallet:

So in short, try not to reveal your master extended public key. If you do, other people can find all the addresses in your wallet. But if you were to reveal a child private key as well, then that’s as bad as as revealing the master extended private key.

What does an extended key look like?

To make extended keys easier to pass around, we serialize them along with some additional data.

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

version:     0488ade4     # puts "xprv" or "xpub" at the start after encoding to base58
depth:       00           # how deep we are in the key tree
index:       00000000     # the index number
fingerprint: 00000000     # this is from the hash of the parent key
chain code:  1d7d2a4c940be028b945302ad79dd2ce2afe5ed55e1a2937a5af57f8401e73dd
key:         00081549973bafbba825b31bcc402a3c4ed8e3185c2f3a31c75e55f423e9629aa3 # prepend 00 for private keys

serialized: 0488ade40000000000000000001d7d2a4c940be028b945302ad79dd2ce2afe5ed55e1a2937a5af57f8401e73dd00081549973bafbba825b31bcc402a3c4ed8e3185c2f3a31c75e55f423e9629aa3

We can then make this more convenient by converting it to base58 (including a checksum):

xprv9s21ZrQH143K2MPKHPWh91wRxLKehoCNsRrwizj2xNaj9zD5SHMNiHJesDEYgJAavgNE1fDWLgYNneHeSA8oVeVXVYomhP1wxdzZtKsLJbc

This is now a more useful format for our extended key. It’s easier to share between computers and import in to wallets.

See extended key serialization for details.

Who came up with the idea for HD Wallets?

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 homomorphic derivation.

The FSF wanted to accept donations in Bitcoin and wanted to generate new addresses for each user, but didn’t want their private key on their webserver. – Gregory Maxwell

Armory was the first wallet to implement this homomorphic derivation, and also introduced the concept of using a chain code.

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.

HD wallets (BIP32) was based on Armory’s scheme, but with more flexibility (the hierarchical structure), and random-access in the index (Armory’s scheme required generating all N addresses before N to derivate address number n). – Pieter Wuille

What are some examples of HD wallets?

Most modern wallets (since 2013) are hierarchical deterministic. Here are some popular examples:

They each give you a seed when you create the wallet, which is then used to generate all the keys and addresses for it.

Derivation Paths The actual keys are then generated according to the following structure:

m/44'/0'/0'
m/49'/0'/0'
m/84'/0'/0'
See derivation paths for more details.

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 seed in the same way each time, and it’s hierarchical because you can organise 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.

If you’re interested in the details of HD wallets, here are some more technical explanations:

  • 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 organising keys.)

By Greg Walker,

Last Updated: 19 Apr 2020
  • 19 Apr 2020: added ajax-loading html and disabled ajax buttons when making ajax requests
  • 14 Apr 2020: added links
  • 14 Apr 2020: added wif converter tool
  • 13 Apr 2020: tooltip css class updates and /guide/address calculator from hash160
  • 11 Apr 2020: added links for Gregory Maxwell and Pieter Wuille
  • 08 Apr 2020: added private key generator tool
  • 08 Apr 2020: added history - gregory maxwell, pieter wuille
  • 07 Apr 2020: added link to slides by Gregory Maxwell on Deterministic Wallets
  • 07 Apr 2020: typo
  • 07 Apr 2020: added bip links below page title
  • 07 Apr 2020: renamed hierarchical-deterministic-wallets to hd-wallets
Back to Top

Hey there, it's Greg.

I'll let you know about cool website updates, or if something seriously interesting happens in bitcoin.


Don't worry, it doesn't happen very often.