Update the website link of the github repo to https://walletsrecovery.org/

There're two versions of Electrum seed system, the old one is a reversible encoding, the new one (Electrum2.0) is a variant of BIP39, which is one-way hashed to derive BIP32 entropy (thus the "root" master key/node).

Both are not compatible with BIP39.

I'm not familiar with pre-Electrum2.0 seed (the old Electrum seed). Maybe you can point me to the docs or the source code.

Here I'm describing Electrum2.0 seed only.

It seems that the offical documentation only mentions how the version bits (which is used as something like checksum as well) are defined. I don't see how the seed phrase can then derive into private keys (and addresses). Maybe I just haven't find it?

https://electrum.readthedocs.io/en/latest/seedphrase.html

In the source code, I find 4 types of the version bits, rather than 3 types described in the documentation:

https://github.com/spesmilo/electrum/blob/fdaf6e775cdbe461a8466d1d7e46360c8a90e4d7/electrum/version.py#L6

The BIP32 entropy is derived from the seed (mnemonic) phrase by 2048-round PBKDF2, using HMAC-SHA512, which is almostly the same to BIP39, the difference is that Electrum2.0 uses the string "electrum" + passphrase, while BIP39 uses the string "mnemonic" + passphrase:

https://github.com/spesmilo/electrum/blob/64a94e95225bdd62fd5aa8a6dec5ac27e03b9dae/electrum/mnemonic.py#L159

Pay attention that Electrum once had a bug (Electrum issue No.4566) around normalization of BIP39 passphrase, it once removed more whitespaces (like, deleting one whitespace from two consecutive whitespaces). I'm not sure how Electrum would treat passphrase of Electrum2.0 seed phrases.

I once encountered a lot of posts describing that Electrum2.0 uses derivation paths different than BIP44/49/84, which can be confirmed in the source code as well:

https://github.com/spesmilo/electrum/blob/9d0bb295e6f55a2bff9f5b6770fa744c16af6e8a/electrum/keystore.py#L975
https://github.com/spesmilo/electrum/blob/6058829870fde0ef17b2e08a567110ecc381ab94/electrum/plugins/trustedcoin/trustedcoin.py#L572

• (According to comments in the source code) pre-2.7 2fa seed phrase is typically 24-25 words. However, due to a bug (electrum issue No,3611), there's a (almostly negligible) probability of 2^(-59) for pre-2.7 2fa seed phrase to be less than 20 words.

• Because it's a P2(W)SH wrapped multisig, knowing 2 private keys (BIP32 xprv) in such 2of3 multisig setup is still not enough to spend the funds, because the last 1 public key (BIP32 xpub) must be also known to construct the corresponding redeem script. Such public key can be automatically retrieved from TrustedCoins servers, if the user doesn't have it.

DISCLAIMER: although I have tried my best to make the info above accurate, I can't guarantee its accuracy.

First of all, (as a reply of #129 (comment) as well) I think this website/project is intended to show how to recover funds from a wallet listed in the table, isn't it?

Some wallets like Bitcoin Core and Bitcoin Wallet app (maintained by Andreas Schildbach) don't have any mnemonic at all.

Some wallets like Electrum and LND have mnemonic schemes which are incompatible with BIP39.

For these cases, I'm afraid to say the info provided on this site is not quite clear in this aspect - "is this wallet itself recoverable, and how? Oh, not so clear..."

Therefore, my bold suggestion is adding a new "Mnemonic" column to represent such info.

Just like Electrum, Bitcoin Core and LND, these three wallets could be represented like (some text should be hyperlinks but I haven't set them):

Consider removing unused "exploit" column and replacing the words in the PSBT support column with icons that use less width.

It would be great if this site could also host a machine readable format (probably JSON) that allows recovery software to read information about wallets, paths and script types and uses the data to search the tree produced by a seed or xpub.

I'm working on such a recovery tool and would love to have a well managed location for that data that can be updated collaboratively.

For example:

{
wallets_recovery: [
 "ColdCard Mk1": [{ "path" : "m/44'/0'/0'", "script": "p2pkh", "passphrase": "optional", "psbt": true},
                             { "path" : "m/84'/0'/0'", ... etc
]
}

After a few years all these links to external docs will be 404 (link rot).
Especially for wallets that have their best days behind them.

The solution is to save that info to Web Archive and link to that instead.

Github Pages has an option for forcing HTTPS which will redirect clients that request http://walletsrecovery.org to https://walletsrecovery.org. See more here.

This prevents walletsrecovery.org from being trivially MITM'ed, which would allow an attacker to provide incorrect wallet recovery information which may give them access to a user's seed.

In the Ian Coleman tool, a derivation path of m/0'/0 is required in the BIP32 Derivation Path field but in Electrum, a m/0′ derivation path is used.

Users need to be clear which path to use if they are going to recover their wallets correctly.

"BIP32 non 44 Compatible" is still not clear enough.

• SW https://twitter.com/samouraidev/status/1193514580816871427?s=21
• green, Coinomi, mycelium
• fullynoded https://twitter.com/fullynoded/status/1193525236689321984?s=21

Doesn't work with wide tables.

add primer for bech32 addresses.

It looks fine on the readme.md on Github

...but on the walletsrecovery.org page, it isn't rendering. Same for mobile too.

When somebody has issues with Wallet X, he usually wants to find a wallet Y that can restore his funds. It would be awesome if the list could be filtered by standards and derivation paths.

Cardano Wallets have a history of different wallet master key derivation implementations.

• https://github.com/cardano-foundation/CIPs/blob/master/CIP-0003/CIP-0003.md#history

The main Cardano software wallets (Daedalus and Yoroi) appear to implement a key derivation method called Icarus.

Two hardware wallets implement a different key derivation method (making a BIP39 recovery seed from a software wallet essentially incompatible)

• Ledger Cardano master key generation
• Icarus-Trezor - Trezor historically has implemented a BIP39 24 word master key that differs from the standard Icarus derivation
  • Trezor fixed in a future firmware - trezor/trezor-firmware#1388

I don't know enough about BIP39 key derivation methods to properly document the Cardano software wallet compatibilities, but I think it would be helpful to add to this project as it's an instance of incompatibility of wallet recovery methods.

Thoughts for this? For Samourai and Wasabi, the passphrase is mandatory. If this isn't supported on other wallets, it should be highlighted.

template https://github.com/nvk/wallets-recovery/blob/master/wallets/template.md

m/84'/0'/0' - Coldcard really represents m/84'/0'/0'/0/n & m/84'/0'/0'/1/n (Paths for native segwit account 0). Should this be m/84'/0'/n'/0/n & m/84'/0'/n'/1/n (any account number).

m/44/0'/X' - Copay. Uses an X, we should normalise to an n, does this really mean m/44/0'/n'/0/n & m/44/0'/n'/1/n ?

m/45'/0'/0'/0/0 - Unchained Capital. Is this a single address path (no n)

@nvk ?

We need a status option for wallets that have had major security concerns and/or may misrepresent Bitcoin/BTC for other forks. I'd like to still list them as ppl may need to recover from it.

i.e.
✅|Blockchain.com[↗︎](https://www.blockchain.com/en/wallet)|m/44'/0'/n'|[Docs](https://support.blockchain.com/hc/en-us/articles/115001298143-Your-Recovery-Phrase-The-Failsafe), [xPub](https://support.blockchain.com/hc/en-us/articles/207746403-Wallets-Addresses)

In order to recover the user needs to try a few address types (if unknown).
It would be great to have all this info already available.
For starters we can use this matrix

I'll create a PR if @nvk OKs it.

• Armoury
• Hexa wallet
• Crypto Advanced Spectr
• Lilly Wallet
• ...

Blixt is a pure LND aezeed wallet
m/84/0/0 derivation path
https://github.com/hsjoberg/blixt-wallet
https://blixtwallet.com

As Shinobi said 😂😂 :

I could add a PR if you want, but I don't want to meddle into your nice page.

I have been trying to restore electrum wallet in Wasabi but I did not succeed.
What are all the information needed to do that.

Hi,

could you please update the details for the BitBox02? Thanks :)
Guide: https://guides.shiftcrypto.ch/bitbox02/advanced/backup-recovery/
Tool: https://github.com/digitalbitbox/bitbox02-backup-recovery

Related commit (Bitcoin Core issue No.9294): bitcoin/bitcoin@f34cdcb

I didn't see such feature noticeably described in the release note of Bitcoin Core 0.15.0, it was just listed in the "wallet" section as a trivial commit history entry: https://bitcoincore.org/en/releases/0.15.0/

In the release note of Bitcoin Core 0.17.0, the -upgradewallet feature is described as being able to upgrade an old "non-split" wallet.dat into a new "split" one: https://bitcoincore.org/en/releases/0.17.0/

By the way, it worth noting that Bitcoin Core uses hardened-derivation on each private keys (addresses, either receiving or change), which might be incompatible with other wallets (like Electrum). However, tools like Ian Coleman's BIP39 Mnemonic Code Converter is compatible with this.

Besides, as we all know, Bitcoin Core currently doesn't support any mnemonic (including BIP39) at all. It's also tricky to deal with wallet.dat (which is a Berkeley db4.8 database) without Bitcoin Core (although Bitcoin Core has always supported such db4.8 wallet.dat).

Also, although dumpwallet RPC command of Bitcoin Core can generate a text file of contents of wallet.dat, IIRC it won't include old (no longer used) HD seeds - there could be more than one HD seed inside wallet.dat actually. (related issue discussion thread: bitcoin/bitcoin#17748 (comment) )

DISCLAIMER: although I have tried my best to make the info above accurate, I can't guarantee its accuracy.

I think the Wallets Recovery [DRAFT] button should be the left most button.

A

Link

Not sure if you want this on the extended section or the main table but some wallets, especially the mobile ones, require connectivity to a central server to even gain access to the wallet and individual private keys. I think this is worth including as sweeping private keys from a defunct wallet can be an easy way for users to get access to their funds. Feedback welcome.

Hi, could you please update the following rows, thanks.

BitBox01:

Derivation: m/44'|49'|84'/0'/0'
BIP-39 Pass: required
PSBT: not supported
Docs: https://guides.shiftcrypto.ch/docs/BitBox01

BitBox02:

Derivation: m/44'|49'|84'/0'/0'
BIP-39 Pass: optional
PSBT: not supported
Docs: https://guides.shiftcrypto.ch/docs/BitBox02

https://help.blockstream.com/hc/en-us/articles/900002953926-What-standard-does-AQUA-use-for-its-recovery-phrase-

Wallet Descriptors solves a lot of the problems in future recoverability.

Ideally we would store the descriptors templates for each wallet in the documentation ie/wallets/casa.md

I suggest to add Ellipal, D'CENT and Safepal hardware wallets.

They all use m/44'/0'/0' for btc legacy address.
I don't know about the segwit address though. They all show different addresses so I guess they use a different derivation path.