From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 13 Jun 2026 09:36:13 -0700 Received: from mail-ot1-f63.google.com ([209.85.210.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wYRLA-0003C0-8W for bitcoindev@gnusha.org; Sat, 13 Jun 2026 09:36:12 -0700 Received: by mail-ot1-f63.google.com with SMTP id 46e09a7af769-7e6e0426fd3sf925206a34.3 for ; Sat, 13 Jun 2026 09:36:11 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781368565; cv=pass; d=google.com; s=arc-20240605; b=IilJ55bmmhv6NpxYLJz6iKVdDjLLkrgPqwy1ovP4zavmthDLP24D6DuvIfXplDcIlM qjQJa/7cZ/BbrbS4RncyhQ3LHFDj68S3um4IheqZ/14+NqGjVawtNsXXVsbFlR6l8TsZ eUuwf6DbTaHUqr6Hc34g7hAtQiVmKSx+UxgCxHQlxUmqN5X3deKR/y2Mc+3Hpr+SCr3y DHKxKuXksIM3c5rl3fDrlpfvPns3NXQEWtqGE1yvs8dEQQbpjHThpJyZoF8zp43NtTTH u+xeTGiNLrW5ul4Je+wX530oaJrR6q/hwJmh47V536+ezNm8i1NPIc/pGR+6mduhAz+h mKWw== 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=sViQ0gscfuJ4DsKPiQqiIMbFtxlC+Osp/XJVpYNEHKs=; fh=rEsOnS4gMnlv8unyNOSMA9iFikbsDl0vkZ7ZxT50XPc=; b=gAnGtAxEisJMMr6Wb7XISl9FsIm7owbbVg7bAa0TG9lX+pHUCXczM17xe9XrukKxbi jgwzPkuQAeX/XUDFGE4cPlqq8doU8nfBH0Eetn1/gWToN0hkHeqU8DVRomWXmq42A5Iw u0OGWoey5HoEAEckundbVxZO0XhuzFDlGbT4fOGfWzqwXeJMBC4ILLgLPT4a693eyfms TezTaHeP19QJbbDIqCQdvMbUnw0qY32gcwiRdDHBZJiWmm/4yXRH3NIqxgf8RGPzZGoP fmfbn4ch5pVOgYIsxfKg5eUszfm6g+/dw6sqoSfjZwfeakf+e0vvY4KZonUg4y72ypRa LGpg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=gcuvnN63; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 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=1781368565; x=1781973365; 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=sViQ0gscfuJ4DsKPiQqiIMbFtxlC+Osp/XJVpYNEHKs=; b=KAPrpq7HEVkf8KbT4W8P/QJYX1aPtupWXZHTlPs1ej1q5gfu+xqWnfgFepqyAgcNdX nqBjiLKQduDyKvg1xE0P1Exwxh3+xDYCdSIsSSKABt49xSEwgrVcSEsFHMPIZTKWKC22 ZttmhjdXRFf8wNGsQRy0O3Ndwz3EonlohuZY3YCusR1b9Vre28RmVhXkCrK/0XRD0tAY bkE9kucOaGWn5zfdAZD7ZR6z72HYjATc5mc1tJ7k/PJ7u3A0PXJ2dvQnPtgYO4EDDd4Q NGFilJO44Fi5+DgjVLGfomnJ8V0xxnPPfhqZH6rnuvMcbx8A5QGYp+ZTc2MTj8MKGByR cHbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781368565; x=1781973365; 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=sViQ0gscfuJ4DsKPiQqiIMbFtxlC+Osp/XJVpYNEHKs=; b=X9f2yuwX2P1k9C+hgOF0K+h0E/ZrN5Mhh88OuJlAvUNzCVHJ+/pS9G5c6Z3rg4r8O1 5P75Ck2Eacqh6RdDgAAkWw7lq+ql09sIyLr70BrnJaLSz7M/QfkOh5qM9eKgS1jgBxK4 z6KDYX8wxg/sgbTVUGqHvm+yYIza1QDo7KXwVvHXrvCJ9HwG9fgvPSLsZ/tPdusMmVd+ BVwfiUN8j4gad6TlNhrwXJovGrFYTcQkOm3uJeo5eTfjcPUqo0TNYPUzKg+mENzhqfQ5 Hxg0f7C/DlxhfRlGhfd3YsYs8S5fZLY+V2mJGOXoD/EZ6fe/1XpFf12eNBbs/OoKWxyX cQFA== X-Forwarded-Encrypted: i=2; AFNElJ8nSYpx9tKaWxdqJQg3b2Pi8Y914R9TqEzUC0tYni7H7FWN1O5oNynkAiQg7Kt/+C5GEMicjJ920r12@gnusha.org X-Gm-Message-State: AOJu0Yz03xw0WDFm6cTNZ6bJm5/M9RCHBY/bfce1Ght669x80O1VQau+ eXW59gJTzaw48pB5iaxjh0dIi4pw1QRCuwjHFxOjyiBq/B5s9cXxQ1GK X-Received: by 2002:a05:6830:6c14:b0:7e5:68ca:89d1 with SMTP id 46e09a7af769-7e7847d9352mr2988228a34.6.1781368565378; Sat, 13 Jun 2026 09:36:05 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUfF+6VPf4I1gWcXEWc+SYqhuh/n/W+baMH6l3El9RpJvQ==" Received: by 2002:a05:6871:a810:20b0:43d:1d34:8bbb with SMTP id 586e51a60fabf-442617c538cls836971fac.0.-pod-prod-01-us; Sat, 13 Jun 2026 09:36:01 -0700 (PDT) X-Received: by 2002:a05:6808:4f1e:b0:485:290e:8ba1 with SMTP id 5614622812f47-4872f31266fmr5012299b6e.8.1781368561432; Sat, 13 Jun 2026 09:36:01 -0700 (PDT) Received: by 2002:a05:600c:534c:b0:485:53e3:ec5e with SMTP id 5b1f17b1804b1-490ea8e6fecms5e9; Sat, 13 Jun 2026 09:35:07 -0700 (PDT) X-Received: by 2002:a05:600c:314a:b0:490:b8c0:d470 with SMTP id 5b1f17b1804b1-490ec504d5dmr91967755e9.19.1781368505995; Sat, 13 Jun 2026 09:35:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781368505; cv=none; d=google.com; s=arc-20240605; b=LFduHAmk8eVZOeLSg7+U5xJ74AGwfxhNXRu7ypVVvy2KyGpy3NxsWJ340uqQf74q0K 9s9wR1muGSP9LhtHlin8Xm+ARSOawK8Ap1ZSHjNkVJ8txznzb0UvUUEtf+MiStQjer5J KbSTp0stUqLCMKkU9PPTjYpRUuac7R1qCBVhwNVisLTtSiiEw8Sndb1WuTqMyEzef0Vz ySHmtWTJppi+yHaHQtSq6YPVXwPESQPsIrkFdmRIHwvYyXFP/e749Mn9VxQz4/L4hoRu 5cYYG/PnstBcPsPJN/2EC2sjvQecd8R0IzEsf3rB8tWCncjovDQOMnMA7Nt6IA8BgX5l nUdQ== 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=hQCKjxmH6Z3/dPPDyxYX8wl1HC9N7wAcoo7H4MnX1Fw=; fh=siFuu9E44rOQLaoPayHMNEd4eIOO0IgnvKqemF9vWEA=; b=RDU81+ho49D2XBFmL82ghlZSki78n8XZ+J32Ksca1HLa1H1/p1tENgV3cuYVfqIOS5 iTyoDGqHVYb6dTISUkO3h72BK6AZAP0gQdBWAy3z7qd2mdDdyI7K361jlF3tPlhz29cz oHfUVpE0FA2X/cNGfXGDaMQT/GENftl6YuR5VSbRQNSRUKAfYAf7rqDhJMJeTKDNE+os PKLzdHtYOZgDDWf2PDwFyf1C4mW1hVM1xE4l98okOgtSaL5/CA92cFgJX3pd+v69wItE NsCzccpj2+SPcAYJrPgBg7Ilg/S3x8WgKjHMazzaqiPJzFCznjDA9FdDgkQuJi4KM3om ZeoQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=gcuvnN63; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch. [185.70.43.167]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-49220396e95si558605e9.2.2026.06.13.09.35.05 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Jun 2026 09:35:05 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.167 as permitted sender) client-ip=185.70.43.167; Date: Sat, 13 Jun 2026 16:34:59 +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: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 8a2e4ead48193ee9d86603240e9e7487513fb903 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------d5322ad522d2ef2cf6ef068996a72ac39496339eb7b95f9c07e1634be6437a72"; 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=gcuvnN63; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.167 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) --------d5322ad522d2ef2cf6ef068996a72ac39496339eb7b95f9c07e1634be6437a72 Content-Type: multipart/mixed;boundary=---------------------691ec0201b10048c8d8a2b1ea02380b3 -----------------------691ec0201b10048c8d8a2b1ea02380b3 Content-Type: multipart/alternative;boundary=---------------------76060632b3a2f08238beb1257c8b10b5 -----------------------76060632b3a2f08238beb1257c8b10b5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 c= onverted 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 c= ompatibility between implementations written for different locales, and inc= entivizes everyone to use seeds of the same language so that they're maxima= lly compatible (which is exactly what happened).=C2=A0 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 w= ord indices to english and then run PBKDF2 with your algorithm? Or do you r= un 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 b= etween a "locale-mapped seed phrase" using your spec, and a legacy french B= IP39 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 y= ou could safely assume the former, but still it leaves open an unfortunate = ambiguity which could lead to lost funds in some cases. What do you think of this? regards, conduition On Saturday, June 13th, 2026 at 12:04 PM, Daniel Osemberg wrote: > Hi list, >=20 > I would like to ask for early feedback on an idea before attempting any f= ormal BIP submission. >=20 > The proposal is a display/input layer for BIP39 recovery phrases in addit= ional native languages. >=20 > The important constraint is that this does not change the BIP39 cryptogra= phic flow. The canonical mnemonic remains the existing BIP39 English wordli= st, and PBKDF2 is still performed on the canonical English form. >=20 > 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 corr= esponding English BIP39 word. Wallets could display or accept the native-la= nguage form for UX purposes, but internally normalize back to the canonical= English mnemonic before seed generation. >=20 > Motivation: >=20 > Many users around the world are asked to back up and restore Bitcoin wall= ets using English recovery words, even when English is not their native lan= guage. This creates UX risk, spelling mistakes, misunderstanding, and lower= confidence during backup and recovery. >=20 > This proposal tries to improve multilingual recovery UX while keeping com= patibility 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 sup= port native-language recovery UX while preserving canonical BIP39 compatibi= lity. >=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-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 >=20 > Thank you, > Daniel >=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/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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= FOZaQw_eyfsyT45cgYr6VCHB79in1lybdP9HBbm-KkEQqqjwrNA5DHghqebO1nB3PhvpHyhmPoD= 5qlHi7KHygLzRqXU6u_B9LSm5K-H-YC8%3D%40proton.me. -----------------------76060632b3a2f08238beb1257c8b10b5 Content-Type: multipart/related;boundary=---------------------6fc2200f2b1949bc7fd9e687a9a6753f -----------------------6fc2200f2b1949bc7fd9e687a9a6753f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Daniel,=

<= /div>
So bas= ically this would allow a user to translate an english language BIP39 seed = phrase to/from other languages, insured by the knowledge that it be convert= ed back if needed for compatibility with english-only BIP39 wallets.
<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">
Neat idea. Th= is 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 so= urce entropy, which was arguably a mistake because it breaks compatibility = between implementations written for different locales, and incentivizes eve= ryone to use seeds of the same language so that they're maximally compatibl= e (which is exactly what happened). 

I worry your proposal here might cause c= onfusion 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 PBKD= F2 with your algorithm? Or do you run PBKDF2 on the french version as speci= fied in the original BIP39?

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

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

What do you think = of this?

conduition
On Saturday, June 13th, 2026 at 12:04 PM, Daniel Osemberg <d= aniosemberg@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/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 e= mail to bitcoindev+u= nsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/e4ee1a70-aa70-4dbe-9f6= c-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/bitcoindev/FOZaQw= _eyfsyT45cgYr6VCHB79in1lybdP9HBbm-KkEQqqjwrNA5DHghqebO1nB3PhvpHyhmPoD5qlHi7= KHygLzRqXU6u_B9LSm5K-H-YC8%3D%40proton.me.
-----------------------6fc2200f2b1949bc7fd9e687a9a6753f-- -----------------------76060632b3a2f08238beb1257c8b10b5-- -----------------------691ec0201b10048c8d8a2b1ea02380b3 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== -----------------------691ec0201b10048c8d8a2b1ea02380b3-- --------d5322ad522d2ef2cf6ef068996a72ac39496339eb7b95f9c07e1634be6437a72 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmothqIJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmeuMyMZcYxx/nzN20auJrJjdG2vfWssd3rIXWLx 9MEqPBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAABLUgEA1MdSZoKhvfpyCfan jyCwIucI6uy6L0PtzvB0ZGKKRdYA/jl3VyQqqhl/Z5eStDuWa5mahoEjkkjA dBD35+XqzhoE =/e4H -----END PGP SIGNATURE----- --------d5322ad522d2ef2cf6ef068996a72ac39496339eb7b95f9c07e1634be6437a72--