Wallets Recovery [DRAFT]

Giving users their seed phrase is not enough.

While great advances have been made in interoperability and recoverability, developers across the industry continue to build wallets that either:

• Don't implement BIP standard(s).
• Implement a BIP standard, but with important differences from other wallets that also implemented it.
• Implement a BIP standard, but one that has not been widely adopted (and perhaps only by them).
• Don't have clear documentation about their derivation paths, backup and recovery processes.

This list is meant to gather information about wallet defaults for external recovery. Wallets come and go, information gets lost and users are left with tears. Responsible wallet makers document external recovery.

Users should not have to dig or read the source code of a wallet to figure-out the Derivation Path or Redeem Scripts.

If we went to your website and couldn't find it => ☠️☠️☠️ [EXTERNAL RECOVERY NOT DOCUMENTED].

Status	Wallet	Path and/or Script	Note
✅	Bitcoin Wallet app↗︎	BIP32 non 44 Compatible	Docs, Archive
🛑	Bither↗︎		[EXTERNAL RECOVERY NOT DOCUMENTED]
✅	Blockstream Green↗︎	Custom 2-of-2 Script	Recovery tool
✅	BlueWallet↗︎	m/49'|84'/0'/0'	Docs, Archive
🛑	BRD (Bread Wallet)↗︎		[EXTERNAL RECOVERY NOT DOCUMENTED]
🛑	BTC.com app↗︎		[EXTERNAL RECOVERY NOT DOCUMENTED]
⚠️	Casa Keymaster↗︎	m/49/0/X (X increments with each key rotation)	Unofficial Docs
🛑	Coin Wallet↗︎		[EXTERNAL RECOVERY NOT DOCUMENTED]
✅	Coinomi↗︎	m/44'/0'/0'	Docs
🛑	Eclair Mobile↗︎		[EXTERNAL RECOVERY NOT DOCUMENTED]
✅	Edge Wallet↗︎	m/44'|49'/0'/0'	Docs
🛑	Mycelium↗︎		[EXTERNAL RECOVERY NOT DOCUMENTED]
✅	OpenBazaar↗︎	m/44'/0'|1'|133'|145'/0'	Docs
⚠️	Rise Wallet↗︎	m/49'/0'/0'	[EXTERNAL RECOVERY NOT DOCUMENTED]
✅	Samourai↗︎	m/44'|49'|84'|47'/0'/0'	Docs, BIPs Supported
⚠️	Unchained Capital↗︎	m/45’/0’/0’/0/0 + Redeem Script	Docs, Archive, Script 404
✅	Wasabi↗︎	m/84'/0'/0' Very Deep Depths	Docs, BIPs Supported

Status	Hardware Wallets	Supported Paths	Note
✅	ColdCard↗︎	m/44'|49'|84'/0'/0' + Custom	Docs
✅	Ledger S/Nano↗︎	m/44'/0'/0'	Docs
✅	Trezor 1/t↗︎	m/44'|49'/0'/0'	Docs
✅	Opendime↗︎	WIF	Docs, Archive

Notes:

• Hardware wallets don't care about derivation in certain modes.

Todo:

• Complex desktop and special purpose wallets (i.e. Core, Electrum, BTCPay, etc...) are not listed yet.
• List hardware wallet's apps / services on the main table, need to be listed separately from their hardware. (i.e. Ledger Live)

Icon	Legend
🛑	Unknown. No obvious docs, research in progress
☠️	Not publicaly available or complex without a external tool available for the average user
⚠️	Known, but unofficially documented
✅	Documented + Link to doc

---

Explainer: Wallet Types

• Paper wallets are not actually wallets, but rather private keys and addresses printed out on paper. While the keys and addresses can technically be generated non-deterministically or deterministically, the usability is basically the same or poorer than a non-deterministic software wallet. They have a number of significant drawbacks, including encouraging address reuse, exposing keys to poorly secured networked devices (printer), and not handling change addresses. They should not be confused with recovery seeds.
• Non-deterministic wallets randomly generate all private / public key pairs independent of each other. Keypool buffer was added to the Bitcoin-Qt / Bitcoin Core wallet in October 2010, which allowed the wallet to create a collection of unused addresses, rather than generating new addresses one by one upon use. While this feature allowed for less frequent backups than before, the non-determinism still carried the risk of key loss if the pool was exhausted and a new key was generated beyond what was saved in backup.
• Deterministic wallets are essentially any wallet where "you can backup once... because all future addresses are determined in advance," which was a massive improvement in recoverability. There are two different forms:
  • Sequential deterministic wallets take a single seed phrase / passphrase and repeatedly increment it in order to generate new keypairs. This meant that the system would only need to store addresses, and then re-generate the private keys when needed.
  • Hierarchical deterministic wallets take a single seed phrase and randomly generate a master private / public key pair, which is then used to derive child key pairs that generate addresses. This system allows for the generation of addresses to occur without the master private key, with only the public key.
• Multi-signature wallets require multiple signatures or parties to sign a transaction in order to spend bitcoin. An M-of-N BIP-11 address must first be generated in order to receive bitcoin for spending in multi-signature transactions. While the 2-of-2 and 2-of-3 schemes are the most common, the maximum number of public keys is higher, and this could increase much more in the future with Schnorr signatures and Taproot.

Explainer: Derivation Paths

In hierarchical deterministic wallets (BIP-32), a derivation path is a sequence of fields or levels through which a wallet organizes coins in a multi-currency, multi-account, and multi-address system. According to BIP-44, this hierarchy consists of five levels, in addition to the master extended private key ('xpriv') represented by m (alternatively, derivation paths for the master extended public key or 'xpub' use M).

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

• Purpose: This field, which was added through BIP-43, indicates which standard the derivation path follows. Possibilities include 44 referring to the default BIP-44 P2PKH / '1' legacy addresses [Double check your wallet, BIP44 is inconsistenly implemented], 45 referring to BIP-45 P2SH multi-party multi-signature wallets (proposed), 47 referring to BIP-47 reusable payment codes (draft), 48 referring to hardware multisignature wallets (no BIP or standard proposal), 49 referring to BIP-49 P2WPKH-nested-in-P2SH / '3' SegWit addresses, or 84 referring to BIP-84 P2WPKH / 'bc1' native SegWit addresses. Some wallet services are supporting more than one (as in, they can display both legacy and SegWit addresses derived from the same seed phrase).
• Coin Type: This field indicates which cryptocurrency is being used in a multi-currency wallet. All coins, including testnet bitcoin, are assigned a constant number. For example, a derivation path for a Monero (XMR) account would be m/44'/128'. Note that if finalized, BIP-45 would designate this level as the 'Cosigner Index' instead.
• Account: This field, in a multi-account wallet, indicates the identity or collection of addresses, which allows users to segregate funds for different things (ex. savings, donations). Note that if finalized, BIP-45 would not include this field. If BIP-47 is finalized, this level would be designated as 'Identity', though it is equivalent to 'Account.'
• Change: This field, if the constant 0 is present, indicates "external chain" (regular) addresses; if the constant 1, indicates "internal chain" (change) addresses. Note that if finalized, BIP-47 would designate this level as space for the notification keys and ephemeral payment codes.
• Address Index: This field indicates the specific address number in a sequence, within an account.

Note how many of the sequential fields start at zero (0), like how the first / ground floor is level zero in the U.K. and Europe. If a user has a wallet that displays them, the derivation path sequence for a BIP-44 compliant bitcoin wallet, in which there is a second change address in the third account, would look like this: m/44'/0'/2'/1/1.

The meaning of "public" / unhardened versus hardened derivation, indicated in the fields by apostrophes, is explained here, here, and here.

---

Did we get it wrong? Just let us know, and this will be updated. :)

Want to contribute, make a Pull Request.