BIP-39: Add shortcomings section, drop comments headers. #2184

ajtowns commented at 7:07 AM on May 31, 2026: contributor

No description provided.

ajtowns force-pushed on May 31, 2026

ajtowns commented at 7:10 AM on May 31, 2026: contributor

cc @scgbckbone @prusnak ; ref #1677 (review)

in bip-0039.mediawiki:146 in 9444507916

 141 | +Some shortcomings have been identified with this proposal:
 142 | +
 143 | + * Generated seed depends on the wordlist used for the mnemonic. Because
 144 | +   the "mnemonic to seed" process uses the mnemonic sentence directly
 145 | +   rather than the original entropy, translating the mnemonic to a
 146 | +   different wordlist necessary creates a completely different seed.

prusnak commented at 8:49 AM on May 31, 2026:

Maybe I'd add that this shortcoming has been addressed by wallets by not-allowing generating seeds in other languages than English to maximize compatibility across wallets.

ajtowns commented at 3:13 AM on June 1, 2026:

Never attempting to translate to a different wordlist avoids the problem, sure, but it's still a shortcoming given the BIP includes 10 different wordlists. It's your doc, so happy to reword if you prefer, but I think "despite supporting different languages, you can't actually translate mnemonics" is a real shortcoming.

prusnak commented at 9:08 AM on June 1, 2026:

I was advocating for removing other wordlists for years but the friction to change the BIP used to be too high for me to still care; especially when the editors marked the BIP as "Unanimously Discouraged for implementation".

If there is now editors' will to edit the BIP, I would remove the other wordlists and encourage all wallets to generate only English mnemonics.

scgbckbone commented at 10:57 AM on June 1, 2026:

ACK on removing it all besides english

ajtowns commented at 1:50 PM on June 1, 2026:

Removing the wordlists seems like it would be annoying for anyone trying to be compatible with old mnemonics that were created with different languages. I've reworded to emphasise focussing on the english wordlist.

murchandamus commented at 10:16 PM on June 3, 2026:

I’m biased, but I think editors now are a bit more available. Given that there are a number of Bitcoin projects depending on the wordlists in other languages (especially in countries where English proficiency is perhaps less common), it seems to me that even with willing BIP Editors, there would probably be a few hurdles to clear, so that a removal of other lists from BIP39 wouldn’t break deployed software.

in bip-0039.mediawiki:151 in 9444507916 outdated

 146 | +   different wordlist necessary creates a completely different seed.
 147 | +
 148 | + * No versioning scheme. When originally introduced, there was no way to
 149 | +   distinguish the address format that should be used for a BIP-0039 key.
 150 | +   This is now largely mitigated by using descriptor wallets (BIP-0380)
 151 | +   in addition to a seed however.

prusnak commented at 8:50 AM on May 31, 2026:

I still do think this is a feature not bug, allowing the seed to be future proof which has proven to be very useful.

ajtowns commented at 3:16 AM on June 1, 2026:

Any suggestion for rewording it?

jonatack added the label Proposed BIP modification on May 31, 2026

jonatack added the label Pending acceptance on May 31, 2026

scgbckbone commented at 10:56 AM on June 1, 2026: contributor

ACK

That said, I do not think the new Shortcomings section is very useful as written; it is also incomplete (check rust-bitcoin BIP39 discussion).

Enumerating shortcomings directly in the BIP feels unusual; I do not think many BIPs include this kind of retrospective critique of themselves. Framed this way, it also raises the opposite question: should the BIP also include a section on the practical interoperability benefits BIP39 has provided across many wallets over the years? I would call that section Great Success.

So overall, I support removing Comments-Summary; this was long overdue. I do not feel strongly about whether the Shortcomings section is added or not, since this BIP has long contained language that does not really match how it is used in practice.

ajtowns force-pushed on Jun 1, 2026

ajtowns commented at 1:58 PM on June 1, 2026: contributor

That said, I do not think the new Shortcomings section is very useful as written; it is also incomplete (check rust-bitcoin BIP39 discussion).

Added some things from there.

Enumerating shortcomings directly in the BIP feels unusual; I do not think many BIPs include this kind of retrospective critique of themselves.

It definitely is unusual (cf this post) but maybe it should be less unusual? The "unanimously discourage" / "supported almost everywhere" dichotomy with this BIP always bugged me, so it was the first test case that came to mind.

Framed this way, it also raises the opposite question: should the BIP also include a section on the practical interoperability benefits BIP39 has provided across many wallets over the years? I would call that section Great Success.

There is a pre-existing "Post mortem" in the form of bip 50 which could potentially work; but "why my bip was awesome, by me, the author of an awesome bip" doesn't sound like something that'll be useful in general to me...

ajtowns force-pushed on Jun 1, 2026

in bip-0039.mediawiki:143 in f36c8d04aa

 135 | @@ -138,6 +136,22 @@ Also see https://github.com/bip32JP/bip32JP.github.io/blob/master/test_JP_BIP39.
 136 |  
 137 |  (Japanese wordlist test with heavily normalized symbols as passphrase)
 138 |  
 139 | +==Shortcomings==
 140 | +
 141 | +Some shortcomings have been identified with this proposal:
 142 | +
 143 | +* Generated seed depends on the wordlist that was used for the mnemonic. Because the "mnemonic to seed" process uses the mnemonic sentence directly rather than the original entropy, translating the mnemonic to a different wordlist necessary creates a completely different seed.  This is not an issue if you only support the English wordlist, as recommended above.

danielabrozzoni commented at 12:58 PM on June 2, 2026:

nit: Here and a couple of lines below, there are double spaces after periods. Are those intentional?

completely different seed. This is not an issue
for a BIP-0039 key. This is now largely mitigated

jonatack commented at 2:58 PM on June 4, 2026:

https://www.grammarly.com/blog/punctuation-capitalization/spaces-after-period/

tldr: 2 spaces was previously the standard, this evolved to become 1 space, and it's now it's personal preference for some, outdated/incorrect for (probably most) others. (I don't mind either way.)

jonatack commented at 2:59 PM on June 4, 2026:

* Generated seed depends on the wordlist that was used for the mnemonic. Because the "mnemonic to seed" process uses the mnemonic sentence directly rather than the original entropy, translating the mnemonic to a different wordlist necessarily creates a completely different seed.  This is not an issue if you only support the English wordlist, as recommended above.

ajtowns commented at 2:50 PM on June 5, 2026:

For anything I write, it's mostly from running fmt over lines to wrap them to <80 chars per line and not noticing.

danielabrozzoni commented at 1:18 PM on June 2, 2026: member

I think it's slightly cleaner to have shortcomings in the BIP itself rather than having comments in the wiki, but I don't have a strong opinion either way.

While doing some research on why Core doesn't implement BIP39 I found this stackexchange answer from Ava:

Also, more generally, many Bitcoin Core contributors don't consider BIP 39 to be secure. It uses PBKDF2 which is generally regarded to be a fairly weak KDF so it isn't considered to be good for the secure storage of all of your Bitcoin. Some software (such as Electrum) use their own mnemonic algorithm because of this weakness in BIP 39.

Should this be in the shortcomings as well?

murchandamus commented at 10:21 PM on June 3, 2026: member

There is a pre-existing "Post mortem" in the form of bip 50 which could potentially work; but "why my bip was awesome, by me, the author of an awesome bip" doesn't sound like something that'll be useful in general to me...

I think we could consider an informational BIP that gathers issues, learned lessons, and best practices regarding an idea proposed previously by another BIP.

in bip-0039.mediawiki:153 in f36c8d04aa

 148 | +
 149 | +* No versioning scheme. When originally introduced, there was no way to distinguish the address format that should be used for a BIP-0039 key.  This is now largely mitigated by use of descriptor wallets (BIP-0380) in addition to a seed however.
 150 | +
 151 | +New deployments should consider using the
 152 | +[https://github.com/satoshilabs/slips/blob/master/slip-0039.md SLIP-0039]
 153 | +scheme instead.

jonatack commented at 3:02 PM on June 4, 2026:

GitHub rich diff seems to render this as 3 separate lines instead of one.

jonatack commented at 3:09 PM on June 4, 2026: member

Approach ACK f36c8d04aa62d612504d813e632449924819107d. Bringing this information into the BIP as done here seems a helpful improvement. No strong opinion on creating an informational retrospective BIP, apart from it being perhaps less convenient for readers.

BIP-39: Add shortcomings section, drop comments headers. 026964125d

ajtowns force-pushed on Jun 5, 2026

ajtowns commented at 2:58 PM on June 5, 2026: contributor

I don't really think the mnemonic to seed function not being very secure is much of a shortcoming -- you can't make that too slow, because it has to be performed on signing devices which might themselves be slow, and you should have high entropy when generating the mnemonic in the first place anyway.

Updated for wording/layout nits.

jonatack requested review from prusnak on Jun 5, 2026

jonatack requested review from danielabrozzoni on Jun 5, 2026

jonatack requested review from scgbckbone on Jun 5, 2026

katesalazar commented at 8:37 PM on June 5, 2026: contributor

Concept ACK Approach NAK

I think comments of this BIP should be included in the BIPS repository, but I think it's not tidy having them inside the BIP itself.

I'm not finding 'shortcomings' as a standard in BIP 3, so I'm unsure what is really happening here.

jonatack commented at 12:03 AM on June 7, 2026: member

ACK 026964125d282ba80004b4a7ec1d489150b86706

Pending feedback or sign-off by the BIP authors.

danielabrozzoni approved

danielabrozzoni commented at 4:40 PM on June 9, 2026: member

I don't really think the mnemonic to seed function not being very secure is much of a shortcoming...

Understood, thanks for explaining!

Looks good to me, ACK 026964125d282ba80004b4a7ec1d489150b86706

jonatack commented at 8:56 PM on June 23, 2026: member

@osem23 if the above is an LLM-generated comment, as it looks to be, please don't do that.

prusnak commented at 8:11 AM on June 24, 2026: contributor

NACK to changing the standard.

jonatack commented at 4:14 PM on June 24, 2026: member

If the comment was too long or too polished @osem23 it is too verbose and pedantic and LLM output wastes the community's time. Please write in your own words. If English is a challenge, write in the language you are most comfortable with, and translate it to English using google translate or another translation service. I have hidden the last two comments as low quality (people can still see them if they click once).

jonatack commented at 4:17 PM on June 24, 2026: member

NACK to changing the standard. @prusnak just to be sure, is that a NACK on this change?

murchandamus commented at 10:45 PM on June 24, 2026: member

I don’t see comments by osem23. Have they since been deleted?

jonatack commented at 10:56 PM on June 24, 2026: member

They appear to have been self-deleted.

prusnak commented at 11:22 PM on June 24, 2026: contributor

@prusnak just to be sure, is that a NACK on this change?

Nope. It was NACK to osem23 suggestions.

ajtowns commented at 12:36 PM on July 8, 2026: contributor

@scgbckbone @prusnak want to ack / nack this PR, or give me some concrete suggestions for the changes you'd like to see? Otherwise, I plan on closing this PR next week.

in bip-0039.mediawiki:151 in 026964125d

 146 | +
 147 | +* The checksum is short. This means it only gives modest odds of catching random errors (1-in-256 errors will be missed). It is also not able to provide any assistance in correcting errors.
 148 | +
 149 | +* No versioning scheme. When originally introduced, there was no way to distinguish the address format that should be used for a BIP-0039 key. This is now largely mitigated by use of descriptor wallets (BIP-0380) in addition to a seed however.
 150 | +
 151 | +New deployments should consider using the [https://github.com/satoshilabs/slips/blob/master/slip-0039.md SLIP-0039] scheme instead.

scgbckbone commented at 1:23 PM on July 8, 2026:

does not belong here

ajtowns commented at 1:07 AM on July 9, 2026:

Can you clarify? Do you mean "the SLIP-39 recommendation shouldn't be in a shortcomings section" or shouldn't be recommended at all, or that the versioning scheme/descriptors comment shouldn't be there?

prusnak commented at 2:07 PM on July 8, 2026: contributor

ACK 026964125d282ba80004b4a7ec1d489150b86706