HD Wallets
For a long time, BIP32 was the standard way to structure a Bitcoin wallet. While type-42 has since taken over as the standard approach due to its increased privacy and open-ended invoice numbering scheme, it's sometimes still necessary to interact with legacy systems using BIP32 key derivation.
This guide will show you how to generate keys, derive child keys, and convert them to WIF and Bitcoin address formats. At the end, we'll compare BIP32 to the type-42 system and encourage you to adopt the new approach to key management.
Generating BIP32 keys
You can generate a BIP32 seed with the SDK as follows:
You can also import an existing key as follows:
Now that you've generated or imported your key, you're ready to derive child keys.
Deriving Child Keys
BIP32 child keys can be derived from a key using the derive_xprv_from_mnemonic
function. Here's a full example:
Any of the standard derivation paths can be passed into the derivation function.
Converting Between Formats
XPRIV keys can be converted to normal PrivateKey
instances, and from there to WIF keys. XPUB keys can be converted to normal PublicKey
instances, and from there to Bitcoin addresses. XPRIV keys can also be converted to XPUB keys:
This guide has demonstrated how to use BIP32 for key derivation and format conversion. You can continue to use BIP32 within BSV wallet applications, but it's important to consider the disadvantages and risks of continued use, which are discussed below.
Disadvantages and Risks
BIP32 allows anyone to derive child keys if they know an XPUB. The number of child keys per parent is limited to 2^31, and there's no support for custom invoice numbering schemes that can be used when deriving a child, only a simple integer. Finally, BIP32 has no support for private derivation, where two parties share a common key universe no one else can link to them, even while knowing the master public key. It's for these reasons that we recommend the use of type-42 over BIP32. You can read an equivalent guide here.
Last updated