Context:

• Don't require "m" when creating derivation path strings #2449
• Remove m prefix requirement #2451
• Reverted in PR Revert "Remove unnecessary m/ prefix requirement" #2674

To Close this issue:

1. bip32 module should continue to support parsing a HDW string of form m/44'/0'/0'/0/a/b/c
2. There should probably be some abstraction for a thing that results from parsing the string above (hence referred to as HDW)
3. There should be some abstraction for the a/b/c bit from (1) and one should be able to extend a HDW with a , a/b/c, etc.

Other considerations

The module is probably too tightly named, should it be called hdw and support bips 43, and 44 (ie., function purpose() returns a const and we have all the "current" purposes hardcoded (see below)

Some of my personal notes on HDW

BIP-32: Defines HD wallets, default account is m/0'/*
BIP-43: Defines purpose i.e., m/0'
BIP-44: Defines m / purpose' / coin_type' / account' / change / address_index

(Bitcoin mainnet is coin_type 0) - m/44'/0'/0'

??? : Defines account for P2PKH outputs:

BIP-45: Defines account for P2SH multisig outputs: m/45'/0'/0'
BIP-48: Defines account for BIP-69 sorted multisig outputs: m/48'/0'/0'
BIP-49: Defines account for P2SH-P2WPKH (nested) outputs: m/49'/0'/0'
BIP-84: Defines account for P2WPKH (BIP-173) outputs: m/84'/0'/0'
BIP-86: Defines account for P2TR outputs (BIP-341): m/86'/0'/0'
BIP-87: Defines account for P2WSH sorted multi (Hierarchy for Deterministic Multisig Wallets)

Elephant

Just to mention the elephant in the room, should the bip32 module (in its current or future form) even be in rust-bitcoin or should it be a separate crate? Some of this is pure wallet stuff but some, for example parsing output from Bitcoin Core, is more general.

• BIP-32
• BIP-43
• BIP-44
• BIP-84
• BIP-86
• BIP-87