From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 16 Jun 2026 14:28:12 -0700 Received: from mail-oo1-f62.google.com ([209.85.161.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wZbKM-0002lK-PD for bitcoindev@gnusha.org; Tue, 16 Jun 2026 14:28:12 -0700 Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-69e3464b1afsf5741816eaf.0 for ; Tue, 16 Jun 2026 14:28:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781645285; cv=pass; d=google.com; s=arc-20240605; b=Xsa1iej9KzaLu9RBo1m+hm+tXydafTRmVhIpKqas+RRk2WU2evSH3knvSGWzQLMOPD lRmG5VE9Tp/onStgIU7rX1i5MO6k8a7/eN4qleSQGvRoZTMdEZtmEL9t06420FHaR0bm B1W75Ohph4ElKC7apaGNoL/Q2HdpFYEbFTw9V4bdyrPkCjGRm7UO/lusGiQCu7ulDGmW sLgva8b245DunkVWq/T8mbobiXeTWrWwCkrUtXMvWxQeFftAoHPZ4HTD3qZlh9IYYXQX bbHKBhtyRglF3UErorU9So1sjy//I6vZXdiz7fn684HSV0U0OOUeH+l2CjLA4/u78g6Q 136Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=dlGJ//Qryl0ZNJ1RE2r/N5VAYluCU+IxwmVzKS/nV3Q=; fh=emFLHXr4iIDNaBbF0eTcicJEzCXk2xYhezfkRTREy4s=; b=U3cByfggfo6bOFg1ohgZ/ccdRPbANOZxObbUcsIPrJwdQFpK6fdI/2LjOR+aFe/gmt heglJ6X8T0TrafsE+KZzDAXT9x8VV1irCVV4Btxy/AGyeROBtfc3lo6yTkS3HgCIaum/ Kjc2imj6TKwR/XBFPA3TguF6A0VUgNoS2HIsqnLnxKeqitBcm5BwXYjb91cWF4VZuwrW lCfPTuOSdy0Ozh48kjl59yI5xr+C1nGnqv7k65zHu6ZMMaYymg/kqDiLyYZIn1w/FseO v0t1SDZJxapCf/tqrI8M7vCodg1uvrFjBVXKdPyh3Gan7JpchCLKuFao66vO3OhedguO aHew==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=Dfpr+sM8; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.96 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781645285; x=1782250085; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=dlGJ//Qryl0ZNJ1RE2r/N5VAYluCU+IxwmVzKS/nV3Q=; b=Xd/PWYmXrSeVHgMp/dYoprr4TMNN0T7FPYprUHQgLhLH5Ify8CYj78y4E7gypLIyER fy/wL5T7qrHNa/lh5rAiWErzSV2cjuMlgApMPioqIeQXBIe9zHXBFWkgRdRhHlxNZBjZ 5HcaBMt+PImZqul/q0JCbAxG5GJORuiEvCwEelQIOgjFKMOkbm4z0Xei9lg0tO0v5dLF TJXXCb5/li0wfhBBxbxnUt6IzUHgDZHVKYOsR9Z2Y+7F8kfbEPHAYTJKsCPUQGk1Glqo 2HpqD4KIiZ2QkVwB1Hm0VyjcW+q8xp57lbvDWKl8wogAF/jO6HgVW7EG4hmlGPh3xVNa ScWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781645285; x=1782250085; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dlGJ//Qryl0ZNJ1RE2r/N5VAYluCU+IxwmVzKS/nV3Q=; b=VX7zxb7paeUdmBpZax2YYNWsfdlFb1Nvns+JybvuP3wsFcuSWQbSkry2mQ/9ISd/AF WlkASDAFwjedCpfXJwxjDyjSvLH0OTGhs6OMzCo7EmUHS9aXs48x4Tu8ZPXe6wHQHwi9 Oit9UO3hxxWtQew6lYXOi8H+MA91wROyUXrZ/j6O81T0ouj18G4VTxBe+gDz1F9ztZRE V4qXyE5bWMDwNuFucVtJlgw4v61lVSfuW4fIzHzQybgxY7emBMeqIKnPt3d+IHqhdgll IAzzgvB/wbweJWGYBA2wTe4CNW9bMgkivhzzOyT6bkEBv9sBkL4mr3ndAOawHJTcGXr+ tXVg== X-Forwarded-Encrypted: i=2; AFNElJ89nMOj3j5YlQFV4ULpAKmDjXIr5IinHxhYcF9maCG/Sk+wT7ttGcWO41FcHw7r6YHIaRCeeuOpfD0n@gnusha.org X-Gm-Message-State: AOJu0YxlO6StgaJUYuuCpXMGhdeZWEzoSjnWbohiypJFYT7pJmVA3D6+ UodREe5y7Rg2rKdztQ1MSImbCW7T4ETFyVoIAFdh0LjZsOb3SmIPgM0R X-Received: by 2002:a05:6820:16a5:b0:69e:b41f:1963 with SMTP id 006d021491bc7-6a0b61c48femr692782eaf.48.1781645284344; Tue, 16 Jun 2026 14:28:04 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUfI3KIvu2VRCDmkuxVGpnwr2O09n70e96H1xjTgzYW4cQ==" Received: by 2002:a05:687c:3393:b0:43f:a4c9:acab with SMTP id 586e51a60fabf-442617be954ls2130591fac.0.-pod-prod-03-us; Tue, 16 Jun 2026 14:27:58 -0700 (PDT) X-Received: by 2002:a05:6809:388:20b0:487:4f76:d3eb with SMTP id 5614622812f47-489445f2751mr503987b6e.21.1781645278687; Tue, 16 Jun 2026 14:27:58 -0700 (PDT) Received: by 2002:a05:6402:a2cd:20b0:68c:16a8:bd1b with SMTP id 4fb4d7f45d1cf-695469b008bmsa12; Tue, 16 Jun 2026 14:18:41 -0700 (PDT) X-Received: by 2002:a05:6402:2804:b0:68c:bf82:8844 with SMTP id 4fb4d7f45d1cf-69547561dfemr500218a12.6.1781644720228; Tue, 16 Jun 2026 14:18:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781644720; cv=none; d=google.com; s=arc-20240605; b=IyOmq5Rm0sJO3BdoYmjGA6Ty9J6I2lSDsWALF/EjVhfrrRENhq5qBnu2D+nknAIHVS T0J4lU+eZ6jTmOsNLqsbI7HqiXfzwhguXKPE50MiupWn/F41frp9DzEAPt5RCLV5B5KL ghqy/2oC9gXnudzYvWz4wNuFIYTCAEJWh5n4D92zpfIv5UTnNQEBQIgS8NmBNn6rNlTV mlJjwUGMxD7G0p5HLwOUueIs/SnpNYaWySASLad6+djzRk9ScoHcRjZgVEKx1uYfDrUk Tc4cZroUOvCatcC07bS86Ob4mcQZozyOL0cXYW3VjEj6N/KLevyww9d/WQMuxrwM029M aMqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=jTZeB8kpZ6RKH187GXj4fukA/DM66BIiTkNRVrFWcMU=; fh=siFuu9E44rOQLaoPayHMNEd4eIOO0IgnvKqemF9vWEA=; b=hhMtTyPQGKGYzhcl3ttNEbI5Klx1lhJp/8NArwgKuEniMCqJrhR3tf10+u0vp/hUON BjEDT4ECHphCfXPTaZEZrogBSl1eDxrHZPHwQQpEAJ3dVS6mZ/dA89GciNlVuHEbYo2e NBXSGxMbblNlxSBywwDnirQKeJYY2cePoVK1/HpOtLwantww45IPOWH975AgM1x/hzmE SQy1SRJNZ7dp/j0omsQW8o6jK/Pmplk98+HlnhqhOCZka54WQuiLL6Xys60lNd9Y5IVc yuid8JDCUEon6tlTZcdVhPkiVDvJ5dzZq72JMuEay1vRMXxlNy60KZB/T6nBO3t71ai3 I9ww==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=Dfpr+sM8; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.96 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10696.protonmail.ch (mail-10696.protonmail.ch. [79.135.106.96]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-69378e07bccsi270262a12.0.2026.06.16.14.18.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 14:18:40 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.96 as permitted sender) client-ip=79.135.106.96; Date: Tue, 16 Jun 2026 21:18:36 +0000 To: Daniel Osemberg From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] [bitcoin-dev] Proposal discussion: BIP39 native-language display wordlists Message-ID: In-Reply-To: <7fe5fea8-ae9d-4081-a94f-fa9be0677012n@googlegroups.com> References: <7fe5fea8-ae9d-4081-a94f-fa9be0677012n@googlegroups.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: c16ea5529816336beee7d8b4fd27542c4e1d9d5b MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------e64f5ebdea1d63ac2c761dca39b8ec372ec30bc54799e8aee9640c855a470880"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=Dfpr+sM8; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.96 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------e64f5ebdea1d63ac2c761dca39b8ec372ec30bc54799e8aee9640c855a470880 Content-Type: multipart/mixed;boundary=---------------------f7dde30defeedf1a579dfbbb5e34ca9d -----------------------f7dde30defeedf1a579dfbbb5e34ca9d Content-Type: multipart/alternative;boundary=---------------------a4c4ea183187287f454452e79dd76880 -----------------------a4c4ea183187287f454452e79dd76880 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hey Daniel, > For that reason, a wallet implementing this convention should not just se= e =E2=80=9CFrench words=E2=80=9D and guess. It should know, or ask, which w= ordlist mode is being used: This is the exact problem I was referring to. Imagine your french uncle die= s and leaves you a 12 word french seed phrase. You install a BIP39 wallet a= nd import the seed phrase. The wallet asks you: Is this a BIP39 seed phrase= or a TZUR-translated seed phrase? You don't know what that means - all you= have is a list of 12 french words. The only thing you can do as a user is = try both. And if the wallet doesn't ask you at all (because maybe it only s= upports one format or the other), then the wallet happily imports the seed = without asking and you have no idea the distinction even exists. A seed phrase is supposed to contain all the necessary information to recov= er a wallet, either explicitly in its encoded payload, or implicitly in its= format. That way a user doesn't have to record or remember any other extra= neous meta-information - Just the seed phrase. To make your translated wordlists work like this and fix the ambiguity, I w= ould recommend you consider changing the encoding or the format to ensure a= TZUR-translated display phrase cannot be interpreted as a BIP39 non-englis= h seed phrase. So for instance, using a different number of words. Or use w= ordlists disjoint from BIP39, so that the probability of a random TZUR phra= se containing at least one non-BIP39 word is overwhelming.=C2=A0 One clean way to do both would be to increase the size of the TZUR wordlist= s. For instance, instead of encoding 12 words with 11 bits per word, you mi= ght encode 11 words with 12 bits per word - the exact same number of bits a= re encoded in both cases. To map the phrase back to BIP39 is as simple as c= hanging how those bits are interpreted. Since a 4096-length word list would= be double the size of a BIP39 wordlist, it=C2=A0must=C2=A0include at least= 2048 words not present in the BIP39 wordlists, and so a randomly-sampled w= ord has at most a 1 in 2 chance of=C2=A0being in the BIP39 wordlist. Thus t= he chance of all 11 random words just happening to be BIP39 words would be = at least 1 in 2048. You can (and probably should) reduce that probability b= y reducing the size of the intersection between the TZUR and BIP39 wordlist= s. You don't have to use those exact numbers either - as long as your encoding= is able to package all the entropy bits from the equivalent a BIP39 seed p= hrase, it should work. (e.g. 13 words with 10 bits per word, encoding 130 b= its).=C2=A0 You could use wordlists which have size that isn't a power of two, and use = some base-x math to reconstruct the entropy as a big unsigned integer.=C2= =A0 You could make your wordlists shorter instead of longer, though you'd need = to be careful to minimize the overlap with BIP39 wordlists. You could use a different word list for specific word indexes, e.g. the fir= st word must=C2=A0be a non-bip39 word, and so it encodes less information b= ut guarantees the phrase can't be misinterpreted as BIP39. Anyways just some ideas. Hope it comes in handy. regards, conduition On Saturday, June 13th, 2026 at 9:46 AM, Daniel Osemberg wrote: > Hi conduition, >=20 > Thank you for the thoughtful feedback. I agree that ambiguity is the main= issue any proposal like this has to handle carefully. >=20 > To clarify the design: TZUR display wordlists are not meant to replace or= reinterpret existing BIP39 wordlists. They are separate, index-parallel di= splay wordlists whose purpose is to render and accept a user-facing mnemoni= c in another language while keeping the canonical English BIP39 mnemonic as= the seed of record. >=20 > So the derivation path for a TZUR display mnemonic is always: >=20 > localized TZUR display words =E2=86=92 word indices =E2=86=92 canonical E= nglish BIP39 words =E2=86=92 standard BIP39 checksum validation =E2=86=92 s= tandard PBKDF2 =E2=86=92 standard BIP32/BIP84 derivation >=20 > The localized words themselves are never passed directly into PBKDF2. Onl= y the canonical English mnemonic is. >=20 > Your French example is exactly the edge case that needs to be explicit. A= legacy French BIP39 mnemonic and a TZUR French display mnemonic are not th= e same thing. They are two different encodings that may use the same human = language, and they must not be silently treated as interchangeable. >=20 > For that reason, a wallet implementing this convention should not just se= e =E2=80=9CFrench words=E2=80=9D and guess. It should know, or ask, which w= ordlist mode is being used: >=20 > 1. Legacy BIP39 French wordlist > =20 > 2. TZUR French display wordlist > =20 > 3. Canonical English BIP39 > =20 >=20 > The reference design also includes stable wordlist identifiers: language = code, version, and SHA256 of the exact wordlist file. A wallet can persist = that metadata alongside the wallet, and use it during restore to avoid ambi= guity. But for maximum portability, the wallet should always show the canon= ical English mnemonic as the universal recovery form. >=20 > So I think your concern is valid. The safe rule is: never auto-detect bet= ween legacy non-English BIP39 and TZUR display lists when both exist. Make = the mode explicit, keep the English mnemonic available, and treat the displ= ay mnemonic as a UX layer rather than a new seed derivation scheme. >=20 > Regards, > Daniel >=20 >=20 > On Saturday, June 13, 2026 at 7:36:05=E2=80=AFPM UTC+3 conduition wrote: >=20 > > Hey Daniel, > >=20 > > So basically this would allow a user to translate an english language B= IP39 seed phrase to/from other languages, insured by the knowledge that it = be converted back if needed for compatibility with english-only BIP39 walle= ts. > >=20 > > Neat idea. This is how BIP39 should've been done originally. Today, a B= IP39 seed derives a different master key depending on what language is used= to encode the source entropy, which was arguably a mistake because it brea= ks compatibility between implementations written for different locales, and= incentivizes everyone to use seeds of the same language so that they're ma= ximally compatible (which is exactly what happened). > >=20 > > I worry your proposal here might cause confusion if introduced today th= ough. Say you are given a french language 12-word seed phrase. Do you map t= he word indices to english and then run PBKDF2 with your algorithm? Or do y= ou run PBKDF2 on the french version as specified in the original BIP39? > >=20 > > There would need to be a clear way for humans and software to distingui= sh between a "locale-mapped seed phrase" using your spec, and a legacy fren= ch BIP39 seed phrase, so they know how to derive the correct master key. > >=20 > > I guess one could argue that non-english BIP39 seeds are so uncommon th= at you could safely assume the former, but still it leaves open an unfortun= ate ambiguity which could lead to lost funds in some cases. > >=20 > > What do you think of this? > >=20 > > regards, > > conduition > >=20 > > On Saturday, June 13th, 2026 at 12:04 PM, Daniel Osemberg wrote: > >=20 > > > Hi list, > > >=20 > > > I would like to ask for early feedback on an idea before attempting a= ny formal BIP submission. > > >=20 > > > The proposal is a display/input layer for BIP39 recovery phrases in a= dditional native languages. > > >=20 > > > The important constraint is that this does not change the BIP39 crypt= ographic flow. The canonical mnemonic remains the existing BIP39 English wo= rdlist, and PBKDF2 is still performed on the canonical English form. > > >=20 > > > The native-language lists are index-paired to the English BIP39 wordl= ist. 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 nativ= e-language form for UX purposes, but internally normalize back to the canon= ical English mnemonic before seed generation. > > >=20 > > > Motivation: > > >=20 > > > 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 l= ower confidence during backup and recovery. > > >=20 > > > This proposal tries to improve multilingual recovery UX while keeping= compatibility with existing BIP39 behavior. > > >=20 > > > This is not: > > >=20 > > > A new seed scheme > > > A replacement for BIP39 > > > A new cryptographic standard > > > A change to PBKDF2 input > > > A wallet-specific format > > >=20 > > > It is intended as a display/input convention for wallets that want to= support native-language recovery UX while preserving canonical BIP39 compa= tibility. > > >=20 > > > A draft implementation and wordlists are here: > > >=20 > > > https://github.com/osem23/bip39-wordlists-tzur > > >=20 > > > I would appreciate feedback on: > > >=20 > > > Whether this idea is appropriate for the BIP process at all > > > Whether it should be considered informational rather than standards-t= rack > > > 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 > > >=20 > > > Thank you, > > > Daniel > >=20 > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+...@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/e4ee1a70-aa70-4dbe-9f6c-27c26c5d17e0n%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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/7fe5fea8-ae9d-4081-a94f-fa9be0677012n%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/= kxuhfn7jqWsmcvm6ANEIYxdL8FiGzgHt5_tx9weHR9WMfIv_wAopjsBK9zbIb_3UdL5sLzzOTkC= CdXe0YmfcbKX4_n3q5Fp8HUd4LlfPojo%3D%40proton.me. -----------------------a4c4ea183187287f454452e79dd76880 Content-Type: multipart/related;boundary=---------------------739f29c8702c3ec2970b659af83be789 -----------------------739f29c8702c3ec2970b659af83be789 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Daniel,=

<= /div>
= For that reason, a wallet implementing this convention should not jus= t see =E2=80=9CFrench words=E2=80=9D and guess. It should know, or ask, whi= ch wordlist mode is being used:

This is the e= xact problem I was referring to. Imagine your french uncle dies and leaves = you a 12 word french seed phrase. You install a BIP39 wallet and import the= seed phrase. The wallet asks you: Is this a BIP39 seed phrase or a TZUR-tr= anslated seed phrase? You don't know what that means - all you have is a li= st of 12 french words. The only thing you can do as a user is try both. And= if the wallet doesn't ask you at all (because maybe it only supports one f= ormat or the other), then the wallet happily imports the seed without askin= g and you have no idea the distinction even exists.

A seed phrase is supposed to c= ontain all the necessary information to recover a wallet, either explicitly= in its encoded payload, or implicitly in its format. That way a user doesn= 't have to record or remember any other extraneous meta-information - Just = the seed phrase.

To make your translated wordlists work like this and fix the ambi= guity, I would recommend you consider changing the encoding or the format t= o ensure a TZUR-translated display phrase cannot be interpreted as a BIP39 = non-english seed phrase. So for instance, using a different number of words= . Or use wordlists disjoint from BIP39, so that the probability of a random= TZUR phrase containing at least one non-BIP39 word is overwhelming. <= /div>

One cle= an way to do both would be to increase the size of the TZUR wordlists. For = instance, instead of encoding 12 words with 11 bits per word, you might enc= ode 11 words with 12 bits per word - the exact same number of bits a= re encoded in both cases. To map the phrase back to BIP39 is as simple as c= hanging how those bits are interpreted. Since a 4096-length word list would= be double the size of a BIP39 wordlist, it must include a= t least 2048 words not present in the BIP39 wordlists, and so a randomly-sa= mpled word has at most a 1 in 2 chance of being in the BIP39 wordlist.= Thus the chance of all 11 random words just happening to be BIP39 words wo= uld be at least 1 in 2048. You can (and probably should) reduce that probab= ility by reducing the size of the intersection between the TZUR and BIP39 w= ordlists.

You don't have to use those exact numbers either - as long as your encod= ing is able to package all the entropy bits from the equivalent a BIP39 see= d phrase, it should work. (e.g. 13 words with 10 bits per word, encoding 13= 0 bits). 

You could use wordlists which have size that isn't a power of two, = and use some base-x math to reconstruct the entropy as a big unsigned integ= er. 

You could make your wordlists shorter instead of longer, though you'd ne= ed to be careful to minimize the overlap with BIP39 wordlists.

You could use a dif= ferent word list for specific word indexes, e.g. the first word must=  be a non-bip39 word, and so it encodes less information but guarantee= s the phrase can't be misinterpreted as BIP39.

Anyways just some ideas. Hope it co= mes in handy.

regards,
conduition
On Saturday, June 13th, 2026 at 9:46 AM, Daniel Osemberg <danios= emberg@gmail.com> wrote:

Hi conduition,

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

To clarify the design: TZUR display wordlists are not m= eant to replace or reinterpret existing BIP39 wordlists. They are separate,= index-parallel display wordlists whose purpose is to render and accept a u= ser-facing mnemonic in another language while keeping the canonical English= BIP39 mnemonic as the seed of record.

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

localized TZUR display words =E2=86= =92 word indices =E2=86=92 canonical English BIP39 words =E2=86=92 standard= BIP39 checksum validation =E2=86=92 standard PBKDF2 =E2=86=92 standard BIP= 32/BIP84 derivation

The localized words themselves are never passed d= irectly into PBKDF2. Only the canonical English mnemonic is.

Your Fre= nch example is exactly the edge case that needs to be explicit. A legacy Fr= ench BIP39 mnemonic and a TZUR French display mnemonic are not the same thi= ng. They are two different encodings that may use the same human language, = and they must not be silently treated as interchangeable.

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

  1. Legacy BIP39 French wordlist

  2. TZ= UR French display wordlist

  3. Canonical English BIP39

    4. <= /ol>

    The reference design also includes stable wordlist identifiers: lang= uage code, version, and SHA256 of the exact wordlist file. A wallet can per= sist that metadata alongside the wallet, and use it during restore to avoid= ambiguity. But for maximum portability, the wallet should always show the = canonical English mnemonic as the universal recovery form.

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

    Regards,
    D= aniel


    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 BIP39 seed phrase to/from other lang= uages, insured by the knowledge that it be converted back if needed for com= patibility 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 o= n 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 lang= uage so that they're maximally compatible (which is exactly what happened).=

    I worry your pr= oposal here might cause confusion if introduced today though. Say you are g= iven 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 th= e 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" us= ing your spec, and a legacy french BIP39 seed phrase, so they know how to d= erive the correct master key.

    I guess one could argue that non-english BIP39 seeds are so un= common that you could safely assume the former, but still it leaves open an= unfortunate ambiguity which could lead to lost funds in some cases.
    <= div style=3D"font-family:Arial,sans-serif;font-size:14px">
    What do you think of th= is?

    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 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 "= 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 "= Bitcoin Development Mailing List" group.
    To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
    To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/7fe5fea8-ae9d-4081-a94= f-fa9be0677012n%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/bitcoindev/kxuhfn= 7jqWsmcvm6ANEIYxdL8FiGzgHt5_tx9weHR9WMfIv_wAopjsBK9zbIb_3UdL5sLzzOTkCCdXe0Y= mfcbKX4_n3q5Fp8HUd4LlfPojo%3D%40proton.me.
-----------------------739f29c8702c3ec2970b659af83be789-- -----------------------a4c4ea183187287f454452e79dd76880-- -----------------------f7dde30defeedf1a579dfbbb5e34ca9d Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------f7dde30defeedf1a579dfbbb5e34ca9d-- --------e64f5ebdea1d63ac2c761dca39b8ec372ec30bc54799e8aee9640c855a470880 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmoxvZwJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmf8Wl7NnKxsgzFfTDwqtIf3iVXqoumDnn48kxE3 FSEExRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABjQQD/VmlAyu9rEskYpMJ0 HMXkFGoIDUP02+vFXS7nNagSM7QBAOVKXpzQXyGkxULDIXP9UEOwk5zsWjWO 01Qk/qJp14IH =yFWa -----END PGP SIGNATURE----- --------e64f5ebdea1d63ac2c761dca39b8ec372ec30bc54799e8aee9640c855a470880--