From: Daniel Osemberg <daniosemberg@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] [bitcoin-dev] Proposal discussion: BIP39 native-language display wordlists
Date: Mon, 8 Jun 2026 07:24:06 -0700 (PDT) [thread overview]
Message-ID: <e4ee1a70-aa70-4dbe-9f6c-27c26c5d17e0n@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2357 bytes --]
Hi list,
I would like to ask for early feedback on an idea before attempting any
formal BIP submission.
The proposal is a display/input layer for BIP39 recovery phrases in
additional native languages.
The important constraint is that this does not change the BIP39
cryptographic flow. The canonical mnemonic remains the existing BIP39
English wordlist, and PBKDF2 is still performed on the canonical English
form.
The native-language lists are index-paired to the English BIP39 wordlist.
In other words, each native word maps to the same 0-2047 index as the
corresponding English BIP39 word. Wallets could display or accept the
native-language form for UX purposes, but internally normalize back to the
canonical English mnemonic before seed generation.
Motivation:
Many users around the world are asked to back up and restore Bitcoin
wallets using English recovery words, even when English is not their native
language. This creates UX risk, spelling mistakes, misunderstanding, and
lower confidence during backup and recovery.
This proposal tries to improve multilingual recovery UX while keeping
compatibility with existing BIP39 behavior.
This is not:
A new seed scheme
A replacement for BIP39
A new cryptographic standard
A change to PBKDF2 input
A wallet-specific format
It is intended as a display/input convention for wallets that want to
support native-language recovery UX while preserving canonical BIP39
compatibility.
A draft implementation and wordlists are here:
https://github.com/osem23/bip39-wordlists-tzur
I would appreciate feedback on:
Whether this idea is appropriate for the BIP process at all
Whether it should be considered informational rather than standards-track
Whether the index-paired approach creates hidden risks
Whether wallet developers see practical value in this
How native-speaker review and normalization rules should be handled
Whether there is prior work I should study before continuing
Thank you,
Daniel
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e4ee1a70-aa70-4dbe-9f6c-27c26c5d17e0n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2796 bytes --]
next reply other threads:[~2026-06-13 16:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 14:24 Daniel Osemberg [this message]
2026-06-13 16:34 ` [bitcoindev] [bitcoin-dev] Proposal discussion: BIP39 native-language display wordlists 'conduition' via Bitcoin Development Mailing List
2026-06-13 16:39 ` Daniel Osemberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e4ee1a70-aa70-4dbe-9f6c-27c26c5d17e0n@googlegroups.com \
--to=daniosemberg@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox