Bitcoin Key Derivation Paths Reference: BIP32 to BIP86

Bitcoin Derivation Paths Overview

Bitcoin hierarchical deterministic (HD) wallets generate an entire tree of key pairs from a single seed phrase. The derivation path is the route through that tree to a specific key. Each standard (BIP44, BIP49, BIP84, BIP86) defines a different path structure that produces a different address type, from legacy P2PKH addresses starting with 1 to modern Taproot addresses starting with bc1p.

Understanding derivation paths matters for wallet recovery, cross-wallet compatibility, and advanced Bitcoin operations like running watch-only wallets with an xpub. The following table summarizes the five key BIP standards that define how Bitcoin wallets derive keys.

To inspect extended public keys and see derived addresses across these paths, use the xpub viewer tool.

Path Format Explained

All BIP44-family derivation paths follow the same five-level structure defined by BIP43 and BIP44. The general format is:

m / purpose' / coin_type' / account' / change / address_index

The apostrophe (') after the first three levels indicates hardened derivation. This is a critical security feature: it ensures that exposing an extended public key at any of these levels cannot compromise sibling branches or parent keys. The change and address_index levels use normal (non-hardened) derivation so that an xpub at the account level can generate all child public keys without the private key, enabling watch-only wallets.

Note: Hardened derivation adds 0x80000000 (2^31) to the index value. So 44' is actually index 2147483692 (0x8000002C). The apostrophe is shorthand notation.

BIP32: The Foundation

BIP32, authored by Pieter Wuille in 2012, defines the core algorithm for hierarchical deterministic key derivation. It does not specify a particular path structure: it provides the cryptographic primitives that all subsequent BIPs build on.

The master seed generates a master extended private key and chain code via HMAC-SHA512(Key = "Bitcoin seed", Data = seed). Child keys are then derived recursively. Normal derivation uses the parent public key as input (allowing public-key-only derivation), while hardened derivation uses the parent private key (providing stronger isolation between branches).

Before BIP32, wallets generated independent random keys for each address. Backing up a wallet required saving every individual private key. BIP32 made it possible to back up an entire wallet with a single seed, which BIP39 later standardized as a mnemonic phrase. For a deeper look at Bitcoin address evolution, see the Bitcoin address types guide.

BIP44: Legacy P2PKH Addresses

BIP44, authored by Marek Palatinus and Pavol Rusnak in 2014, standardized the five-level path structure described above. It uses purpose 44' and produces P2PKH addresses that start with 1.

The first receiving address for Bitcoin mainnet, account 0, is derived at path m/44'/0'/0'/0/0. The first change address is at m/44'/0'/0'/1/0. P2PKH transactions are the largest in terms of virtual bytes, making them the most expensive to spend on-chain. While all wallets still support BIP44 for compatibility, new wallets default to SegWit or Taproot paths.

BIP49: Wrapped SegWit (P2SH-P2WPKH)

BIP49, authored by Daniel Weigl in 2016, was a transitional standard that brought SegWit benefits while maintaining backward compatibility. It uses purpose 49' and produces P2SH-wrapped SegWit addresses starting with 3.

The first receiving address is at path m/49'/0'/0'/0/0. Under the hood, the address wraps a native SegWit script inside a P2SH script: the wallet computes HASH160(0x0014 || HASH160(pubkey)) to produce the P2SH address. This allowed senders who did not yet support SegWit to pay to SegWit-enabled recipients. The extended key prefix ypub distinguishes BIP49 keys from BIP44 xpub keys.

BIP49 addresses are smaller than P2PKH and benefit from the SegWit witness discount, but they are still larger than native SegWit (BIP84) addresses because of the P2SH wrapping overhead.

BIP84: Native SegWit (P2WPKH)

BIP84, authored by Pavol Rusnak in 2017, defines the derivation path for native SegWit addresses. It uses purpose 84' and produces P2WPKH addresses encoded in Bech32 format, starting with bc1q.

The first receiving address is at path m/84'/0'/0'/0/0. Native SegWit provides the best fee savings for single-signature transactions because the full witness discount applies without P2SH overhead. Bech32 encoding also includes error detection and is case-insensitive, reducing user errors when copying addresses. BIP84 is currently the most widely used derivation path, with the extended key prefix zpub.

BIP86: Taproot (P2TR)

BIP86, authored by Ava Chow in 2021, defines derivation for single-key Taproot (P2TR) outputs. It uses purpose 86' and produces addresses encoded in Bech32m format, starting with bc1p.

The first receiving address is at path m/86'/0'/0'/0/0. BIP86 involves an additional step compared to earlier BIPs: the derived public key becomes an "internal key" that is tweaked with HashTapTweak(internal_key) to produce the output key. This tweak commits to an empty script tree, making it a key-path-spend-only output per BIP341.

Taproot outputs offer privacy benefits because single-key spends, multisig spends, and complex script spends all look identical on-chain. Combined with Schnorr signatures, Taproot also enables more efficient multisig constructions. For a comprehensive overview, see the Taproot and Schnorr signatures explainer.

Derivation Path Examples

The following table shows concrete path examples for common scenarios. All examples assume Bitcoin mainnet (coin_type = 0') and the first account (account = 0').

Multisig Derivation Paths

Single-signature paths (BIP44/49/84/86) do not cover multisig wallets. Separate BIPs define derivation for multi-key setups:

• BIP45 (m/45'/cosigner_index/change/index): early P2SH multisig standard, now largely superseded
• BIP48 (m/48'/coin'/account'/script_type'/change/index): adds a script_type level where 1' indicates P2SH-P2WSH and 2' indicates P2WSH
• BIP87 (m/87'/coin'/account'/change/index): modern approach that relies on output descriptors for script semantics

BIP48 is the most widely used multisig derivation standard today, supported by Sparrow Wallet, Coldcard, and other multisig-focused wallets. For constructing and inspecting multisig transactions, see the PSBT inspector and multisig planner.

Wallet Compatibility

Not all wallets support all derivation paths. When recovering a wallet from a seed phrase, selecting the wrong derivation path will produce valid but empty addresses. The following table shows support across popular wallets.

When working with signing devices, always confirm which derivation paths the firmware supports before sending funds. Some older hardware wallet firmware versions do not support Taproot addresses. For help choosing a hardware wallet, see the hardware wallet comparison.

Recovery and the Gap Limit

The address gap limit is critical during wallet recovery. BIP44 specifies a default gap limit of 20: if a wallet scans 20 consecutive addresses with no transaction history, it stops looking for funds on that account. This means that if you skipped addresses (by generating more than 20 unused receiving addresses), a standard recovery may miss your funds.

During recovery, wallets must also scan across all supported derivation paths (BIP44, BIP49, BIP84, BIP86) to discover funds that may have been received at different address types. Sparrow Wallet and Electrum allow you to set a custom gap limit during recovery to handle non-standard usage patterns.

Hardened vs Normal Derivation

The distinction between hardened and normal derivation is the most important security property of BIP32. In normal derivation, child keys are derived using the parent public key. This means an extended public key (xpub) can derive all child public keys without the private key. This is what makes watch-only wallets possible.

However, normal derivation has a risk: if an attacker obtains both an extended public key and any single child private key, they can compute the parent private key and derive all sibling private keys. Hardened derivation prevents this by using the parent private key as input, which means the extended public key cannot derive hardened children at all.

This is why the BIP44 path structure hardens the first three levels (purpose, coin_type, account) but leaves the last two (change, address_index) unhardened. The hardened levels create security firewalls between accounts and cryptocurrencies, while the unhardened levels enable xpub-based address generation for key management workflows.

Frequently Asked Questions

What is a Bitcoin derivation path?

A derivation path is a sequence of indices that tells an HD wallet how to navigate from the master seed to a specific key pair. The path m/84'/0'/0'/0/0 means: start at the master key, go to purpose 84 (native SegWit), coin type 0 (Bitcoin), account 0, external chain, first address. Every wallet using the same seed and the same derivation path will generate the same addresses.

What is the difference between BIP44, BIP49, BIP84, and BIP86?

Each BIP defines a purpose field that produces a different address type. BIP44 produces legacy P2PKH addresses (1...). BIP49 produces wrapped SegWit P2SH-P2WPKH addresses (3...). BIP84 produces native SegWit P2WPKH addresses (bc1q...). BIP86 produces Taproot P2TR addresses (bc1p...). The path structure is identical across all four: only the purpose value and resulting address type differ.

What does the apostrophe mean in a derivation path?

The apostrophe (') denotes hardened derivation. Technically, it adds 2^31 (0x80000000) to the index value. Hardened child keys are derived using the parent private key rather than the parent public key. This prevents a leaked child private key from being combined with the parent extended public key to derive sibling keys. The first three levels of BIP44 paths are hardened for this security reason.

Which derivation path should I use for a new Bitcoin wallet?

For single-signature wallets, BIP84 (native SegWit) or BIP86 (Taproot) are the best choices. BIP84 offers the broadest compatibility: every modern wallet and exchange supports bc1q addresses. BIP86 provides slightly better privacy and future-proofs for advanced Taproot features, but a small number of older services cannot send to bc1p addresses. Most wallet software now defaults to BIP84 for new accounts.

Why does my restored wallet show zero balance?

The most common cause is a derivation path mismatch. If you sent funds to BIP84 (native SegWit) addresses but restored using BIP44 (legacy), the wallet will generate different addresses and find no transaction history. During recovery, make sure to select the same address type you originally used, or use a wallet like Sparrow that scans all derivation paths automatically. The gap limit can also be a factor if you generated many unused addresses.

Can I use the same seed phrase with different derivation paths?

Yes. A single seed phrase can derive keys at any number of paths simultaneously. Many wallets create accounts under BIP44, BIP49, BIP84, and BIP86 from the same seed, each producing a separate set of addresses. The paths are independent branches of the key tree, so funds at one path are not visible or accessible when querying a different path.

What is the gap limit and why does it matter?

The gap limit is the number of consecutive unused addresses a wallet scans before it stops looking for funds. The BIP44 default is 20. If you generated more than 20 unused receiving addresses in sequence (for example, by using an e-commerce system that pre-generates addresses), a standard wallet recovery may not find all your funds. You can increase the gap limit in wallets like Sparrow or Electrum to handle this.

This reference guide is for informational purposes only and does not constitute financial advice. Derivation path standards are defined by their respective BIP specifications. Always verify your wallet's derivation path before sending funds, and test recovery procedures with small amounts first.