Month: February 2017

Note: I originally wrote this in April 2016 while traveling thru Asia and kept it in my private log area until now.

Many different software vendors have produced different HD (e.g. BIP32-compliant) Wallets, and it’s nice, but the supposed features/benefits of HD wallets aren’t really able to be used except by the most-technical of end-users. That’s because the HD standard is both really flexible (by enabling a multitude of derivation paths), and because multiple standards are used by wallet software vendors, some of which are conflicting, and each developer will use whichever standard he/she thinks is best, without regard to interoperability or what’s best and easiest for the end-user.

I propose an HD Wallet standard to which all wallets should conform for interoperability, e.g. an HD wallet created by a user with a certain software package, should be able to work with a different HD Wallet software package on possibly an altogether different OS/software ecosystem.

Example:

An HD Wallet created by a user at home on a laptop running Windows 7 should also work with that users’ Android HD Wallet software package, and with a minimum of setup required to port over the wallet. It should also work with both at the same time, meaning that a user shouldn’t have to sweep all funds to the new wallet — the user should have the choice of using either wallet based on where they are and what machine/device they wish to work from at that particular moment.

Proposed Standards

Key generation and key serialization are separate and unique processes, and regardless of the generation method used, the user should be able to port the serialized keys to different wallet software. Nevertheless, for ease-of-use and security/backup purposes, I will also address key generation here.

Key Generation

A user should always be able to easily generate their BIP32 root private key via a mnemonic seed phrase consisting of a number of words. BIP0039 is one such scheme, and the popular Electrum wallet uses a very similar, but not 100% compliant scheme.

Regardless of which scheme is used to generate the BIP32 root private key, both the seed phrase and the name of the mnemonic->seed scheme used (e.g. “BIP0039” or “Electrum”) shall be made available to the user so that the user is able to manage his/her own keys at will, without vendor lock-in. This can be hidden on an “advanced options” screen, but should not be extremely difficult to access.

Users can be warned of the dangers of displaying their mnemonic seed in clear-text, nevertheless, all wallets should make both these pieces of information available to all users:

2. Name of Scheme used to convert from seed phrase to BIP32 root private key, e.g.:

BIP0039

Key Serialization/Deserialization

All HD Wallets should:

1. Make available the wallet’s BIP32 derivation path for both receive and change addresses, e.g.:

Receive: m/0'/0/n
Change: m/0'/1/n

2. Accept a BIP0032 extended key (any derived key/depth also, don’t have to be the original root) and operate on that key as if it were the root.

3. Accept a custom user-specified BIP32-compliant derivation path and operate on that given path as long as the entire path is not entirely used (e.g. every one of the 4294967295 || 2147483647 (whatever the number is) has not been used. The path must end in a ‘n’, which will be used to generate receive addresses. The next-highest path element will be incremented and used for change addresses (e.g. for a custom user-specified path of ‘m/0/0/7/n’, change addresses will be generated from ‘m/0/0/8/n’). Or users can specify a derivation path for change addresses too. Yeah, I like that better.

4. Allow for export of a BIP0032 root **private** key for use in other wallet software.

5. Allow for export of a BIP0032 root **public** key for use in other wallet software.

6. Disallow import of individual keys except by sweeping the key into a BIP32 wallet. In other words, sweeping should be the only method allowed for import of individual keys.

Security

Obviously the Mnemonic seed phrase and all BIP32 HD **private** keys should be encrypted in the wallet software and protected by some form of user authentication, however, as this document is intended only to be a guideline for interoperability for HD wallets, I leave the implementation of security up to the individual software vendors. (And in the hope that each understands the implications of good wallet security and uses industry-standard best practices in doing so.)