From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Jun 2026 09:46:37 -0700 Received: from mail-ot1-f61.google.com ([209.85.210.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wYRVC-0003HK-T0 for bitcoindev@gnusha.org; Sat, 13 Jun 2026 09:46:36 -0700 Received: by mail-ot1-f61.google.com with SMTP id 46e09a7af769-7e6f0539a88sf702031a34.2 for ; Sat, 13 Jun 2026 09:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781369182; x=1781973982; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=K8rLoyOXFw7VUJEKmruhMJQ/B4T5IQX0xF59VROp3nw=; b=xMaBuGdXntrUDXOM9861ouDDQ4UUDlfJEk1fCg+feYdzoWW7PuU7+ewy3Y8f6ySPA9 uQipW/DIgzVlwUkM0b+T+BgxV5Lmyjq8Quz56S247zCL3dSTGdWgH2FHt2B/ClYyFym8 lVgmrYgUG2jPWeqGLs+NX074PW7z4qh2xduWip/konJBy+3ZIDIAlY6KA/Wx/thDplb8 4G4fYrQdlBnUm2nTLK+2o3zu9C5ILxwuiZZ++25rndnWOv+FE9HGNmWpo4Zt7Wu+wLG3 Vd+WdCrtmDKj6w4CGc5etPH8Ks7mhf/B8gFQQEqNKDnr9ct7SyODyW+3dvt7VV8BFiqi kBnw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781369182; x=1781973982; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=K8rLoyOXFw7VUJEKmruhMJQ/B4T5IQX0xF59VROp3nw=; b=WqsE8I8FKKwGgDiGS60jWCWS/m0a6dXcd4fWPyCzXAPchuUC3H8khxDekCjCExS0nf woH5dlTOtPHFaQm2PxPHgM5RHW7b9ejT+EwN6kKOVJ0HNn3MwJDdXb9tQudzC4rsdpf5 5CSDmBvM8U7qLEphaBckeexybQ76VsbIWDy+urVuyitgjW0pQKsbOKYgAqbIyeauDI6C 9gK7/TH2UBsdF5+gCopcN4sNd+ICVS+fLkUx/WqfaJGUti2+XWXhONKwNNvoMJQ2/gVn d3p+2Pkzd5a4o6Zf2jTxGNmPHF5l/hFg36UWhq+iG+QZoO4xQmVfkhst6i3nDgOlJ1Ab OTfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781369182; x=1781973982; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=K8rLoyOXFw7VUJEKmruhMJQ/B4T5IQX0xF59VROp3nw=; b=kBIpBvh7U665il7iM3SYOIK/Kp4sDigt0aAtM+W45RIFJjVb/loaMcnsUQxc+PB4u6 KjteLqHTk9sVnH6p+gVz3RBkrf74kNyDr+WHOCtaV0MKiBS3MtluwnvDBMmUSZMHdMRh IU+FtB941LC+3cq8+iSiaHbEWsKA87PdD7cCGscfiPHBZaRYcgBMJ60fM4nSVH6Y7+Xg zstFhSJu9eCfgITISTYanm5k9mY1bjxT6sq6aUYFl6kQgjXe5NHaexL9SKKGQMEtWxhx RH6+xPsW1QDq32yuGxhdDLJIcy/hrG5/CUfOjUYWJ1JNzqUrZM8KizJpSISL8aLNhLH8 krHQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ8HRDUklWkYn7FdJXlHqEBIgRy7dF9K1SeU5VhSh4V7RM6ljJFV4cJ8ngSBOyEu0KBvNpjzZMZZzFi9@gnusha.org X-Gm-Message-State: AOJu0Yx6rNA7TLrBO4zW3A/gzc5FjILehK9DlWLlPkPPOwa1ioz3KkKF TOOxXPyfg9Qrw7G5owUjRCDSb1UtBdJWkOeP+xSr+fmuBcdpKb6gUMGT X-Received: by 2002:a05:6820:408:b0:69d:f888:8a96 with SMTP id 006d021491bc7-69edc6c3623mr1585267eaf.2.1781369182092; Sat, 13 Jun 2026 09:46:22 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUfm7gFy74CaF1miHWx2w5Sc97ESut8XUegUikxQevlrfw==" Received: by 2002:a05:6820:168e:b0:69e:8587:ef49 with SMTP id 006d021491bc7-69ed7d35895ls2067012eaf.2.-pod-prod-09-us; Sat, 13 Jun 2026 09:46:17 -0700 (PDT) X-Received: by 2002:a05:6809:396:20b0:487:55d8:ec22 with SMTP id 5614622812f47-48755d8f90emr361654b6e.1.1781369177842; Sat, 13 Jun 2026 09:46:17 -0700 (PDT) Received: by 2002:a05:690c:8682:10b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7f7980936e2ms7b3; Sat, 13 Jun 2026 09:39:21 -0700 (PDT) X-Received: by 2002:a05:690c:2505:b0:7af:6904:3f3f with SMTP id 00721157ae682-7f7b951eed3mr72538177b3.45.1781368760522; Sat, 13 Jun 2026 09:39:20 -0700 (PDT) Date: Sat, 13 Jun 2026 09:39:20 -0700 (PDT) From: Daniel Osemberg To: Bitcoin Development Mailing List Message-Id: <7fe5fea8-ae9d-4081-a94f-fa9be0677012n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] [bitcoin-dev] Proposal discussion: BIP39 native-language display wordlists MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_185838_56019149.1781368760115" X-Original-Sender: daniosemberg@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_185838_56019149.1781368760115 Content-Type: multipart/alternative; boundary="----=_Part_185839_2069420239.1781368760115" ------=_Part_185839_2069420239.1781368760115 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi conduition, Thank you for the thoughtful feedback. I agree that ambiguity is the main= =20 issue any proposal like this has to handle carefully. To clarify the design: TZUR display wordlists are not meant to replace or= =20 reinterpret existing BIP39 wordlists. They are separate, index-parallel=20 display wordlists whose purpose is to render and accept a user-facing=20 mnemonic in another language while keeping the canonical English BIP39=20 mnemonic as the seed of record. So the derivation path for a TZUR display mnemonic is always: localized TZUR display words =E2=86=92 word indices =E2=86=92 canonical Eng= lish BIP39 words=20 =E2=86=92 standard BIP39 checksum validation =E2=86=92 standard PBKDF2 =E2= =86=92 standard=20 BIP32/BIP84 derivation The localized words themselves are never passed directly into PBKDF2. Only= =20 the canonical English mnemonic is. Your French example is exactly the edge case that needs to be explicit. A= =20 legacy French BIP39 mnemonic and a TZUR French display mnemonic are not the= =20 same thing. They are two different encodings that may use the same human=20 language, and they must not be silently treated as interchangeable. For that reason, a wallet implementing this convention should not just see= =20 =E2=80=9CFrench words=E2=80=9D and guess. It should know, or ask, which wor= dlist mode is=20 being used: 1.=20 =20 Legacy BIP39 French wordlist 2.=20 =20 TZUR French display wordlist 3.=20 =20 Canonical English BIP39 =20 The reference design also includes stable wordlist identifiers: language=20 code, version, and SHA256 of the exact wordlist file. A wallet can persist= =20 that metadata alongside the wallet, and use it during restore to avoid=20 ambiguity. But for maximum portability, the wallet should always show the= =20 canonical English mnemonic as the universal recovery form. So I think your concern is valid. The safe rule is: never auto-detect=20 between legacy non-English BIP39 and TZUR display lists when both exist.=20 Make the mode explicit, keep the English mnemonic available, and treat the= =20 display mnemonic as a UX layer rather than a new seed derivation scheme. Regards, Daniel On Saturday, June 13, 2026 at 7:36:05=E2=80=AFPM UTC+3 conduition wrote: > Hey Daniel, > > So basically this would allow a user to translate an english language=20 > BIP39 seed phrase to/from other languages, insured by the knowledge that = it=20 > be converted back if needed for compatibility with english-only BIP39=20 > wallets. > > Neat idea. This is how BIP39 should've been done originally. Today, a=20 > BIP39 seed derives a different master key depending on what language is= =20 > used to encode the source entropy, which was arguably a mistake because i= t=20 > breaks compatibility between implementations written for different locale= s,=20 > and incentivizes everyone to use seeds of the same language so that they'= re=20 > maximally compatible (which is exactly what happened).=20 > > I worry your proposal here might cause confusion if introduced today=20 > though. Say you are given a french language 12-word seed phrase. Do you m= ap=20 > the word indices to english and then run PBKDF2 with your algorithm? Or d= o=20 > 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= =20 > between a "locale-mapped seed phrase" using your spec, and a legacy frenc= h=20 > 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= =20 > you could safely assume the former, but still it leaves open an unfortuna= te=20 > 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 < > danios...@gmail.com> wrote: > > Hi list, > > I would like to ask for early feedback on an idea before attempting any= =20 > formal BIP submission. > > The proposal is a display/input layer for BIP39 recovery phrases in=20 > additional native languages. > > The important constraint is that this does not change the BIP39=20 > cryptographic flow. The canonical mnemonic remains the existing BIP39=20 > English wordlist, and PBKDF2 is still performed on the canonical English= =20 > form. > > The native-language lists are index-paired to the English BIP39 wordlist.= =20 > In other words, each native word maps to the same 0-2047 index as the=20 > corresponding English BIP39 word. Wallets could display or accept the=20 > native-language form for UX purposes, but internally normalize back to th= e=20 > canonical English mnemonic before seed generation. > > Motivation: > > Many users around the world are asked to back up and restore Bitcoin=20 > wallets using English recovery words, even when English is not their nati= ve=20 > language. This creates UX risk, spelling mistakes, misunderstanding, and= =20 > lower confidence during backup and recovery. > > This proposal tries to improve multilingual recovery UX while keeping=20 > 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=20 > support native-language recovery UX while preserving canonical BIP39=20 > 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 > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/e4ee1a70-aa70-4dbe-9f6c-27c2= 6c5d17e0n%40googlegroups.com > . > > > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 7fe5fea8-ae9d-4081-a94f-fa9be0677012n%40googlegroups.com. ------=_Part_185839_2069420239.1781368760115 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi conduition,

Thank you for the thoughtful feedback. I agree that= ambiguity is the main issue any proposal like this has to handle carefully= .

To clarify the design: TZUR display wordlists are not meant to repl= ace or reinterpret existing BIP39 wordlists. They are separate, index-paral= lel display wordlists whose purpose is to render and accept a user-facing m= nemonic in another language while keeping the canonical English BIP39 mnemo= nic as the seed of record.

So the derivation path for a TZUR display = mnemonic is always:

localized TZUR display words =E2=86=92 word indic= es =E2=86=92 canonical English BIP39 words =E2=86=92 standard BIP39 checksu= m validation =E2=86=92 standard PBKDF2 =E2=86=92 standard BIP32/BIP84 deriv= ation

The localized words themselves are never passed directly into P= BKDF2. Only the canonical English mnemonic is.

Your French example is= exactly the edge case that needs to be explicit. A legacy French BIP39 mne= monic and a TZUR French display mnemonic are not the same thing. They are t= wo different encodings that may use the same human language, and they must = not be silently treated as interchangeable.

For that reason, a wallet= implementing this convention should not just see =E2=80=9CFrench words=E2= =80=9D and guess. It should know, or ask, which wordlist mode is being used= :

  1. Legacy BIP39 French wordlist

  2. TZUR French dis= play wordlist

  3. Canonical English BIP39

The re= ference design also includes stable wordlist identifiers: language code, ve= rsion, and SHA256 of the exact wordlist file. A wallet can persist that met= adata alongside the wallet, and use it during restore to avoid ambiguity. B= ut for maximum portability, the wallet should always show the canonical Eng= lish mnemonic as the universal recovery form.

So I think your concern= is valid. The safe rule is: never auto-detect between legacy non-English B= IP39 and TZUR display lists when both exist. Make the mode explicit, keep t= he English mnemonic available, and treat the display mnemonic as a UX layer= rather than a new seed derivation scheme.

Regards,
Daniel

On Sa= turday, June 13, 2026 at 7:36:05=E2=80=AFPM UTC+3 conduition wrote:
Hey Daniel,

So basically this would allow a user to t= ranslate an english language BIP39 seed phrase to/from other languages, ins= ured 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 origi= nally. Today, a BIP39 seed derives a different master key depending on what= language is used to encode the source entropy, which was arguably a mistak= e because it breaks compatibility between implementations written for diffe= rent locales, and incentivizes everyone to use seeds of the same language s= o that they're maximally compatible (which is exactly what happened).= =C2=A0

=
I worry yo= ur 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 indice= s 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 w= ay for humans and software to distinguish between a "locale-mapped see= d phrase" using your spec, and a legacy french BIP39 seed phrase, so t= hey know how to derive the correct master key.

I guess one could argue that non-english BIP3= 9 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 s= ome cases.
=
What d= o you think of this?

regards,
conduition
On Saturday, June 13th, 2026 at 12:04 PM, Daniel Osemberg <danios...@gmail.c= om> wrote:

Hi list,

I would like to ask for early feedback on an = idea before attempting any formal BIP submission.

The proposal is a d= isplay/input layer for BIP39 recovery phrases in additional native language= s.

The important constraint is that this does not change the BIP39 cr= yptographic 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 cor= responding English BIP39 word. Wallets could display or accept the native-l= anguage form for UX purposes, but internally normalize back to the canonica= l English mnemonic before seed generation.

Motivation:

Many use= rs around the world are asked to back up and restore Bitcoin wallets using = English recovery words, even when English is not their native language. Thi= s creates UX risk, spelling mistakes, misunderstanding, and lower confidenc= e during backup and recovery.

This proposal tries to improve multilin= gual recovery UX while keeping compatibility with existing BIP39 behavior.<= /p>

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 BIP= 39 compatibility.

A draft implementation and wordlists are here:

<= p>https://github.com/osem23/b= ip39-wordlists-tzur

I would appreciate feedback on:

Whether= this idea is appropriate for the BIP process at all
Whether it should b= e considered informational rather than standards-track
Whether the index= -paired approach creates hidden risks
Whether wallet developers see prac= tical value in this
How native-speaker review and normalization rules sh= ould be handled
Whether there is prior work I should study before contin= uing

Thank you,
Daniel

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bit= coindev/e4ee1a70-aa70-4dbe-9f6c-27c26c5d17e0n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/7fe5fea8-ae9d-4081-a94f-fa9be0677012n%40googlegroups.com.
------=_Part_185839_2069420239.1781368760115-- ------=_Part_185838_56019149.1781368760115--