summaryrefslogtreecommitdiff
path: root/89/33bb0a348d9080fbeefb4105dd2648a6f9c5fe
blob: 68a1d79b777085edf48bb3d16d65d4af1a8df6df (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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
Return-Path: <weiji.g@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CBCD4BD4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 22 Nov 2018 17:25:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com
	[209.85.208.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C11B7782
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 22 Nov 2018 17:25:41 +0000 (UTC)
Received: by mail-ed1-f43.google.com with SMTP id b3so8323436ede.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 22 Nov 2018 09:25:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=ooOP+ETkN1TXkxjjSOXbd2dM1aTcYzmMpsgOH4ea0JE=;
	b=Wdx4NsQDLm7tSS4GyS9pq7y3eFG5HYVb7J90v6z7CCUSNd74Kjw6TvsfcKJxhhznVt
	QqvZDmlhYCMBOeT4zws582SKiQ3DLh4avSURpH0eoLy7vLS0pR/EV1/gCMLRIe1uyUIC
	CLy05yDeMt/92Bb7iStHMAhaURzAtUuxHgv3zmjRLN8sgTVaf7nZRhTC/sfuIS4y84Bt
	cSFXpgRvgDgugqMB8dtF0TNRASbdho4yTYvdXjqAqHtehihU57kF/hdnHC9Y5sEfIZNH
	HrCt/bcq0U1dgHUH9iVdDeZzwjqrcRv83YkPpoWjHmUfBVGQafDhvP8g8Bn/goTXvmLK
	wCFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=ooOP+ETkN1TXkxjjSOXbd2dM1aTcYzmMpsgOH4ea0JE=;
	b=ATcs4ux6HJmF8U6fCOFxvAv9/IohlxwZeDvB4Epmm2ywVWXAa78qTaQCljEonT2EMs
	txcPTpNM/QtZpk8m8Urk/vuBnGaivBa2ngKTBv//N8PvXU1Y/Z6DGe2iLq43PSV2ufx3
	OObIy+uZoxsPtWMR5t7AqWnl09LoVrTqkfPvkIWILsKRJ/f+ru/9uBykCHkD11ZCv0k8
	CQSZhdNK375lWJxIyQZhISB8HSekEhZige+cdg2ITV0b5+bijvcqX0h02vAieCoI3SRt
	bwQ8i58YUfURbydYLD9N9wjpcZ99Atv/xxpcr5SxV8aPXxUrbPMFeEMnpTnxhvMmaAiS
	NM1A==
X-Gm-Message-State: AGRZ1gLbI+D2M5U2DmbHE4bmMblcrNRQe2bUDvHakZl99t2kNs6qEteq
	siJX+/daJe2nFW8/r+GzOh/yuSU2TlqzgYlhwEmY13t+ju4=
X-Google-Smtp-Source: AJdET5fJvrDn1J4CydZJOHIdCtg/q5cdacWm9ldKkVc4ZKtfLrNStjQNepdvPVbXYK2nBdipE5h/lXICJfbKkrgLoMo=
X-Received: by 2002:a17:906:228d:: with SMTP id
	p13-v6mr8832371eja.159.1542907539925; 
	Thu, 22 Nov 2018 09:25:39 -0800 (PST)
MIME-Version: 1.0
References: <mailman.2299.1542895684.19477.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.2299.1542895684.19477.bitcoin-dev@lists.linuxfoundation.org>
From: Weiji Guo <weiji.g@gmail.com>
Date: Fri, 23 Nov 2018 01:25:07 +0800
Message-ID: <CA+ydi=Kr3ekGZ2t_2B53Fwm-Xoc0kgLNKVM72BUj1f=FxXwvqw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000d6b126057b442709"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 23 Nov 2018 04:04:44 +0000
Subject: [bitcoin-dev]  BIP- & SLIP-0039 -- better multi-language support
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Nov 2018 17:25:42 -0000

--000000000000d6b126057b442709
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Everyone,

Thank you very much in this thanks giving day for the detailed and well
thought out responses. :)

Steven Hatzakis via bitcoin-dev <bitcoin-dev at
lists.linuxfoundation.org
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>:

>* *Option 2*: Perhaps a revision is needed to how the BIP39 seed is
*>* generated in the first place, such as by hashing the entropy instead of=
 the
*>* words. Any thoughts on how viable that could be where the initial entro=
py
*>* is fed into the PBKDF2 function and not the words?*

If we go this direction, I'd suggest that we pull Shamir's Secret Sharing
into the game. Trezor's
SLIP-0039 proposal is great and has many security aspects already covered.
However, it does
not allow any language other than English and Trezor team clearly stated
that no other language
will be supported.

While I really want to keep the language independent design. So in the
revision, I'd like to see
a language id (allocated to each one having a defined wordlist) in the SSS
share, as well as
share id, threshold, index, share value, checksum etc.

Regarding checksum scheme, SLIP-0039 proposals a 3-word Reed-Solomon
design. It has a very
good error checking capability but not very good at providing hints to
error recovery. Trezor team
opposes to the idea of providing hints to users regarding how to fix an
error. This could lead to
difficulties for some vendors, and in small probability, confusions to
users (when there is a 2-word
error)

I do agree with Trezor team that it should be users' responsibility to
recover from a detected error.
However, there is a better way than solely rely on checksum. That is, as in
our revision, we can
support mnemonic in multiple languages simultaneously, why don't we use two
languages, or one
language + numbers to check each other? In Steven's example (language id,
share id, etc. skipped)
we could record a SSS share (assuming it is one of the shares just for the
sake of example) like:

>* *In English*: minimum fee sure ticket faculty banana gate purse caught
*>* valley globe shift
*>* *In Spanish*: mercado faja soledad tarea evadir aries gafas peine bu=CC=
=81ho
*>* tumor gerente reja*

Or

>* *In English*: minimum fee sure ticket faculty banana gate purse caught
*>* valley globe shift*

>* Word Indexes: 1128, 676, 1744, 1805, 653, 145, 770, 1396, 291, 1927,
794, 1582*


Then software will have to check checksum as well as to check if words
match each other. For
example, "minimum"'s index value in English wordlist should equal to "
*mercado*"'s in Spanish,
or should equal to 1128.

If any error is detected, combining the checksum value and dual-encoding
information, it is much
easier to figure out which word was handprinted incorrectly.

BTW, it is very error prone to handprint. Some study suggests about 0.9%
per word rate. See
http://panko.shidler.hawaii.edu/HumanErr/Basic.htm

Hotopf [1980]

W sample (written exam). Per word

0.9%

It is important to have an error recovery mechanism easy to understand and
implement.

Thanks,
Weiji

--000000000000d6b126057b442709
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Everyone,<div><br></div><div>Thank you=
 very much in this thanks giving day for the detailed and well thought out =
responses. :)</div><div><br></div><div><pre style=3D"white-space:pre-wrap;c=
olor:rgb(0,0,0)">Steven Hatzakis via bitcoin-dev &lt;<a href=3D"https://lis=
ts.linuxfoundation.org/mailman/listinfo/bitcoin-dev">bitcoin-dev at lists.l=
inuxfoundation.org</a>&gt;:</pre></div><div><pre style=3D"white-space:pre-w=
rap;color:rgb(0,0,0)">&gt;<i> *Option 2*: Perhaps a revision is needed to h=
ow the BIP39 seed is
</i>&gt;<i> generated in the first place, such as by hashing the entropy in=
stead of the
</i>&gt;<i> words. Any thoughts on how viable that could be where the initi=
al entropy
</i>&gt;<i> is fed into the PBKDF2 function and not the words?</i></pre>If =
we go this direction, I&#39;d suggest that we pull Shamir&#39;s Secret Shar=
ing into the game. Trezor&#39;s=C2=A0</div><div>SLIP-0039 proposal is great=
 and has many security aspects already covered. However, it does=C2=A0</div=
><div>not allow any language other than English and Trezor team clearly sta=
ted that no other language=C2=A0</div><div>will be supported.</div><div><br=
></div><div>While I really want to keep the language independent design. So=
 in the revision, I&#39;d like to see=C2=A0</div><div>a language id (alloca=
ted to each one having a defined wordlist) in the SSS share, as well as</di=
v><div>share id, threshold, index, share value, checksum etc.=C2=A0</div><d=
iv><br></div><div>Regarding checksum scheme, SLIP-0039 proposals a 3-word R=
eed-Solomon design. It has a very</div><div>good error checking capability =
but not very good at providing hints to error recovery. Trezor team=C2=A0</=
div><div>opposes to the idea of providing hints to users regarding how to f=
ix an error. This could lead to</div><div>difficulties for some vendors, an=
d in small probability, confusions to users (when there is a 2-word</div><d=
iv>error)</div><div><br></div><div>I do agree with Trezor team that it shou=
ld be users&#39; responsibility to recover from a detected error.</div><div=
>However, there is a better way than solely rely on checksum. That is, as i=
n our revision, we can=C2=A0</div><div>support mnemonic in multiple languag=
es simultaneously, why don&#39;t we use two languages, or one=C2=A0</div><d=
iv>language=C2=A0+ numbers to check each other? In Steven&#39;s example (la=
nguage id, share id, etc. skipped)=C2=A0</div><div>we could record a SSS sh=
are (assuming it is one of the shares just for the sake of example) like:</=
div><div><br></div><pre style=3D"white-space:pre-wrap;color:rgb(0,0,0)">&gt=
;<i> *In English*: minimum fee sure ticket faculty banana gate purse caught
</i>&gt;<i> valley globe shift
</i>&gt;<i> *In Spanish*: mercado faja soledad tarea evadir aries gafas pei=
ne bu=CC=81ho
</i>&gt;<i> tumor gerente reja</i></pre><pre style=3D"caret-color: rgb(0, 0=
, 0); text-size-adjust: auto;">Or<i style=3D"color:rgb(0,0,0);white-space:p=
re-wrap">
</i><pre style=3D"color:rgb(0,0,0);white-space:pre-wrap">&gt;<i> *In Englis=
h*: minimum fee sure ticket faculty banana gate purse caught
</i>&gt;<i> valley globe shift</i></pre><font color=3D"#000000"><span style=
=3D"white-space:pre-wrap">&gt;</span></font><i style=3D"color:rgb(0,0,0);wh=
ite-space:pre-wrap"> Word Indexes: 1128, 676, 1744, 1805, 653, 145, 770, 13=
96, 291, 1927, 794, 1582</i></pre><div><br><pre style=3D"white-space:pre-wr=
ap;color:rgb(0,0,0)"></pre>Then software will have to check checksum as wel=
l as to check if words match each other. For=C2=A0</div><div>example, &quot=
;minimum&quot;&#39;s index value in English wordlist should equal to &quot;=
<i style=3D"color:rgb(0,0,0);white-space:pre-wrap">mercado</i>&quot;&#39;s =
in Spanish,</div><div>or should equal to 1128.=C2=A0</div><div><br></div><d=
iv>If any error is detected, combining the checksum value and dual-encoding=
 information, it is much</div><div>easier to figure out which word was hand=
printed incorrectly.=C2=A0</div><div><br></div><div>BTW, it is very error p=
rone to handprint. Some study suggests about 0.9% per word rate. See</div><=
div><a href=3D"http://panko.shidler.hawaii.edu/HumanErr/Basic.htm">http://p=
anko.shidler.hawaii.edu/HumanErr/Basic.htm</a><br></div><div><table cellspa=
cing=3D"1" cellpadding=3D"2" class=3D"gmail-style2" style=3D"border-style:s=
olid;border-width:1px;font-family:-webkit-standard;width:600px"><tbody><tr>=
<td width=3D"33%" valign=3D"TOP" height=3D"25"><p><font face=3D"Arial">Hoto=
pf [1980]</font></p></td><td valign=3D"TOP" height=3D"25" style=3D"width:29=
8.953px"><p><font face=3D"Arial">W sample (written exam). Per word</font></=
p></td><td valign=3D"TOP" height=3D"25" class=3D"gmail-style1" style=3D"tex=
t-align:right;width:91.0469px"><p class=3D"gmail-style1"><font face=3D"Aria=
l">0.9%</font></p></td></tr></tbody></table></div><div><br></div><div>It is=
 important to have an error recovery mechanism easy to understand and imple=
ment.=C2=A0</div><div><br></div><div>Thanks,</div><div>Weiji</div></div></d=
iv>

--000000000000d6b126057b442709--