We Need to Document Bitcoin HD Derivations for Multisig (aka m/48' or BIP-0048)

[ChristopherA]

Bitcoin HD Derivations for Multisig (aka m/48' or BIP-0048)

Problem Statement

A number of wallet companies have settled on using the HD key derivation of m/48' for use with hardware wallets doing multisig, but so far there is no formal documenation in the form of a BIP or SLIP.

My best guess that the idea was that by using m/48' for multisig paths, you'd never need to check a single signature bitcoin address for balance from those derived keys, and you'l never reuse a derived key that will be used for a single-signature wallet and also multisig wallet.

Christopher Allen writes a side note

This still presumes one hardware wallet, one master seed. But there may emerge new hardware wallets that have multiple master seed on them, and FullyNoded 2 for iOS already does. I still have concerns about future airgapped wallets (#LetheKit v2?) offering to network multisig coordinators keys already used by another multisig network coordinator. Not quite how I'd fix that, but I had a weird idea about using a hash of the wallet descriptor without any but the first pubkey in it so the derivation would be a different for each wallet and key holder and never conflict with another derived key. But m/48' seems easier and solves the immediate problem.

Who is using it

It appears that Coldpay may have initiated it.

https://github.com/bitpay/copay#wallet-export-format :

Since version 1.5, Copay uses the root m/48' for hardware multisignature wallets. This was coordinated with Ledger and Trezor teams. While the derivation path format is still similar to BIP44, the root was in order to indicate that these wallets are not discoverable by scanning addresses for funds. Address generation for multisignature wallets requires the other copayers extended public keys.

Trezor has some limited notes on it at https://wiki.trezor.io/Standard_derivation_paths

m/48'/cointype'/account'//change/address ... multisig P2SH, implemented in Copay wallet (backups), no BIP or SLIP defined

@stepansnigirev reports that Electrum wallet, Trezor, Ledger and ColdCard all use it.

Questions

Paths for legacy, nested segwit, and native segwit

Reportedly (reported by @stepansnigirev not confirmed)

• m/48'/0'/0'/0' legacy
• m/48'/0'/0'/1' nested segwit
• m/48'/0'/0'/2' native segwit

Hardened Paths

Are all of these hardened paths like above?

Change

Anything weird in change addresses?

Accounts

How are different accounts handled?

[ChristopherA]

My biggest problem with current practices of m/48' is that since most wallets are stateless or airgapped, there is a risk that a multisig coordinator will request the use of a HD derivation during multisig setup that was used by a different multisig coordinator app that doesn't know about the use of the first one issued.

Ideally, the wallet should just give the next incremental path when it generates the child HD key, but without knowing state it doesn't know which one is the next one.

[Overtorment]

correction: its m/45' for legacy

[stepansnigirev]

Yes, I've never seen m/48'/0'/0'/0' path. According to ColdCard export file m/45h is used for legacy:
https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki

[Overtorment]

relevant: https://github.com/satoshilabs/slips/blob/master/slip-0132.md

[jonathancross]

s/Coldpay/Copay/ 😉

[craigraw]

While it is certainly not ideal that there exists no BIP48 for this emerged 'standard', there does not seem to be any rational option but to follow it.

Given the widespread usage, proposing anything else will immediately create a double standard, leading to confusion and likely loss of funds through misconfiguration. This seems to be far worse than proceeding with the generally accepted derivation paths we already have.

In answer to the questions above, I have for Account 0:

Script type	Default Account Derivation
Multisig P2SH	m/45'/0'/0'
Multisig P2SH-P2WSH	m/48'/0'/0'/1'
Multisig P2WSH	m/48'/0'/0'/2'

Are all of these hardened paths like above?

Yes.

Anything weird in change addresses?

No, /0/* and /1/* are appended to the paths above as per normal.

How are different accounts handled?

In all cases, the third element of the path increments e.g. P2WSH Account 1: m/48'/0'/1'/2'

I have used these paths in defining a standard for sharing BIP44 account level information: BlockchainCommons/Research#50 and started a discussion topic for the PR here: #24

[Overtorment]

m/45'/0'/0' doesnt seem to be correct. should be m/45' (yeah, no accounts)

[craigraw]

Appears you're right - here's an example testnet Coldcard export file: https://github.com/Coldcard/firmware/blob/806c5c4cf8ac3e2768affea21ced8cce9f5e0157/testing/data/multisig/ccxp-0F056943.json

[craigraw]

Corrected the PR to reflect that as per BIP45 the hardened derivation in P2SH has only one level of m/45'.

[Rspigler]

This is the best documentation I can find for m/48'

m / purpose' / coin_type' / account' / script_type' / change / address_index (spesmilo/electrum#4352 (comment))

How does this work without a cosigner_index like BIP45?

[Fonta1n3]

This is the best documentation I can find for m/48'

m / purpose' / coin_type' / account' / script_type' / change / address_index (spesmilo/electrum#4352 (comment))

How does this work without a cosigner_index like BIP45?

It seems to be that all "bip48" wallets are by default supporting bip67. cosigner_index should never be used, that is what bip67 is for. bip45 is outdated IMO and should be made redundant and only exist for backward compatibility.

[Rspigler]

Ah, that makes a lot of sense, thanks!

[Rspigler]

My biggest problem with current practices of m/48' is that since most wallets are stateless or airgapped, there is a risk that a multisig coordinator will request the use of a HD derivation during multisig setup that was used by a different multisig coordinator app that doesn't know about the use of the first one issued.

If we are creating a standard for secure offline multisignature wallets, it should include all devices, ie computers (state obviously) and HWW (some with state? and most without). So there's a simple solution if the device has access to any state (just keep track), but I don't believe there is any solution for m/48' for stateless devices.