bip32: Understand and fix the m/ problem

[tcharding]

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

Some more things of interest:

BIP-32 never mentions the term 'derivation path' so our DerivationPath is either misnamed or a rust-bitcoin only concept. The bip uses the term "chain" to refer to the stuff after the account eg the a/b/c in m/i'/0'/a/b/c

Note BIP-43 and BIP-44 add "purpose" and "coin" to the front of the unnamed-thing-that-we-call-derivation-path

The best nomenclature I can garner from the combination of all three bips is that the unnamed-thing-that-we-call-derivation-path is the string representation of a Hierarchical Deterministic Wallet (HDW) that may or may not include the chain (as defined above).

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

[apoelstra]

If you want to support those BIPs it definitely needs to be another crate that I will have no part in maintaining. If people want their keys to serve specific purposes they should use descriptors, not abuse their key derivation paths for it.

[apoelstra]

Also, "derivation path" is definitely a standard term. You can search it and you will find hundreds of articles, for example https://www.ledger.com/blog/understanding-crypto-addresses-and-derivation-paths

[tcharding]

I may be wrong in original description "chain" may only be the internal/external child number not everything after it ...

[tcharding]

I asked the internet: https://bitcoin.stackexchange.com/questions/122581/where-does-the-term-derivation-path-originate