From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Jun 2026 09:04:27 -0700 Received: from mail-qt1-f186.google.com ([209.85.160.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wYQqQ-0002ts-UJ for bitcoindev@gnusha.org; Sat, 13 Jun 2026 09:04:27 -0700 Received: by mail-qt1-f186.google.com with SMTP id d75a77b69052e-51956be1f44sf9942071cf.1 for ; Sat, 13 Jun 2026 09:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781366657; x=1781971457; 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:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=472AWexXt6ClrOlypY2itxX+JY4ctSOZGBRw/4UpXdo=; b=BrfQPY+ab4eFPoCtKv5uQ2YOEJod/Rt+2g7IwzQEMIzGnHZbwrlTu104d2vEdr7V9d tRn3uKQ0tqSrgGkhW8+iU7W+nyNgnGGyiW8nJNGlNkJNqdqCZ5kUnsyewb9ydcCFcH6R rrdVa1qghrXq+JGpL609CpybcDqu27nCNJjTnNxHAuxMSQom6xg5jelkUyENKiRS2QJM /gO+JKuH+DzDujJpSvRcOTNbkQy0pceFT6GI+4Fb2IcXzbn4Nzj3ibi8aWke9vlvQjwq PgX3tCVNbev4KTbnryIBjmhVejF3UQab41976HKp6ok2ABYJC/UR7O1NCPXNBKuht13Z novw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781366657; x=1781971457; 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:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=472AWexXt6ClrOlypY2itxX+JY4ctSOZGBRw/4UpXdo=; b=eKKixNUAcD36LLPoqYwxZ5/Wwt3RM4fS3VPYzBdKjRm0jcPXEP/w829KcDEhNXtisP RxHDDpyWLx261va7wi3nJtaUDjpa+Qn+pbdVUp0rCGwpIP7Dq89W5WeySeJGY8ncAvgx Xw+aF02+Tg7ljLTQMYjLMNLzg8b0BuVwEo+qhBaXbbmKUJQocM+x2C/fscfnZuj1jOxs n29cQuAaZSITvA/e0zGElEEvxSW7j6ALUXPc4q0DTaIT4J5Ku6VpxFsCIF5Bc05rtycx ePt3vWkQUsmcvu1CvenW7FHR4p6D7dY6Kz2maebh/oHzKTT7vxIbL05F4NlvyQMWEsgW G63Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781366657; x=1781971457; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=472AWexXt6ClrOlypY2itxX+JY4ctSOZGBRw/4UpXdo=; b=Mwx6uXeMUVe2UDLFSkYJd/hzosGqIUFLKxArciTCpaMZk3g2b/tLAIpnZprzu8uCVs yEtyOp2+EJ4+dOIGFiKrmKPLyscMrrF1+WPis4Xo5ww4bivtAGhMvBTjmfgc15rO7de8 t2huV0tQamW/D5528CUxEKT7H7wxTWrx2+cZ8Hx4hQKYHQwSPO5ymR9XjajlAgLakvPQ 0l/vh1OHaNTuJVs06XrY6pqHiBJSxBX3Llm5LUjz9S080ze7cKjwzKclWvjXnuid5mTX lkKfaO61nBaR/LuYx2aeJX08nW+SIw6GG5RLDF3sXbKjAIA+u9a+KuuCBFr8gutrzTc8 n6ZA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/IVIJtal5BSt6r+tyWCTEKOfvjhyTXYaRf96TG+or3HJkyvWWKOeOZqTBa2JvM+aLJmKw0zvNLkkAT@gnusha.org X-Gm-Message-State: AOJu0YwLyMjHtJ34NyKONFQXXBHeAVj8OShZUs0oiqvoqUdNfjTfwmBj eI1VVIbkrsqzIIOlUgVO239dUepi4mLfU1DNMtLYFGik4Sv0yoiIQDl1 X-Received: by 2002:ac8:5f54:0:b0:516:35fe:5524 with SMTP id d75a77b69052e-517fbc89717mr97721091cf.5.1781366656843; Sat, 13 Jun 2026 09:04:16 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUfjrnBaTX8OoggoskQiN3dfBeebFYtRWUmnTS+FfjRVqg==" Received: by 2002:ac8:7fd6:0:b0:509:d0a:5648 with SMTP id d75a77b69052e-517f9f46528ls50678641cf.2.-pod-prod-09-us; Sat, 13 Jun 2026 09:04:13 -0700 (PDT) X-Received: by 2002:a05:620a:7014:b0:916:411:a143 with SMTP id af79cd13be357-9161bbfe733mr1134639285a.21.1781366652913; Sat, 13 Jun 2026 09:04:12 -0700 (PDT) Received: by 2002:a05:690c:6881:b0:7ba:f1b3:9504 with SMTP id 00721157ae682-7ed2c8f87e8ms7b3; Mon, 8 Jun 2026 07:24:10 -0700 (PDT) X-Received: by 2002:a05:690c:7309:b0:7dc:61c7:5932 with SMTP id 00721157ae682-7ed0c71406fmr144056857b3.28.1780928647570; Mon, 08 Jun 2026 07:24:07 -0700 (PDT) Date: Mon, 8 Jun 2026 07:24:06 -0700 (PDT) From: Daniel Osemberg To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] [bitcoin-dev] Proposal discussion: BIP39 native-language display wordlists MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_371710_1497331813.1780928646953" 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_371710_1497331813.1780928646953 Content-Type: multipart/alternative; boundary="----=_Part_371711_1355420289.1780928646953" ------=_Part_371711_1355420289.1780928646953 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_371711_1355420289.1780928646953 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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, a= nd PBKDF2 is still performed on the canonical English form.

The nativ= e-language lists are index-paired to the English BIP39 wordlist. In other w= ords, each native word maps to the same 0-2047 index as the corresponding E= nglish BIP39 word. Wallets could display or accept the native-language form= for UX purposes, but internally normalize back to the canonical English mn= emonic before seed generation.

Motivation:

Many users around th= e world are asked to back up and restore Bitcoin wallets using English reco= very words, even when English is not their native language. This creates UX= risk, spelling mistakes, misunderstanding, and lower confidence during bac= kup and recovery.

This proposal tries to improve multilingual recover= y UX while keeping compatibility with existing BIP39 behavior.

This i= s not:

A new seed scheme
A replacement for BIP39
A new cryp= tographic standard
A change to PBKDF2 input
A wallet-specific for= mat

It is intended as a display/input convention for wallets that wan= t to support native-language recovery UX while preserving canonical BIP39 c= ompatibility.

A draft implementation and wordlists are here:

https://github.com= /osem23/bip39-wordlists-tzur

I would appreciate feedback on:

<= p>Whether this idea is appropriate for the BIP process at all
Whether = it should be considered informational rather than standards-track
Whet= her the index-paired approach creates hidden risks
Whether wallet deve= lopers see practical value in this
How native-speaker review and norma= lization 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 &= 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/e4ee1a70-aa70-4dbe-9f6c-27c26c5d17e0n%40googlegroups.com.
------=_Part_371711_1355420289.1780928646953-- ------=_Part_371710_1497331813.1780928646953--