I’ve previously written summaries of my qualms with the BIP39 standard in various chat rooms, preserving this one so I can just link to it in the future:
In general I think BIP39 mnemonics are sort of a distraction from developing better wallet backup systems. They introduce uncertainty into restoration such that a great wallet needs to derive and scan a huge number of addresses (paths, script types, optional passwords, etc.) across potentially many chains/networks, and you can never be sure if you’re finished. Even in terms of (re)storing private keys, the CashAddress format is a better backup standard than BIP39 as a degree of error correction can be safely automated (and that’s what I plan to use in my own software).
The BIP39 internationalization story is also a mess – you can’t convert between languages after wallet creation (e.g. if you created your wallet using the Spanish wordlist, you can’t get an English equivalent, etc.)
The backup “phrase” itself is easily confused for unimportant data – it doesn’t look like a secret you shouldn’t share. Normal humans do not expect to lose their life savings (or those of their tech-savvy late relative) by exposing 12 silly words in public
The attempted “plausible deniability” feature of the BIP39 spec is weak + expensive – $5 wrench attackers can still easily figure out that you have a hidden wallet, but in many cases you need to trust your squishy meat brain to remember a non-standard restore strategy + “strong password” which is almost certainly either 1) not strong enough to matter 2) recorded in a nearby password manager (and vulnerable to the $5 wrench attack), or 3) insufficiently backed up, i.e. its going to the grave with you. The BIP39 standard’s attempt at supporting “plausible deniability” has – with certainty – lost people far more money than it has saved. In practice, $5 wrench attacks are better thwarted at different layers (better privacy, time delays, multi-entity multisig, etc.)
Just about the only redeeming feature of BIP39 is that it makes memorizing some entropy a little easier for humans (e.g. fleeing an authoritarian regime). But even there, it would be far better to store keys in CashAddress format normally, and simply use another standard that is purpose-built for arbitrary entropy memorization. BIP39 doesn’t let you go from entropy to memorizable phrase, you have to start with the phrase + a bloated standard for converting it into bits. In practice, that even hurts its suitability for this use case, where you may have created your wallet during “happy times” and now you need to run… so you’ll need a different standard anyways to transfer your existing secrets into your brain (not to mention the recording of details beyond the private seed: script types, derivation paths, etc.)
Then there’s the problem with BIP39 being insufficient for almost anything but P2PKH… I wrote this on it last year: Libauth Wallet API Planning · GitHub
Ignore the code example here (this API in Libauth is continuing to evolve), but for details, see the paragraphs which follow “An HD key alone is almost never a sufficient backup for a wallet.”
Actually I’ll copy/paste:
While most single-entity wallets (P2PKH) are similar enough that they can be recovered from a “wallet backup” (e.g. a BIP39 mnemonic seed phrase) without knowing which wallet software produced the backup, backup strategies for practically all multi-entity wallets must account for shared, non-key material.
For example, a standard 2-of-3 P2SH wallets can be spent using 2 signatures from any of the 3 participants. However, transactions from a 2-of-3 P2SH wallet must also include the public keys of the other, non-signing participants to be valid. While this is typically not a problem, if signer 3 loses their private key and both other signers are forced to restore from a backup, if none of the participants have a record of signer 3’s public key, the funds are lost. While the participants have the 2 required private keys, they lack some critical information required to create transactions.
Existing wallets solve this problem by saving required non-key (shared) material to a server (managed by the wallet software vendor), saving it to the user’s account with a cloud backup service, or emailing it to the user. One or more of these strategies may also suit your use case.
On this ^ I have seen significant sums of money lost when otherwise very technically-competent users have lost public keys – not private keys – for a multisig wallet they are not able to recreate with the remaining M of N private keys.
Anyways, those are some of my qualms with BIP39 – I think it’s necessary for advanced wallets to be able to import BIP39 phrases/seeds/etc and scan as thoroughly as possible, but I definitely consider BIP39 to be legacy tech.
