summaryrefslogtreecommitdiff
path: root/b2/d88173c26b991c6882e5e698176c80988c5cdc
blob: b2d89e484e0cd75383720f7c79b3b1344d9d425b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
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 <g.rowe.froot@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <mailman.423274.1390277261.21953.bitcoin-development@lists.sourceforge.net>
	<300D31FC-FB89-4386-8DD9-F5FA792D0B40@bitsofproof.com>
Date: Tue, 21 Jan 2014 10:01:55 +0000
X-Google-Sender-Auth: ZV1O44gq97rmrOfwUGGVWmY9MuQ
Message-ID: <CAKm8k+0xa5-b=gjfZmH760TbYaQUVf5fGvVK9Jx5jwBGAvcX4g@mail.gmail.com>
From: Gary Rowe <g.rowe@froot.co.uk>
To: Bitcoin Development List <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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

<div dir=3D"ltr">MultiBit here.=C2=A0<div><br>&gt;At least Trezor and bitco=
inj (Multibit) seems to be going in this way,<br>&gt;which is 100% of clien=
ts which expressed interest in bip39 :-).<br>&gt;<br>&gt;slush<br><br><div =
class=3D"gmail_extra">
We&#39;ll be using the BIP39 implementation present in Bitcoinj as slush sa=
ys.=C2=A0</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra"><span style=3D"font-family:arial,sans-serif;font-size:12.80000019073486=
3px">&gt;Proper Unicode handling is a serious issue however. You don&#39;t =
want</span><br style=3D"font-family:arial,sans-serif;font-size:12.800000190=
734863px">
<span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=
>&gt;someone to move from one input method / machine to another and</span><=
br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"><s=
pan style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">&=
gt;suddenly find that their coins are inaccessible, because of an issue</sp=
an><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px=
">
<span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=
>&gt;of decomposed vs. compatibility forms or whatever.</span><br></div><di=
v class=3D"gmail_extra"><span style=3D"font-family:arial,sans-serif;font-si=
ze:12.800000190734863px"><br>
</span></div><div class=3D"gmail_extra">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.<br>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">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>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br><=
/div></div>

--001a11c2ca0c2b14f404f07819b2--