Community Blog How Ethereum BIP-32 Hardware Digital Wallet Works

How Ethereum BIP-32 Hardware Digital Wallet Works

What is a digital wallet? In this blog, we'll discuss in depth on Ethereum HD Wallets (BIP-32), focusing on its structure and how a tree of keypairs is derived.

By Matt Zand and Brian Wu

Due to the popularity of blockchain and decentralized finance, many applications that offer digital currencies like Bitcoin or Cryptocurrencies come with a feature called digital wallet. A wallet allows users to store and manage their private keys. A wallet is also used for key generation. Depending on the platform in which a user can access and manage their wallet, there are 4 types of wallets: web, desktop, mobile, and Hardware.

Another way to categorize wallets is based on the way in which keys are generated which includes deterministic and nondeterministic wallets. A non-deterministic wallet is considered a rather old style compared to a deterministic wallet. Modern deterministic wallets have advantages over non-deterministic wallets in many aspects, such as backups, security, data storage, accounting, auditing, and access controls.

The Hardware or HD wallet is the most well-known kind of deterministic wallet. It's also a preferred option among the deterministic wallets if you want to create one since it is well developed. When it comes to the following cases, the HD wallet shows more advantages than other types of deterministic wallets like web and mobile applications.

Normally, a deterministic wallet holds a single chain of keypairs, which doesn't support selective keypair sharing, while the HD wallet allows such selective sharing on multiple keypair chains that are generated from a single root. In some cases, being able to create public keys without exposing private keys makes the HD wallet available in environments that would normally be a higher security risk. With respect to security, the private key management does not only refer to key generation offline (away from the network, such as cold storage). Key sharding and splitting or division of signatures are other alternatives. Key sharding, also known as Shamir's secret sharing, is basically splitting a key into several pieces, or shards. This makes each shard useless, and the original key would be reconstructed unless enough pieces are assembled to reconstruct. A similar but very different concept to this is multi-signature wallet.

With cryptocurrency wallets becoming more and more developed, the protocols and standards need to be shared across the industry. The Ethereum community has been establishing standards over the years. Some of them are known as Ethereum Improvement Proposals (EIPs). Some are on application-level standards, for example, the standard format for smart contracts, known as Ethereum Requests for Comment (ERC). Standards are also followed for wallet creation. There are a few standards that are widely adopted, as follows:

  • HD wallets (BIP-32)
  • Multipurpose HD wallets (BIP-43)
  • Multi-currency and multi-account wallets (BIP-44)
  • Mnemonic code words (BIP-39)

BIP stands for Bitcoin Improvement Proposal. Although there are so many differences between Bitcoin and Ethereum networks today, they still have a lot in common and share standards and protocols.

The mnemonic code words is 128-bit to 256-bit entropy. This entropy will be plugged into a Password-Based Key Derivation Function 2 (PBKDF2) function and stretched to a 512-bit seed. The seed will be used in building a deterministic wallet.

In this article, we will review HD wallet or BIP- standard.

HD Wallets (BIP-32)

HD wallets follow the BIP-32 standard, which was created on February 11, 2012. The standard was set for mainly two aspects:

  • How to use a single seed to derive the tree of keypairs
  • How to derive wallet structure from the tree of keypairs

Deriving a Tree of Keypairs

Before going into any details regarding key derivation, we need to understand the concept of extended keys properly. The concept of extended keys came into the picture to prevent the derived child keys from entirely depending on the parent key itself. The process for deriving the child keys is as follows:

1.  Take the private and public parent key.

2.  Extend the key with an extra 256-bit entropy, called chain code:

  • If the parent key is a private key, the extended private key will have the prefix xprv.
  • If the parent key is a public key, the extended public key will have the prefix xpub.

3.  The extended keys will be used to produce the child key instead of the original private and public parent keys.

For key derivation, Child Key Derivation (CDK) functions are defined. They are functions that are used to derive child keys from a parent key. There will be a different CDK for each computation of the following:

  • Compute the private child key from the private parent key.
  • Compute the public child key from the public parent key.
  • Compute the public child key from the private parent key.

The parent key doesn't need to be the root of the tree, and it can be any node on the tree. To summarize, there are two ways to generate a child public key:

  • Directly from the parent public key
  • From the child private key

Notice it won't be possible to compute a private child key from a public parent key.

However, the feature of generating child public keys from parent public keys only is a key feature of the HD wallet. This brought us back to the second point of advantage deterministic wallets have over non-deterministic ones. With an extended public key on a web server, we can generate as many public keys and addresses as we need. If it wasn't an HD wallet, we would have to store all those pubic keys and addresses on a server, which is more work for maintenance and security. On the other hand, extended private keys can be secured on a separate server or offline cold wallet. Even if the server holding the pubic keys is compromised, the private keys won't be impacted.

Like a coin with two faces, the convenience of generating all the public child keys from the extended public key also comes with risks. Recall the process of generating extended keys. In the second step, we extend the public key with a chain code. If the attacker gets the chain code from the extended public key, it will compromise the non-hardened child key. With the child private key plus the chain code, the attacker will be able to derive the parent private key. Other than extended keys, we will introduce another concept, that is, hardened and normal (unhardened or non-hardened) keys. Here, we simplify the computation of those keys as follows:

  • Hardened child key: Hash (parent private key + index)
  • Normal child key: Hash (parent public key + index)

For the hardened child key, the linkage between the parent pubic key and private child key is broken. Therefore, the risk of exposing the child and parent private keys is countered.

In the formula for hardened and normal child keys, we are using an index. To generate more than one child key from a certain parent key, an index is very useful to keep things in order. The index is defined as a 32-bit integer. Just like how we distinguish private and public extended keys using prefixes xprv and xpub, we use different ranges of indexes for hardened and normal child keys:

  • Index of hardened child key is in the range [0, 231 ) or [0, 231 - 1]
  • Index of normal child key is bigger than 231 - 1

With all the concepts of keys in mind, let's move on to the key derivation process. Instead of solely using one key, both private and public keys are used in extension with an extra 256 bits of entropy. With all CDKs in place, the key tree can be built. Building the key tree takes on the following process:

  1. First, we start with one master extended key.
  2. Then, we use the child key derivation function to get level-one derived nodes.
  3. Next, we apply child key derivation functions to each of these level-one nodes to derive next-level nodes.
  4. Finally, we repeat the same process to build the entire tree.

The keys are in the format of 256 bits, while there are 2 possible extended keypairs in total. Because of security considerations, master keys won't be generated, but are generated from seed values instead.

Deriving Wallet Structure

Having a tree of key pairs, the structure of a wallet can be imposed on the tree. The default wallet layout is defined like so:

  • Each account contains one external and one internal keypair chain.
  • Derive public addresses from external keychain.
  • The internal keychain is responsible for all the activities that won't be shared with the outside environment.

HD wallets support a lot of use cases, for example:

  • Full wallet sharing
  • Support for auditing
  • Central control from headquarter to branches
  • Recurrent transactions among businesses
  • Separating incoming and outgoing transactions to prevent fraud

When it's for accounting and auditing purposes, accountants or auditors need to read the history of transactions. For accessing the transactions, wallet owners can generate the public keys at the hierarchical level needed. In terms of access control, the owner of the HD wallet will have the flexibility to determine how much ether others can spend by designing the hierarchy of the wallet.

For implementations, there are quite a few packages in different languages. We are only listing a few here for reference:

Language Library Name
C ++ mSIGNA: https://github.com/ciphrex/mSIGNA
Go btcutil: https://github.com/btcsuite/btcutil
go-hdwallet: https://github.com/wemeetagain/go-hdwallet
Java supernode: https://github.com/bitsofproof/supernode
bushido-java-core: https://github.com/bushidowallet/bushido-java-core
Python pycoin: https://github.com/richardkiss/pycoin
bip32utils 0.3.post4: https://pypi.org/project/bip32utils/
Ruby money-tree: https://github.com/GemHQ/money-tree

You can extend your reading to the wiki page of this standard: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

HD wallet path

If you have been doing extra reading upon BIP 32, you will have noticed a picture of key derivation, which can be found here. In this picture, the master node at depth 0 has a notation of m. At depth 1, wallets have notations such as m/0, m/1, and so on. And for depth 2, wallets have notations such as m/0/0, m/0/1, ..., m/i/0, and m/i/1.

This is another convention for keys in HD wallets. All keys are formatted like a path. It's defined as follows:

  1. The master private key is m.
  2. The first normal child of the master private key is m/0.
  3. The first hardened child of the master private key is m/0'.
  4. The first normal child of m/0' is m/0'/0 and so on.

The last digit of the path describes which one is the child of the parent, and the rest of path is the parent. You may also see keys such as M/1/0, this means it's a public key. Public keys starts with an uppercase M while private keys start with a lowercase m.

We know one parent extended key can have more than one child key and that the upper limit of numbers of child keys is about 4 billion—2 billion of each hardened and normal child keys. Therefore, the entire tree of HD wallets that are described in BIP-32 can end up being very deep and wide. To reduce the degrees of freedom that BIP-32 offers, BIP-43 and BIP-44 were introduced to further standardize the structure of the tree of HD wallets.


In this article, we learn about Ethereum digital wallet. We started off by explaining the role of a digital wallet in a DeFi application as well as differences between deterministic and non-deterministic methods for key generation. Then, we moved on by reviewing Ethereum standards for digital wallet creation and management. For the remainder of this article, we focused on HD wallet or standard BIP-32 by explaining how to derive a tree of keypairs and wallet structure for Ethereum HD wallets.


Here is a list of resources for learning more about blockchain development with Ethereum:

You can also learn more about Alibaba Cloud's Blockchain as a Service offering at https://www.alibabacloud.com/product/baas

About the Authors

Matt Zand is a serial entrepreneur and the founder of 4 tech startups: DC Web Makers, Hash Flow, Coding Bootcamps and High School Technology Services. He is a leading author of Hands-on Smart Contract Development with Hyperledger Fabric book by O'Reilly Media. He has written more than 100 technical articles and tutorials on blockchain development for Hyperledger, Ethereum and Corda R3 platforms at sites such as IBM, SAP, Alibaba Cloud, Hyperledger, The Linux Foundation, and more. At Hash Flow, he leads a team of blockchain experts for consulting and deploying enterprise decentralized applications. As chief architect, he has designed and developed blockchain courses and training programs for Coding Bootcamps. He has a master's degree in business management from the University of Maryland. Prior to blockchain development and consulting, he worked as senior web and mobile App developer and consultant, investor, business advisor for a few startup companies. You can connect with him on LinkedIn

Brian Wu is an advisor at Hash Flow. He has written 7 books related to blockchain. Visit his Amazon author profile page to learn more: https://www.amazon.com/Xun-Brian-Wu/e/B07MK53PYN/

0 0 0
Share on

Alibaba Clouder

2,600 posts | 754 followers

You may also like


Alibaba Clouder

2,600 posts | 754 followers

Related Products