HD Wallets — Structure and its implementation

In the previous blog post, we discussed key trees and their nodes. The next step is imposing a wallet structure on the concepts we discussed. The layout for this section is a default only; you can add more features for the wallet and make it more secure.

Wallet layout

A Deterministic Hierarchical Wallet deals with many accounts’. Those accounts are numbered, from 0. One account is aligned with one client, and they are not required to support more than one account. If they need supporting more accounts than they use the default account.

Each account is composed of two key pair chains: an internal chain and an external chain. The external keychain is utilized to generate new public addresses, while the internal keychain is used for all operations which are not to be communicated like change addresses or generation of addresses. Clients only use the external key chain for everything.

• m/iH/0/k corresponds to the k’th keypair of the external chain of account number i of the wallet derived from master m.
• m/iH/1/k corresponds to the k’th keypair of the internal chain of account number i of the wallet derived from master m.

In general architecture for a Blockchain module can be grouped into three components:

1. Signing module
2. Public addresses module
3. Networking module

Signing Module

This module is the only holding sensitive data such as the private key. It receives an unsigned transaction, then uses the hidden private key to sign the transaction and returns the signed transaction which can be published to the Blockchain network to make it permanent. It is most feasible to implement this in the hardware such as the Trezor as it separates the private key from other components.

Public Address Module

Private and public key pair are loosely coupled. So both can be separated and stored at different locations. Public-key distribution is the key feature behind hierarchical deterministic wallet. This shares the key with other parties so they could send the payments.

Networking Module

The networking module is in the middle of the other two, and it also acts as the controller module. It’s in charge of several complicated tasks:

1. Connecting to the Blockchain p2p network.
2. Synchronizing and keeping up to date with the blockchain.
3. Monitoring relevant transactions for the user or the group of users.
4. Publishing transactions to the blockchain network.

Networking module can be a huge task. It’s better to use API’s for thin wallets.

There are several ways HD wallets can be used, some of the general use cases for them are as follows:

Use cases

Full wallet sharing
We need to share the master private extended key, in cases two different systems want to access a shared wallet, allowing both to perform spendings. Nodes typically can keep a pool of N look-ahead keys cached for external chains. This helps to keep a watch for incoming payments. The look-ahead for internal chains is very small, as in internal chains we don’t expect any gaps. An extra look-ahead could be enabled for the unused account’s chains and later could trigger the creation of a new account when in use.

Audits
We can hide for secret key and share the public extended keys with the auditor, he/she will have the full access to the list of incoming and outgoing payments. This will allow the auditor to view all transactions by all accounts. On the other hand, our secret keys would be safe and secure.

Per-office balances
When a company has several independent offices, they can all use derived wallets from a single master key. This will allow the head office to maintain a master wallet/key which can see all transactions of within the company, and also allow transfer of funds to the independent offices.

Recurrent business-to-business transactions
In case two partners want to transfer money, one can use the extended public key for the external chain and send a specific account (M/i h/0) as a sort of “super address”, allowing conduction of frequent transactions that cannot be associated, but this will remove the need for a new address for each payment. Such a mechanism is also beneficial for mining pool operators as it provides with variable payout address.

Unsecured money receiver
When an unsecured web server is running an e-commerce website, it should know public addresses that will be used to receive payments. The web server only needs to know the extended public key of the external chain of only a single account. This means if someone illegally obtains the access to the web server, he/she can at most see incoming payments but won’t be able to steal the money, will not be able to distinguish between outgoing transactions, nor be able to see payments received by other web servers if several are being used with wallets.