BIP Draft: Multilingual mnemonic display and input conventions

[osem23]

This adds a Specification BIP draft, "Multilingual mnemonic display and input rules" (resubmission of the previously-closed #2192, updated).

A display wordlist is a 2048-entry list in a target language, index-parallel to the canonical English BIP-39 wordlist. PBKDF2 runs only on the canonical English mnemonic; native-language renderings are a display and input layer with no new cryptographic surface, and every seed produced under the convention is restorable in any BIP-39 wallet via its English form.

The preamble follows the BIP 3 format (Authors, Assigned, Discussion; no Discussions-To/Comments-*). I have not self-assigned a BIP number.

Discussion

• bitcoin-dev (2026-06-13): https://groups.google.com/g/bitcoindev/c/Rwo7P5pTA0c
• Delving Bitcoin (2026-06-23): https://delvingbitcoin.org/t/bip39-native-language-display-wordlists-mapped-to-canonical-english/2637

Reference implementation (MIT): https://github.com/osem23/bip39-wordlists-tzur — 30 index-paired display wordlists with bidirectional mappings, the 10 canonical BIP-39 wordlists preserved byte-for-byte for spec comparison, a reference validator enforcing every MUST clause, reference decoders in Python, JavaScript, and Swift producing byte-identical seeds, and per-language conformance test vectors across the five BIP-39 entropy lengths.

Shipped in production by the TZUR Wallet suite (iPhone and Windows).

License: BSD-2-Clause (document), MIT (reference implementation).

[danielabrozzoni]

Only gave a first very quick pass, will do another one soon :)

[danielabrozzoni]

The preamble should contain

Requires: 39

[osem23]

Done, added Requires: 39 to the preamble.

[danielabrozzoni]

Unfortunately title should be at most 50 characters, and this is 51 😅

[osem23]

Fixed. It's now "Multilingual mnemonic display and input rules" (45 chars).

[danielabrozzoni]

I think this is a specification BIP. From BIP3:

bips/bip-0003.md

Lines 175 to 185 in 861e235

	### BIP Types
	* A **Specification BIP** defines a set of technical rules describing a new feature or affecting the interoperability of implementations. The
	distinguishing characteristic of a Specification BIP is that it can be implemented, and implementations can be compliant with
	it. Specification BIPs must have a Specification section, must have a Backward Compatibility section (if incompatibilities are introduced), and can only be advanced to Complete after they contain or refer to a reference implementation and test vectors.
	* An **Informational BIP** describes a Bitcoin design issue, or provides general guidelines or other information to the
	Bitcoin community.
	* A **Process BIP** describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process
	BIPs are like Specification BIPs, but apply to topics other than the Bitcoin protocol and Bitcoin implementations.
	They often require community consensus and are typically binding for the corresponding process. Examples include
	procedures, guidelines, and changes to decision-making processes such as the BIP process.

[osem23]

Agreed, set to Type: Specification.

[jonatack]

This draft appears to be mostly AI generated?

Edit: am looking at the document history in https://github.com/osem23/bip39-wordlists-tzur/commits/main/docs/BIP-multilingual-mnemonics.md

[osem23]

Yes, I used AI as a writing tool, and I'm not going to pretend otherwise. I'm proud of it.
But "AI generated" isn't really the question for a spec. The question is whether it's correct and implementable. I stand
behind every line and I understand every line. If any specific clause reads as wrong, vague, or unnecessary, point at it and I'll fix or defend it. That's the feedback I can actually use, and this spec is built to be checked rather than trusted.

[osem23]

Only gave a first very quick pass, will do another one soon :)

Thanks for the pass, all three are good catches.

[murchandamus]

I gave this a quick first read. I like the idea of normalizing to the English wordlist under the hood as it directly mitigates one of the worst issues with BIP39’s portability.

That said, the approach to the additional languages feels unappealing to me: producing initial lists by mechanically translating the English word list is bound to cause a number of issues such as the described concerns with terms composed of multiple words and diacritics, which would persist especially for wordlists that don’t get review before publication. As such wordlists would have room for improvement, it implies that there would soon be multiple wordlists for some languages which would cause even more confusion on top of BIP39 language lists vs display language lists. It seems worthwhile to try and pursue more stable higher quality lists from the get-go, so that more languages would only ever have a single wordlist to converge on.

Given the numerous pull requests we’ve had to the BIPs repository where people tried to add more wordlists to BIP39, I would like to suggest only shipping a framework for more languages to be added instead of shipping with placeholder language lists, and to leave the creation of wordlists to the respective language communities.

Since you are creating a new mnemonic scheme that is essentially a breaking change to BIP39 for every language but English, I would alternatively propose that you go further and create a new scheme that is not backwards compatible with BIP39 but instead addresses all issues with BIP39:

• use the indices of the words to generate the seed instead of hashing text
• encode a version
• use a better checksum
• if possible encode information about the output script pattern used
• maybe create a generic encoding of data with words that then is used to encode a seed in a second BIP

Preferably such a scheme would also use a different number of words so that it cannot be mixed up with BIP39.

[murchandamus]

Was that supposed to be a link to the Display wordlist section?

[osem23]

Yes, it points to the Display wordlist requirements section. I use the §section style throughout instead of anchor links. Happy to switch these to real anchors if the editors prefer.

[murchandamus]

Maybe you are implying that already, but would it be possible to enforce at word list creation time that no word matches another per list if diacritics were stripped, case was folded or similar? Has that been done for the proposed lists?

E.g., this was done for the French wordlist, where "special French characters "é-è" are considered equal to "e", for example "museau" and "musée" can not be together".

[osem23]

Right now I enforce this at input time, not at construction time the way the French list did. §Input parsing MUST 3: if a lossy fold (diacritic strip, case fold) maps a token to more than one entry, the wallet must reject and ask the user, never auto-pick. The validator already reports per-language collision counts under those folds.

I didn't make it a construction-time MUST because a mechanically-seeded list can't always satisfy it without curation, which is the quality tension you raise in your top comment. I can add it as a construction-time SHOULD with the per-list collision report surfaced, and make it a MUST for any list that claims a curated tier. The input-time disambiguation MUST keeps wallets safe in the meantime.

[murchandamus]

I was wondering how so many languages had been created at inception. So the wordlists were created by translating the English words to the target languages?

[osem23]

Yes. Generated by translation, then validated rather than trusted: structural checks, back-translation and forward-translation each with an LLM verdict, multilingual sentence-embedding similarity, Wiktionary cross-reference, and a blind LLM top-8 pass. Process and per-language results are in docs/CONSTRUCTION.md and docs/V2_VALIDATION.md. It isn't a substitute for native-speaker review, which is why the lists are explicitly supersedable.

[murchandamus]

I don’t follow here. If people had started using the original native words to record their backup, changing the poorly-chosen word would invalidate their backup.

[osem23]

You're right, that line was wrong and I removed it (6608dcb). Published lists are frozen. A correction is a new versioned list, never a mutation of a published one, so an existing backup is never invalidated: it resolves against the exact version that produced it, pinned by SHA-256, with the canonical English mnemonic as the safety net.

[murchandamus]

If the users have to end up recording both the display-words and the English words, how does this solve the issues that non-English speakers are significantly more likely to make mistakes recording the English words?

[osem23]

MUST 1 is an availability obligation on the wallet, not a requirement to record a second English copy. A user can back up in the display language only, and then there is no English transcription step and therefore no English transcription error, which is exactly the failure this removes. English stays viewable and exportable as the portability guarantee and safety net, surfaced and labeled. I clarified this in the text (6608dcb).

[murchandamus]

I was somewhat excited by your idea at first, but this approach seems to undermine a big portion of the potential utility of this BIP. If the wordlists are not intended to be stable, I am not sure I see the point.

[osem23]

Agreed, and they are stable. The registry pins v1.0 with the SHA-256 as the load-bearing identifier; lists are frozen per version and never mutated in place. The Rationale line that implied otherwise was the bug, and I fixed it (6608dcb). Stability is the point, the same way it is for BIP-39 itself.

[jonatack]

Yes, I used AI as a writing tool, and I'm not going to pretend otherwise. I'm proud of it. But "AI generated" isn't really the question for a spec. The question is whether it's correct and implementable. I stand behind every line and I understand every line. If any specific clause reads as wrong, vague, or unnecessary, point at it and I'll fix or defend it. That's the feedback I can actually use, and this spec is built to be checked rather than trusted.

Thank you for clarifying. My goal isn't to stigmatize and I'm still trying to figure out the best way to handle LLM-generated submissions. I think it's mildly preferable to state upfront to readers and reviewers when the content is mostly LLM output, and to what extent, out of respect for their time. Some may indeed not see any issue. Others may not wish to spend scarce review cycles doing human review of LLM output, or may prefer to delegate review of LLM output out to LLMs, because human review is a scarce and expensive resource. The idea is to respect the community's time and help them allocate it well.

[osem23]

Thanks for the careful read. We agree on the core: normalizing to English under the hood is the win.

On mechanical translation and "multiple lists per language", I think we're closer than it reads. The BIP ships no wordlists into this repo and blesses none as canonical. It specifies the framework: construction, mapping, and input rules, plus a conformance profile where every wordlist-level MUST maps to an executable check. The 30 lists live in a separate registry as a bootstrap corpus, supersedable by native-speaker review. I made that explicit in 6608dcb. So "ship a framework, leave creation to the communities" is the intended end state, not a conflict with it.

On why I shipped a starting corpus and not just an empty framework: it expands practical BIP-39 coverage from 10 languages to ~30 today. The 10 canonical lists cover roughly a third of people by native language. The other two thirds, about 5 billion native speakers, have no list at all. A working corpus, even one communities later refine, lets wallets onboard those users now instead of waiting for 20 separate community list efforts to each reach completion. That reach, opening Bitcoin self-custody to people in their own language, is the whole point of the proposal.

On "multiple lists cause confusion": that's what the (language, version, SHA-256) triple is for. Two lists for one language are two versions, and each backup names the one that produced it. BIP-39 today carries no version identifier at all, so this is strictly more robust, not less.

On stability: I'm committing to immutability-by-version. A published list is frozen, corrections are new versions, no existing backup is invalidated. (You caught a Rationale line that said the opposite; fixed in 6608dcb.)

On going further to a new, non-backwards-compatible scheme (indices to seed, version byte, stronger checksum, script-type encoding, distinct word count): I think that's worth doing, but it's a BIP-39 successor and a different document. This proposal's entire value is zero new cryptographic surface and universal restore in the installed base today, including English-only wallets. Folding a successor in forfeits exactly that, and helps none of those ~5 billion speakers now. I'd support a successor effort on its own track and would contribute, but I'd keep the two separate so this one stays deployable.

[osem23]

This is not something I originally set out to work on.

My main work is BlockSight.Live, a free Bitcoin explorer. I have worked in the Bitcoin ATM industry in Israel for the last 3+ years and have seen thousands of regular users interact with Bitcoin.

My main goal has always been to build useful tools for Bitcoiners.

While building a Bitcoin wallet with the native explorer integrated into it, I encountered the BIP39 language issue directly, and it bothered me.

Users in Israel still generally have to write down their seed words in English. For many people, that is not natural, and I think it creates a real backup and recovery risk.

I am not trying to change BIP39 itself.

I am trying to explore whether this can be made better while keeping English BIP39 as the canonical base.