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.

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.

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

32 bytes is the . 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

New Seed

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.

New Seed

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 :

New Seed

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 .

New Seed

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:

New Seed

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: 00 081549973bafbba825b31bcc402a3c4ed8e3185c2f3a31c75e55f423e9629aa3 # prepend 00 for private keys serialized: 0488ade4000000000000000000 1d7d2a4c940be028b945302ad79dd2ce2afe5ed55e1a2937a5af57f8401e73dd 00 081549973bafbba825b31bcc402a3c4ed8e3185c2f3a31c75e55f423e9629aa3

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

https://bitcointalk.org/index.php?topic=19137 (Gregory Maxwell)

https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki (Pieter Wuille)





https://iancoleman.io/bip39/ (An amazing web tool)

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 Determinstic Wallets)

https://eprint.iacr.org/2014/998.pdf (Interesting paper by Gus Gutoski and Douglas Stebila)