public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Daniel Osemberg <daniosemberg@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [bitcoin-dev] Proposal discussion: BIP39 native-language display wordlists
Date: Sat, 13 Jun 2026 16:34:59 +0000	[thread overview]
Message-ID: <FOZaQw_eyfsyT45cgYr6VCHB79in1lybdP9HBbm-KkEQqqjwrNA5DHghqebO1nB3PhvpHyhmPoD5qlHi7KHygLzRqXU6u_B9LSm5K-H-YC8=@proton.me> (raw)
In-Reply-To: <e4ee1a70-aa70-4dbe-9f6c-27c26c5d17e0n@googlegroups.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 4502 bytes --]

Hey Daniel,

So basically this would allow a user to translate an english language BIP39 seed phrase to/from other languages, insured by the knowledge that it be converted back if needed for compatibility with english-only BIP39 wallets.

Neat idea. This is how BIP39 should've been done originally. Today, a BIP39 seed derives a different master key depending on what language is used to encode the source entropy, which was arguably a mistake because it breaks compatibility between implementations written for different locales, and incentivizes everyone to use seeds of the same language so that they're maximally compatible (which is exactly what happened). 

I worry your proposal here might cause confusion if introduced today though. Say you are given a french language 12-word seed phrase. Do you map the word indices to english and then run PBKDF2 with your algorithm? Or do you run PBKDF2 on the french version as specified in the original BIP39?

There would need to be a clear way for humans and software to distinguish between a "locale-mapped seed phrase" using your spec, and a legacy french BIP39 seed phrase, so they know how to derive the correct master key.

I guess one could argue that non-english BIP39 seeds are so uncommon that you could safely assume the former, but still it leaves open an unfortunate ambiguity which could lead to lost funds in some cases.

What do you think of this?

regards,
conduition
On Saturday, June 13th, 2026 at 12:04 PM, Daniel Osemberg <daniosemberg@gmail.com> wrote:

> 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.

-- 
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/FOZaQw_eyfsyT45cgYr6VCHB79in1lybdP9HBbm-KkEQqqjwrNA5DHghqebO1nB3PhvpHyhmPoD5qlHi7KHygLzRqXU6u_B9LSm5K-H-YC8%3D%40proton.me.

[-- Attachment #1.1.2.1: Type: text/html, Size: 6599 bytes --]

[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]

  reply	other threads:[~2026-06-13 16:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-08 14:24 [bitcoindev] [bitcoin-dev] Proposal discussion: BIP39 native-language display wordlists Daniel Osemberg
2026-06-13 16:34 ` 'conduition' via Bitcoin Development Mailing List [this message]
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='FOZaQw_eyfsyT45cgYr6VCHB79in1lybdP9HBbm-KkEQqqjwrNA5DHghqebO1nB3PhvpHyhmPoD5qlHi7KHygLzRqXU6u_B9LSm5K-H-YC8=@proton.me' \
    --to=bitcoindev@googlegroups.com \
    --cc=conduition@proton.me \
    --cc=daniosemberg@gmail.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