This guide explains BIP 48 Multi-Script Hierarchy for Multi-Sig Wallets in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 48 documents the deployed m/48 hierarchical practice for deterministic multisignature wallets. It adds a hardened script-type level between account and change, enabling one seed hierarchy to separate nested SegWit and native SegWit multisig branches.
- Why it matters: BIP 48 makes multisig derivation more interoperable by giving script type an explicit hardened branch. Safe recovery still requires the entire multisig policy and every cosigner record, not one path or seed.
- Current position: The BIP is Deployed, Applications and Specification.
BIP 48 Multi-Script Hierarchy for Multi-Sig Wallets in simple English
BIP 48 Multi-Script Hierarchy for Multi-Sig Wallets: The hierarchy is m / 48 hardened / coin type hardened / account hardened / script type hardened / change / address index. Preserve every hardening marker exactly.
Simple example
A node operator is checking BIP 48 Multi-Script Hierarchy for Multi-Sig Wallets. Script type 1 represents nested P2SH-P2WSH and 2 native P2WSH.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Status and scope
The BIP is Deployed, Applications and Specification. It standardises an existing wallet derivation practice and does not alter Bitcoin consensus.
Six path levels
The hierarchy is m / 48 hardened / coin type hardened / account hardened / script type hardened / change / address index. Preserve every hardening marker exactly.
Network and account
Coin type separates mainnet zero from testnet one in the specification. Accounts increment from zero and should isolate different wallet identities and policies.
Script-type branch
Script type 1 represents nested P2SH-P2WSH and 2 native P2WSH; native P2WSH is the recommended default. Do not infer future script values without a versioned standard.
Key sorting
BIP 48 relies on deterministic key sorting through BIP 67 so all participants derive the same script. Store cosigner origins and verify resulting key order rather than sorting display strings.
Change and index
Change zero is external receiving and one internal change; address indexes increase from zero. Coordinate issuance and preserve gap and highest-used evidence for both branches.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is the main point of BIP 48 Multi-Script Hierarchy for Multi-Sig Wallets?
BIP 48 Multi-Script Hierarchy for Multi-Sig Wallets: The hierarchy is m / 48 hardened / coin type hardened / account hardened / script type hardened / change / address index.
For BIP 48 Multi-Script Hierarchy for Multi-Sig Wallets, what should a beginner know about status and scope?
The BIP is Deployed, Applications and Specification. It standardises an existing wallet derivation practice and does not alter Bitcoin consensus.
For BIP 48 Multi-Script Hierarchy for Multi-Sig Wallets, what should a beginner know about six path levels?
The hierarchy is m / 48 hardened / coin type hardened / account hardened / script type hardened / change / address index.
For BIP 48 Multi-Script Hierarchy for Multi-Sig Wallets, what should a beginner know about network and account?
Coin type separates mainnet zero from testnet one in the specification. Accounts increment from zero and should isolate different wallet identities and policies.
Conclusion
BIP 48 makes multisig derivation more interoperable by giving script type an explicit hardened branch. Safe recovery still requires the entire multisig policy and every cosigner record, not one path or seed.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.



Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.