Home › Topics › Wallets › BIP 44

BIP 44 (BIP44 derivation path): Multi-Account Hierarchy for Deterministic Wallets

Also known as: BIP44 derivation path, m/44'/0'/0', multi-account hierarchy, legacy derivation, BIP44, BIP-0044.

In plain English: Defines a standard layout for HD wallets that organizes keys by coin type, account, and receiving versus change addresses. Because wallets share this layout, a recovery phrase from one wallet can usually be restored in another.

Status
Deployed
Type
Specification
Layer
Applications
Authors
Marek Palatinus, Pavol Rusnak
Assigned
Last changed
Requires
BIP 32, BIP 43
Topics
Wallets, HD Wallets, Multi-Coin, Key Derivation
Source
bip-0044.mediawiki on GitHub · Markdown

Full specification

Abstract

This BIP defines a logical hierarchy for deterministic wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on).

This BIP is a particular application of BIP43.

Motivation

The hierarchy proposed in this paper is quite comprehensive. It allows the handling of multiple coins, multiple accounts, external and internal chains per account and millions of addresses per chain.

Path levels

We define the following 5 levels in BIP32 path:

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

Apostrophe in the path indicates that BIP32 hardened derivation is used.

Each level has a special meaning, described in the chapters below.

Purpose

Purpose is a constant set to 44' (or 0x8000002C) following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification.

Hardened derivation is used at this level.

Coin type

One master node (seed) can be used for unlimited number of independent cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same space for various cryptocoins has some disadvantages.

This level creates a separate subtree for every cryptocoin, avoiding reusing addresses across cryptocoins and improving privacy issues.

Coin type is a constant, set for each cryptocoin. Cryptocoin developers may ask for registering unused number for their project.

The list of already allocated coin types is in the chapter "Registered coin types" below.

Hardened derivation is used at this level.

Account

This level splits the key space into independent user identities, so the wallet never mixes the coins across different accounts.

Users can use these accounts to organize the funds in the same fashion as bank accounts; for donation purposes (where all addresses are considered public), for saving purposes, for common expenses etc.

Accounts are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.

Hardened derivation is used at this level.

Software should prevent a creation of an account if a previous account does not have a transaction history (meaning none of its addresses have been used before).

Software needs to discover all used accounts after importing the seed from an external source. Such an algorithm is described in "Account discovery" chapter.

Change

Constant 0 is used for external chain and constant 1 for internal chain (also known as change addresses). External chain is used for addresses that are meant to be visible outside of the wallet (e.g. for receiving payments). Internal chain is used for addresses which are not meant to be visible outside of the wallet and is used for return transaction change.

Public derivation is used at this level.

Index

Addresses are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.

Public derivation is used at this level.

Account discovery

When the master seed is imported from an external source the software should start to discover the accounts in the following manner:

  1. derive the first account's node (index = 0)
  1. derive the external chain node of this account
  1. scan addresses of the external chain; respect the gap limit described below
  1. if no transactions are found on the external chain, stop discovery
  1. if there are some transactions, increase the account index and go to step 1

This algorithm is successful because software should disallow creation of new accounts if previous one has no transaction history, as described in chapter "Account" above.

Please note that the algorithm works with the transaction history, not account balances, so you can have an account with 0 total coins and the algorithm will still continue with discovery.

Address gap limit

Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain. We scan just the external chains, because internal chains receive only coins that come from the associated external chains.

Wallet software should warn when the user is trying to exceed the gap limit on an external chain by generating a new address.

Registered coin types

These are the default registered coin types for usage in level 2 of BIP44 described in chapter "Coin type" above.

All these constants are used as hardened derivation.

indexhexacoin
00x80000000Bitcoin
10x80000001Bitcoin Testnet

This BIP is not a central directory for the registered coin types, please visit SatoshiLabs that maintains the full list:

SLIP-0044 : Registered coin types for BIP-0044

To register a new coin type, an existing wallet that implements the standard is required and a pull request to the above file should be created.

Examples

coinaccountchainaddresspath
Bitcoinfirstexternalfirstm / 44' / 0' / 0' / 0 / 0
Bitcoinfirstexternalsecondm / 44' / 0' / 0' / 0 / 1
Bitcoinfirstchangefirstm / 44' / 0' / 0' / 1 / 0
Bitcoinfirstchangesecondm / 44' / 0' / 0' / 1 / 1
Bitcoinsecondexternalfirstm / 44' / 0' / 1' / 0 / 0
Bitcoinsecondexternalsecondm / 44' / 0' / 1' / 0 / 1
Bitcoinsecondchangefirstm / 44' / 0' / 1' / 1 / 0
Bitcoinsecondchangesecondm / 44' / 0' / 1' / 1 / 1
Bitcoin Testnetfirstexternalfirstm / 44' / 1' / 0' / 0 / 0
Bitcoin Testnetfirstexternalsecondm / 44' / 1' / 0' / 0 / 1
Bitcoin Testnetfirstchangefirstm / 44' / 1' / 0' / 1 / 0
Bitcoin Testnetfirstchangesecondm / 44' / 1' / 0' / 1 / 1
Bitcoin Testnetsecondexternalfirstm / 44' / 1' / 1' / 0 / 0
Bitcoin Testnetsecondexternalsecondm / 44' / 1' / 1' / 0 / 1
Bitcoin Testnetsecondchangefirstm / 44' / 1' / 1' / 1 / 0
Bitcoin Testnetsecondchangesecondm / 44' / 1' / 1' / 1 / 1

Reference

Questions about BIP 44

What is BIP 44?

BIP 44, “Multi-Account Hierarchy for Deterministic Wallets”, also known as the BIP44 derivation path, is a specification Bitcoin Improvement Proposal written by Marek Palatinus and Pavol Rusnak and assigned in April 2014. Defines a standard layout for HD wallets that organizes keys by coin type, account, and receiving versus change addresses. Because wallets share this layout, a recovery phrase from one wallet can usually be restored in another.

Is BIP 44 active?

Yes. BIP 44 has the status Deployed, which means it is live: adopted by the Bitcoin network or by widely used software.

Who wrote BIP 44?

BIP 44 was written by Marek Palatinus and Pavol Rusnak. Its number was assigned on April 24, 2014.

What does BIP 44 build on?

BIP 44 requires BIP 32 (Hierarchical Deterministic Wallets) and BIP 43 (Purpose Field for Deterministic Wallets). Read those first to understand this proposal.

Which BIPs build on BIP 44?

12 other BIPs reference BIP 44, including BIP 49 (Derivation scheme for P2WPKH-nested-in-P2SH based accounts), BIP 47 (Reusable Payment Codes for Hierarchical Deterministic Wallets), BIP 84 (Derivation scheme for P2WPKH based accounts) and BIP 388 (Wallet Policies for Descriptor Wallets).

Where can I read the full BIP 44 specification?

The complete text of BIP 44 is on this page, taken unchanged from the official bitcoin/bips repository on GitHub. It is also available as Markdown and JSON.

BIPs that build on BIP 44

Learn more

Guides

Comparisons

Free tools

Glossary

Related proposals