From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 16 Jun 2026 14:28:13 -0700 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wZbKN-0002lN-W5 for bitcoindev@gnusha.org; Tue, 16 Jun 2026 14:28:13 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-69dc9cb3663sf6761215eaf.1 for ; Tue, 16 Jun 2026 14:28:11 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1781645286; cv=pass; d=google.com; s=arc-20240605; b=a6OYAd9vDx/UU219S7CsSvh0azPoUeWgb6q3aV27ab8LZU8DM1Uec5iGs83aHChL+K sJ+AsIEuhokttxQ9kk2JazeqZfGpF2ufgFhOvjdDVbz+NrLFs/gVjm8yR9YMNSiA5+LR pd+oKSAyjr7/MkmCPG7gbtAY2ae0h0fZ1ifBjl3COUZWsrCXMltZ2qwuIpKz3Y7okFPE B9Rqpma9ZL42HV6h/EbpIjchnV2Vqm12NSJUNMo8AJT63Kt2eGpojYMp6Sj63Ov1SL60 pnF3OP4VDkO+QwOsYnGGWt5sfdwQ5/ABWZ8kNid55AxekOI+ap7JNaBdEZfR9scPN131 96SQ== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=UbtVjHn2Gxuip6RK6PxNPi7c/hHHFCOTiDUSMpzMoQM=; fh=bRtoCt8wKj2vHo0p41jhbjfye/JD1oIyJSguqWYtDss=; b=IidTzra2N3RGE4Azu8F1WbX5o5XHm9dTZK1nCG9/YU81Zntj0//vL//jGmLprKQ5v8 c3n7aoo1gRS5RvLdpxDqFSNUuhPm6gN+VtyHmGz3xto/uIfGnz+H/6UhZGK7oc6mG8Ob ladZz1klJ3igNVdaEPTrA33ZVXSIsk3yrYOL/3x47Leul5LusWvQvFeeBffgy3+XKGf1 H4EOqejx0FN0QSeEpr6RDeWmS24foXi3jtD1YD9dHoMy8nB78MX1fBcuaRerT04hZXzs 4r45SR3HcXQFV0MzmOd9D2uHNMT6bapZl4fEZ+t1+MmKRAOA02LNjKsWL7n9DuOo8Adz fRtA==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=n9ZU6NK5; arc=pass (i=1); spf=pass (google.com: domain of daniosemberg@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=daniosemberg@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781645286; x=1782250086; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=UbtVjHn2Gxuip6RK6PxNPi7c/hHHFCOTiDUSMpzMoQM=; b=Xy9XVzmscET2n6eZo5iHD8cTbOgRwpEljP6FuP/Ro452xf939yg8QZbatkriwVcnw6 Xvl2LIOkJkBCae3/l/yve7i5kgst8iLsm6AzKBcR4OSHWwutyYuwb+F7niRO9m1jGd8+ 7HGv+FSBmG1ujJl1wSTeSCG8MSI554FAI3YqJMQU2UkTByCkwgw6uqQHVF9K9UAuDDNp M4Y1zNpJ7faQQcBJuPH60koDFhAJhXJduhvoA5/aXHxjyIaWiy7amuS/QFHfCfcNBBUJ 31oQahNbts5QPVaPPNe/D+AUIUSaAm5UqIK/PFFvdQXJxtdsGB7aZKJ+qFV1uu8PsJi2 6mxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781645286; x=1782250086; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UbtVjHn2Gxuip6RK6PxNPi7c/hHHFCOTiDUSMpzMoQM=; b=UTUN8Ay/YMcbbFXf+x+xelYcJHOCkmV83yPnq02siUBlrnF5fiKauumP5H4PvXqsC0 28Wi430BbDKg7WexRntw700lFgd/WFrdNG0c49Su2cGq1lmO1E4igJ+K43v3zhIixBv/ V7I6IjKl7O1SalJWsyPx8Qg631RFKsgW0oTb9xXx72ERD4Q1Px7gbg+/y3Iw7ASGbiwG DBk/LTDUmsGmrPQWZBnGPT3DZ2zNPGT4DbSkF8BPVaS6wFuM2sFfqPeQQgxEsb6YoujR K8JD/eAL1ZMP3m3H4QZXSnpMkG2mb244NGn9Zvl29fevv+01bLSMoEb+0CXS4KsXKwBw sU5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781645286; x=1782250086; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=UbtVjHn2Gxuip6RK6PxNPi7c/hHHFCOTiDUSMpzMoQM=; b=DcGvSCWJtwxUxaGP8iPBILq62f5GxmU9VdyJbR1nAGx+eqyoyeClsP4kr1CfYHSmZH GP6MVTjj9PxZWrdF34fz1F8ulNmPySVbabobA9dmSJGT2jCcf4cuQk3r8wdw4rxPi5VP CZIooryq8LOm7Ubvcc73a+k8mVRQQiyuwVrGr6WbHKz+HvQXbKVJQG6LV1OhEtJ30GEd aQof9l+JsTxN90w2TWDHaF/qPH42R3IdBT4hMI2wNY4E53j2yCwqb5qEHADpFUfqUk3V pJvskj0m5T7gzC/H4DkkUQE7LjagBHSs7/rYaqiXebnajmhz3Qa8a5OGj6loJR+vHR5H 8ODg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ+bzVpM6xCXyV7pVm6vCOadpZugUZj5uop7/infENvaZoDmIQrG2ZCXfoz3hW9OrXE0V7RsJM4qFMmM@gnusha.org X-Gm-Message-State: AOJu0YwUfFkf/RZjQKqJsaAjJS+CRMXYc8GuB+8Juz5yM9cFyoO6ElBX G6b1y9k3R6UMAqUjy1Pq0GiPkpP0Lj6hgbMGyQ2bvk3b1E3vJwwOMNL9 X-Received: by 2002:a05:6820:1c98:b0:69e:3e2a:a83d with SMTP id 006d021491bc7-6a0b60c052emr777601eaf.32.1781645286023; Tue, 16 Jun 2026 14:28:06 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUcQv5e0aHRG7cvjML6468x1SqCRoUyjyajtjW5xjwFVnA==" Received: by 2002:a05:6820:168e:b0:69e:8587:ef49 with SMTP id 006d021491bc7-69ed7d35895ls4870594eaf.2.-pod-prod-09-us; Tue, 16 Jun 2026 14:28:02 -0700 (PDT) X-Received: by 2002:a05:6808:1494:b0:479:d57b:838a with SMTP id 5614622812f47-489429fad12mr1141191b6e.35.1781645281966; Tue, 16 Jun 2026 14:28:01 -0700 (PDT) Received: by 2002:a05:600c:ad3:b0:490:3d60:134 with SMTP id 5b1f17b1804b1-4923347da40ms5e9; Tue, 16 Jun 2026 14:25:38 -0700 (PDT) X-Received: by 2002:a05:6000:18a3:b0:45e:f271:5019 with SMTP id ffacd0b85a97d-46236276630mr2118055f8f.14.1781645136925; Tue, 16 Jun 2026 14:25:36 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781645136; cv=pass; d=google.com; s=arc-20240605; b=IlmFZUkZcN+XC8204nkDb3xlDtLVkoDM2juW0kUOqTzHVlGe5BciCR1MWlpgKJF5Xk zs670aLWpDudJIqkCfuDl9Z18oMBpG2f1skgdsPYJBeaLRyagNqC921yMy8nPUlEKMGB jr3Pcsyial3s5jUbseOjrm43BP8W6Ag8H5iZhmjE+TADM00fdI78xFODz3qOzIDRW3lX XyudTRvUsfl2Qf1lCpWO61NCgJvNL2pD0U999TyB1EhIRuOAuI0WEby4KfvkxBtccqWk VV4Ih4YIfmMgX05RNvtfddLsRgr1IQ6d7/UBabbvZtdu8cpTbnDDfBIEOCbsppCgTUgG rMFw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=M9NbBdmhbvQytl49JiWG2/KzVYgjWiHu8Q183AnA/OY=; fh=AraWG4EtKgnVZC3vx0kKXPCQKgjblcoyQOn27ZV865o=; b=JslsDf6o2aWGmyF82pRcR+9iS6SF8IZ3WGPzBdXKAxjLJVMQESa8ll3ltrGx+3X+M9 UVXuWoE57h7mCa1QtwJq0qNft5dzDmmrKdS8YSdSLCjHnFBK8el0aZstfi8KOQ0P/WIN +iYjpVT1zI0TxUtfKeEYT59tF35e4pnnwUXIHJ1k6RKjuchlCkC0aMK+IorcIT7R/pu7 vgFxtTEd+Pi6dWfwICR0l5LkLYvPpt2PMekoRhARlbVxoV6cQ7kJbw1dT9DsKJ7UBfhq LYLc1E90LoFHc9Z6g2gwUiQ+5oF2nPMLon7s5ZNm3+X9sLgaex+uPrsdPs56LTjNYolG Y3Bg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=n9ZU6NK5; arc=pass (i=1); spf=pass (google.com: domain of daniosemberg@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=daniosemberg@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com. [2a00:1450:4864:20::536]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-4606f2d8960si337750f8f.3.2026.06.16.14.25.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2026 14:25:36 -0700 (PDT) Received-SPF: pass (google.com: domain of daniosemberg@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) client-ip=2a00:1450:4864:20::536; Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-68e5f7c1131so8634202a12.2 for ; Tue, 16 Jun 2026 14:25:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781645136; cv=none; d=google.com; s=arc-20240605; b=erHSwuTTebWb1I/d7wZoQ+vUftyxToMxyWvAo+qVUJzFnriUqO5b7NGtZeQZMFhlvv CWgzXM5OrozMbRbtX5bSHdV/hM8bGF7e6fzEc+gaYqSSCvSARxu1iCMzWTMM6SSfXEmB XqVE1ASwQxOXBJw74bVXVYnblQCHqjzvwphkhYgt38rLhLKLN+AJETIXBp1OMMGYCHsX a1CkggepOuVntd0wJsh9m2VOstMaBiW2PnZ0HKhxE0H4hlOlbW0iiFIy7x+oFCmRH4fg 2RzA3p35LfToHN4xY7DQ0F2zH7hpswvRJUG0AW2OKkrmu1jv5P3pqA2ma5tNSCiYQFGM 5+Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=M9NbBdmhbvQytl49JiWG2/KzVYgjWiHu8Q183AnA/OY=; fh=AraWG4EtKgnVZC3vx0kKXPCQKgjblcoyQOn27ZV865o=; b=Xy1mRb4cCmLqGGd7SOOIGttZ5y5Hmx6rCInH+wCl8W4MoNBX4erH3Wwj/iN9Bxo020 H2nzkkeklxw3tjszUb1FMnfW3Pfo8QZOc5CyEWRHqCimPk2aZiTZk5x0tPE3ZJQabMGL wnNn3Ovw1BqS6taNDSowGTi6wwVhVz08Dd1Zx37w8EHU3g2LLJ+yi6A8O0BUTrQ9/xG4 tnOYW0kKt19gHrEmo3QRLC+yVAbO7xcdwW39OJsP5DNWn9k/X3TqpvQv1g/0N1z/Brsm ZDbC58j0rjv5FK6ifTm9uuxFosd76lzsXin/C2uoRPhGle4XgObhB4b2qzvlQnz9ylND PjkQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: Acq92OExOgeFKpMefzoaOwj4yYVRWeVHxnMfLffs4AKZe/y6WqfiLUMzMGAkQy/Sxif bSXRIy+9yKo1SoMNUC+R8Fo2HXLujf9updEruulFQJdxuKjnw9MZPL7cIcYyk4Y/uH3pGJCY8BM u7QmP7+rOWVShTzkuTssrJdjFGs+RUojLJdCUYqIbElUQ5xr46Q7ftMDCohcaT8uXByF5E/DKpz +T3MytQ+cu/1+AJEkpNjLgihihCGPdAKHYmSxwCc+bR4Dc6kVLWewoHPs2m5GQMQvgoyhgqop1z YsqUF3TkYE9zGcQkVUgOPaZ9bJK4O1sQdEYywN0cuK4bOUw+20vb+hXX+RF8XvTSg+jtUZPPc1F 4YS1s31NkNQMrpqQOPl/HQ1ixYSR4YqMOo83D8ppTdf97TgktBrE/1yJTEzSWiraC/MqlponnC8 X4scaXoKY5z1MrP69WaR9aqwuVpLTG6aH2VVsX6hs= X-Received: by 2002:a05:6402:501d:b0:691:afc9:f59c with SMTP id 4fb4d7f45d1cf-695473ff222mr547639a12.1.1781645136027; Tue, 16 Jun 2026 14:25:36 -0700 (PDT) MIME-Version: 1.0 References: <7fe5fea8-ae9d-4081-a94f-fa9be0677012n@googlegroups.com> In-Reply-To: From: Daniel Osemberg Date: Wed, 17 Jun 2026 00:25:24 +0300 X-Gm-Features: AVVi8Ccq21iZn0XPVcRDWTlYvoJd4DsJ3ct6eNxTyOvo_r5eEmXYgRAnWUs-gPU Message-ID: Subject: Re: [bitcoindev] [bitcoin-dev] Proposal discussion: BIP39 native-language display wordlists To: conduition Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000072e587065465952c" X-Original-Sender: daniosemberg@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=n9ZU6NK5; arc=pass (i=1); spf=pass (google.com: domain of daniosemberg@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=daniosemberg@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --00000000000072e587065465952c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Conduition, Thank you, this is a very useful way to frame the problem. I agree that the ambiguity must be handled seriously, but I am not sure that changing the word count, wordlist size, or encoding is the right direction for this proposal. The goal of this proposal is not to create a new seed phrase format. The goal is to define fixed, independent display wordlists that map deterministically to the canonical English BIP39 word indexes. In this model, English BIP39 remains the canonical recovery form. The localized phrase is a wallet-level display/input convention, not a new entropy encoding scheme and not a replacement for BIP39. The existing non-English BIP39 wordlists are still relevant for anyone who created a wallet using those lists. I do not have exact data on how widely they are used, but it is reasonable to assume they have been used by some wallets and users. Therefore, any wallet that wants to support both legacy non-English BIP39 mnemonics and this display-wordlist convention must be able to distinguish between them explicitly. That distinction is required regardless of this proposal. Today, a wallet may already need to distinguish between English BIP39, legacy non-English BIP39, Electrum seeds, SLIP39, BIP39 with or without passphrase, and other wallet-specific recovery formats. A seed phrase without context can already be ambiguous in practice. For that reason, I think the safer requirement is not to change the encoding, but to make the restoration mode explicit and prevent silent interpretation. A compatible wallet should: 1. Treat English BIP39 as the canonical form. 2. Treat TZUR-style localized wordlists as separate fixed display lists, not as existing BIP39 language lists. 3. Never automatically reinterpret a legacy non-English BIP39 mnemonic as a mapped display mnemonic. 4. Clearly label import and export modes. 5. Always allow the user to view and export the canonical English BIP39 phrase. 6. Include stable wordlist identifiers, such as language code, version, and hash of the exact wordlist file. I agree that using disjoint wordlists, or at least avoiding overlap with existing BIP39 wordlists where possible, can reduce the chance of confusion. That is a good design constraint for the display lists. But changing the number of words or changing the encoding would move the proposal away from being a BIP39-compatible display/input layer and toward being a new recovery phrase format. That seems like a different proposal with different compatibility tradeoffs. So I think the right rule is: Legacy BIP39 wordlists remain valid for wallets that created them. The new display lists must be independent, fixed, clearly identified, and mapped only to canonical English BIP39 indexes. Wallets that support both must expose the distinction explicitly and must never guess silently. Thanks again. This feedback is very helpful, and I will make sure the draft explains this distinction more clearly. Best, Daniel On Wed, 17 Jun 2026 at 0:18 conduition wrote: > 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 > 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-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 (becau= se > maybe it only supports 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 > 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 oth= er > extraneous meta-information - Just the seed phrase. > > To make your translated wordlists work like this and fix the ambiguity, I > would recommend you consider changing the encoding or the format to ensur= e > 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= . > > One clean 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 encode *11 words* with 12 bits per word - the exact same > number of bits are encoded in both cases. To map the phrase back to BIP39 > is as simple as changing how those bits are interpreted. Since a > 4096-length word list would be double the size of a BIP39 wordlist, it > *must* include at least 2048 words not present in the BIP39 wordlists, > and so a randomly-sampled word has at most a 1 in 2 chance of being in th= e > BIP39 wordlist. Thus the 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 by reducing the size of the intersection between > the TZUR and BIP39 wordlists. > > 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 phrase, it should work. (e.g. 13 words with 10 bits per word, > encoding 130 bits). > > You could use wordlists which have size that isn't a power of two, and us= e > some base-x math to reconstruct the entropy as a big unsigned integer. > > You could make your wordlists shorter instead of longer, though you'd nee= d > to be careful to minimize the overlap with BIP39 wordlists. > > You could use a different word list for specific word indexes, e.g. the > first word *must* be a non-bip39 word, and so it encodes less information > but 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 < > daniosemberg@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 handle carefully. > > To clarify the design: TZUR display wordlists are not meant to replace or > reinterpret existing BIP39 wordlists. They are separate, index-parallel > display wordlists whose purpose is to render and accept a user-facing > mnemonic in another language while keeping the canonical English BIP39 > 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 E= nglish BIP39 > words =E2=86=92 standard BIP39 checksum validation =E2=86=92 standard PBK= DF2 =E2=86=92 standard > BIP32/BIP84 derivation > > The localized words themselves are never passed directly into PBKDF2. Onl= y > the canonical English mnemonic is. > > 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 t= he > same thing. They are two 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 se= e > =E2=80=9CFrench words=E2=80=9D and guess. It should know, or ask, which w= ordlist mode is > being used: > > 1. > > Legacy BIP39 French wordlist > 2. > > TZUR French display wordlist > 3. > > Canonical English BIP39 > > The reference design also includes stable wordlist identifiers: language > code, version, and SHA256 of the exact wordlist file. A wallet can persis= t > 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 explicit, keep the English mnemonic available, and treat th= e > 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 >> 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 local= es, >> 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 distinguis= h >> 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. >> >> I guess one could argue that non-english BIP39 seeds are so uncommon tha= t >> you could safely assume the former, but still it leaves open an unfortun= ate >> 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 >> 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 t= he >> 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 nat= ive >> 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-trac= k >> 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 Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/e4ee1a70-aa70-4dbe-9f6c-27c= 26c5d17e0n%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/7fe5fea8-ae9d-4081-a94f-fa9b= e0677012n%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/= CAFS8eiXHr3zbujpr3QndrCqAU%2BRtDxoOJca1EF5h2PvMGnCzqw%40mail.gmail.com. --00000000000072e587065465952c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hey Conduition,

Thank you, this is a very useful way to frame the problem.

I agree that the ambiguity must be handled seriously, but I am not sure = that changing the word count, wordlist size, or encoding is the right direc= tion for this proposal.

The goal of this proposal is not to create a new seed phrase format. The= goal is to define fixed, independent display wordlists that map determinis= tically to the canonical English BIP39 word indexes.

In this model, English BIP39 remains the canonical recovery form. The lo= calized phrase is a wallet-level display/input convention, not a new entrop= y encoding scheme and not a replacement for BIP39.

The existing non-English BIP39 wordlists are still relevant for anyone w= ho created a wallet using those lists. I do not have exact data on how wide= ly they are used, but it is reasonable to assume they have been used by som= e wallets and users. Therefore, any wallet that wants to support both legac= y non-English BIP39 mnemonics and this display-wordlist convention must be = able to distinguish between them explicitly.

That distinction is required regardless of this proposal. Today, a walle= t may already need to distinguish between English BIP39, legacy non-English= BIP39, Electrum seeds, SLIP39, BIP39 with or without passphrase, and other= wallet-specific recovery formats. A seed phrase without context can alread= y be ambiguous in practice.

For that reason, I think the safer requirement is not to change the enco= ding, but to make the restoration mode explicit and prevent silent interpre= tation.

A compatible wallet should:

  1. Treat English BIP39 as the canonical form.
  2. Trea= t TZUR-style localized wordlists as separate fixed display lists, not as ex= isting BIP39 language lists.
  3. Never automatically reinterpret a lega= cy non-English BIP39 mnemonic as a mapped display mnemonic.
  4. Clearly= label import and export modes.
  5. Always allow the user to view and e= xport the canonical English BIP39 phrase.
  6. Include stable wordlist i= dentifiers, such as language code, version, and hash of the exact wordlist = file.

I agree that using disjoint wordlists, or at least avoiding overlap with= existing BIP39 wordlists where possible, can reduce the chance of confusio= n. That is a good design constraint for the display lists.

But changing the number of words or changing the encoding would move the= proposal away from being a BIP39-compatible display/input layer and toward= being a new recovery phrase format. That seems like a different proposal w= ith different compatibility tradeoffs.

So I think the right rule is:

Legacy BIP39 wordlists remain valid for wallets that created them.

The new display lists must be independent, fixed, clearly identified, an= d mapped only to canonical English BIP39 indexes.

Wallets that support both must expose the distinction explicitly and mus= t never guess silently.

Thanks again. This feedback is very helpful, and I will make sure the dr= aft explains this distinction more clearly.

Best,
Daniel



On Wed, 17 Jun 2026 at 0:18 cond= uition <conduition@proton.me= > wrote:
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 fren= ch uncle dies and leaves you a 12 word french seed phrase. You install a BI= P39 wallet and 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 (bec= ause maybe it only supports one format or the other), then the wallet happi= ly imports the seed without asking and you have no idea the distinction eve= n exists.
<= br>
A seed = phrase is supposed to contain all the necessary information to recover a wa= llet, either explicitly in its encoded payload, or implicitly in its format= . That way a user doesn't have to record or remember any other extraneo= us meta-information - Just the seed phrase.

To make your translated wordlists work like this= and fix the ambiguity, I would recommend you consider changing the encodin= g or the format to ensure a TZUR-translated display phrase cannot be interp= reted as a BIP39 non-english seed phrase. So for instance, using a differen= t number of words. Or use wordlists disjoint from BIP39, so that the probab= ility of a random TZUR phrase containing at least one non-BIP39 word is ove= rwhelming.=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 b= its per word - the exact same number of bits are encoded in both cases. To = map the phrase back to BIP39 is as simple as changing how those bits are in= terpreted. Since a 4096-length word list would be double the size of a BIP3= 9 wordlist, it=C2=A0must=C2= =A0include at least 2048 words not present in the BIP39 wordlists, and so a= randomly-sampled word has at most a 1 in 2 chance of=C2=A0being in the BIP= 39 wordlist. Thus the chance of all 11 random words just happening to be BI= P39 words would be at least 1 in 2048. You can (and probably should) reduce= that probability by reducing the size of the intersection between the TZUR= and BIP39 wordlists.

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 BIP= 39 seed phrase, it should work. (e.g. 13 words with 10 bits per word, encod= ing 130 bits).=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 integ= er.=C2=A0
<= br>
You cou= ld 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 first word must=C2=A0be a non-bip39 word, and so it encodes less in= formation but 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 <daniosemberg@gmail.co= m> 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 use= r to translate an english language BIP39 seed phrase to/from other language= s, insured by the knowledge that it be converted back if needed for compati= bility 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 happen= ed).

    <= /div>
    I worry you= r proposal here might cause confusion if introduced today though. Say you a= re 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 o= n 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 p= hrase" 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 s= eeds 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 y= ou think of this?

    regards,
    c= onduition
    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>ht= tps://github.com/osem23/bip39-wordlists-tzur

    I would appreciate f= eedback on:

    Whether this idea is appropriate for the BIP process at a= ll
    Whether it should be considered informational rather than standards-t= rack
    Whether the index-paired approach creates hidden risks
    Whether w= allet developers see practical value in this
    How native-speaker review a= nd normalization rules should be handled
    Whether there is prior work I s= hould study before continuing

    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/bitcoindev/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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/7fe5fea8-ae9d-4081-a94f-= 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/CAFS8eiXHr3zbujpr3QndrCqAU%2BRtDxoOJca1EF5h2PvMGnCzqw%40ma= il.gmail.com.
--00000000000072e587065465952c--