Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W5Y9i-0004zB-Nw for bitcoin-development@lists.sourceforge.net; Tue, 21 Jan 2014 10:02:02 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.43 as permitted sender) client-ip=209.85.212.43; envelope-from=g.rowe.froot@gmail.com; helo=mail-vb0-f43.google.com; Received: from mail-vb0-f43.google.com ([209.85.212.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W5Y9h-00024W-Cg for bitcoin-development@lists.sourceforge.net; Tue, 21 Jan 2014 10:02:02 +0000 Received: by mail-vb0-f43.google.com with SMTP id p5so3337368vbn.2 for ; Tue, 21 Jan 2014 02:01:55 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.220.159.4 with SMTP id h4mr13977362vcx.1.1390298515836; Tue, 21 Jan 2014 02:01:55 -0800 (PST) Sender: g.rowe.froot@gmail.com Received: by 10.220.64.146 with HTTP; Tue, 21 Jan 2014 02:01:55 -0800 (PST) In-Reply-To: <300D31FC-FB89-4386-8DD9-F5FA792D0B40@bitsofproof.com> References: <300D31FC-FB89-4386-8DD9-F5FA792D0B40@bitsofproof.com> Date: Tue, 21 Jan 2014 10:01:55 +0000 X-Google-Sender-Auth: ZV1O44gq97rmrOfwUGGVWmY9MuQ Message-ID: From: Gary Rowe To: Bitcoin Development List Content-Type: multipart/alternative; boundary=001a11c2ca0c2b14f404f07819b2 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (g.rowe.froot[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1W5Y9h-00024W-Cg Subject: Re: [Bitcoin-development] BIP0039: Final call X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 10:02:02 -0000 --001a11c2ca0c2b14f404f07819b2 Content-Type: text/plain; charset=UTF-8 MultiBit here. >At least Trezor and bitcoinj (Multibit) seems to be going in this way, >which is 100% of clients which expressed interest in bip39 :-). > >slush We'll be using the BIP39 implementation present in Bitcoinj as slush says. >Proper Unicode handling is a serious issue however. You don't want >someone to move from one input method / machine to another and >suddenly find that their coins are inaccessible, because of an issue >of decomposed vs. compatibility forms or whatever. We generate the word list internally (12,18,24) and confirm it is entered correctly through a retyping operation. This will allow us to detect character encoding transpositions (e.g. u0032 vs u00a0) and alert the user before it becomes an issue. While English is the language of the first word list to be implemented, we would definitely integrate alternative non-English word lists to make life easier for the global community. In general the approach would be for the user to select their language (implying a locale) and then the word list to be selected from that locale if available with a fallback to English. This follows the same approach as resource bundles in Java. --001a11c2ca0c2b14f404f07819b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
MultiBit here.=C2=A0

>At least Trezor and bitco= inj (Multibit) seems to be going in this way,
>which is 100% of clien= ts which expressed interest in bip39 :-).
>
>slush

We'll be using the BIP39 implementation present in Bitcoinj as slush sa= ys.=C2=A0

>Proper Unicode handling is a serious issue however. You don't = want
>someone to move from one input method / machine to another and<= br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">&= gt;suddenly find that their coins are inaccessible, because of an issue
>of decomposed vs. compatibility forms or whatever.

We generate the word list internall= y (12,18,24) and confirm it is entered correctly through a retyping operati= on. This will allow us to detect character encoding transpositions (e.g. u0= 032 vs u00a0) and alert the user before it becomes an issue.

While= English is the language of the first word list to be implemented, we would= definitely integrate alternative non-English word lists to make life easie= r for the global community. In general the approach would be for the user t= o select their language (implying a locale) and then the word list to be se= lected from that locale if available with a fallback to English. This follo= ws the same approach as resource bundles in Java.


<= /div>
--001a11c2ca0c2b14f404f07819b2--