Wallets Recovery

A comprehensive guide to Bitcoin and cryptocurrency wallet recovery methods, derivation paths, and compatibility tables for securely regaining access to your digital assets

Explore Bitcoin Wallet Recovery Tables

Contents

Introduction to Bitcoin Wallet Recovery

Giving users their seed phrase is not enough.

While great advances have been made in Bitcoin wallet interoperability and cryptocurrency recovery methods, developers across the industry continue to build wallets that either:

  • Don't implement BIP standard(s) for proper seed recovery.
  • Implement a BIP standard, but inconsistently when compared with other cryptocurrency wallets.
  • 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 recovery guide and wallet compatibility chart 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 developers document external recovery. Users should not have to dig through the source code to figure out the Derivation Paths or Redeem Scripts.

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

This list is not an endorsement of the security or the quality of any of the wallets.

Bitcoin Wallet Recovery Compatibility Tables

These tables list Bitcoin wallets and their recovery compatibility features, derivation paths, and support for various BIP standards.

Loading wallet data...

Bitcoin Wallet Types for Recovery

  • 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. Paper wallets have a number of significant drawbacks, including encouraging address reuse, exposing keys to poorly secured networked devices (printer), and not handling change addresses. Paper wallets should not be confused with recovery seeds.
  • Non-deterministic Wallets

    randomly generate all private / public key pairs independent of each other. A 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 BIP11 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. 'Partially Signed Bitcoin Transactions' (PSBT) according to BIP174 (proposed), where unsigned or partially signed transactions are passed around to multiple signers or signing devices, may also be an option.

Bitcoin Wallet Derivation Paths Explained

In hierarchical deterministic wallets (BIP32), 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 BIP44, this hierarchy consists of five levels, in addition to the master extended private key ('xpriv') represented by m. Derivation paths for the master extended public key ('xpub') use M. Double-check what fields your wallet uses in our chart above, as BIP44 has been implemented inconsistently!

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

  • Purpose Level

    This field, which was added through BIP43, indicates which standard the derivation path follows. Possibilities include 0 or 44 referring to the default BIP44 P2PKH / '1' legacy addresses, 45 referring to BIP45 P2SH multi-party multi-signature wallets (proposed), 47 referring to BIP47 reusable payment codes (draft), 48 referring to hardware multisignature wallets (no BIP or standard proposal), 49 referring to BIP49 P2WPKH-nested-in-P2SH / '3' SegWit addresses, or 84 referring to BIP84 P2WPKH / 'bc1' native SegWit addresses. Some wallets support more than one (for example, many wallets now have both the legacy and wrapped or native SegWit address types).
  • Coin Type Level

    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 BIP45 would designate this level as the 'Cosigner Index' instead.
  • Account Level

    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 BIP45 would not include this field. BIP47 would designate this level as 'Identity', though it is equivalent to 'Account.'
  • Change Level

    This field, if the constant 0 is present, indicates "external chain" (regular) addresses; if the constant 1, indicates "internal chain" or change addresses. Note that BIP47 would designate this level for the notification keys and ephemeral payment codes.
  • Address Index Level

    This field indicates the specific address number in a sequence, within an account.

Note that the fields 'Account' and 'Address Index' start with zero (0). This is because they use zero-based numbering, just as the "ground floor" of buildings in the U.K. and Europe are considered level zero, rather than the first floor / level one in the United States.

Practical Example: A user has a BIP44 compliant bitcoin wallet, and wants to locate the second change address in their third account. The derivation path for the second change address in the third account would look like this: m/44'/0'/2'/1/1.

Another point of confusion may occur when wallets use the same derivation path for different script types. Especially if you are using any newer / more novel script types, wallets that have earmarked those paths for other scripts may cause errors during import. Example with Bread Wallet and Multibit mentioned here.

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

Frequently Asked Questions About Bitcoin Wallet Recovery

How to contribute to the Bitcoin Wallet Recovery project?

Make a Pull Request to update the walletsrecovery.json file.

What's the structure of the Bitcoin Wallet Recovery JSON file?

The walletsrecovery.json file contains all wallet data displayed on this site. It has two main sections:

  • categories: Array of wallet categories (Hardware Wallets, Software Wallets, etc.)
  • icons: Definitions for the status icons used in the wallet tables

Each wallet entry includes fields for status, name, URL, supported paths, and features.

How to test Bitcoin Wallet Recovery changes before submitting?

You can run the site locally to preview your changes:

Option 1 - Simple HTTP server

$ python -m http.server
Serving HTTP on :: port 8000 (http://[::]:8000/) ...

Option 2 - use Grip (Python)

$ pip install grip

$ grip
* Serving Flask app "grip.app" (lazy loading)
* Environment: production
  WARNING: This is a development server. Do not use it in a production deployment.
  Use a production WSGI server instead.
* Debug mode: off
* Running on http://localhost:6419/ (Press CTRL+C to quit)

Bitcoin Wallet Recovery Resources and Tools

Bitcoin Wallet Recovery Guides

  • "Compatibility Matrix: SegWit and Replace-by-Fee" by Bitcoin Optech ↗︎

Bitcoin Seed Recovery Tools

  • "Bitcoin Extended Public Key Converter" by Jameson Lopp ↗︎
  • "Mnemonic Code Converter" by Ian Coleman ↗︎
  • "HD-Wallet Scanner" by Alex Kaul ↗︎
  • "PSBT Toolkit" by Ben Carman ↗︎
  • [Released] Automated Scanner & BIP39 Recovery Feature for Electrum by Luke Childs ↗︎

Bitcoin Wallet Recovery Reference Information

  • "Bitcoin Information and Resources" by Jameson Lopp ↗︎
  • WeUseCoins FAQ ↗︎
  • "What types of mnemonic seeds are used in Bitcoin?" by Coldbit ↗︎
  • "FAQ Regarding Bitcoin Seeds" by 6102bitcoin ↗︎
  • "How BIP39 Seed Words Work" by jimbocoin ↗︎

Bitcoin Wallet Security Resources