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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeanpaulkogelman@me.com>) id 1WNonf-0000X0-7e
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 19:26:47 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of me.com
designates 17.172.220.236 as permitted sender)
client-ip=17.172.220.236; envelope-from=jeanpaulkogelman@me.com;
helo=st11p02mm-asmtp001.mac.com;
Received: from st11p02mm-asmtpout001.mac.com ([17.172.220.236]
helo=st11p02mm-asmtp001.mac.com)
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WNone-0001kJ-2m for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 19:26:47 +0000
Received: from st11p02mm-spool001.mac.com ([17.172.220.246])
by st11p02mm-asmtp001.mac.com
(Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit
(built Aug
22 2013)) with ESMTP id <0N2C004A38OFVY90@st11p02mm-asmtp001.mac.com>
for bitcoin-development@lists.sourceforge.net; Wed,
12 Mar 2014 19:26:40 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.11.87,1.0.14,0.0.0000
definitions=2014-03-12_07:2014-03-12, 2014-03-12,
1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
adjust=0
reason=mlx scancount=1 engine=7.0.1-1401130000
definitions=main-1403120110
MIME-version: 1.0
Content-type: multipart/alternative;
boundary="Boundary_(ID_CKLxorly3Iyv6nT+FElvig)"
Received: from localhost ([17.172.220.223]) by st11p02mm-spool001.mac.com
(Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit
(built Aug
30 2012)) with ESMTP id <0N2C00F018OF6HC0@st11p02mm-spool001.mac.com>;
Wed, 12 Mar 2014 19:26:39 +0000 (GMT)
To: Pavol Rusnak <stick@gk2.sk>
From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
Date: Wed, 12 Mar 2014 19:26:39 +0000 (GMT)
X-Mailer: iCloud MailClient14A49 MailServer14A.15417
X-Originating-IP: [159.153.138.53]
Message-id: <44fcb02b-3784-45a6-816a-312c78d940cd@me.com>
In-reply-to: <53208356.7010209@gk2.sk>
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
X-Headers-End: 1WNone-0001kJ-2m
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet
root key with optional encryption
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: Wed, 12 Mar 2014 19:26:47 -0000
--Boundary_(ID_CKLxorly3Iyv6nT+FElvig)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: quoted-printable
=0A=0AOn Mar 12, 2014, at 08:55 AM, Pavol Rusnak <stick@gk2.sk> wrote:=0A=0A=
On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:=0AYes I am. There are so=
me differences between BIP 39 and my proposal though.=0A- BIP 39 offers an=
easy list of words, no gnarly string of case sensitive letters and number=
s.=0A=0AWhich is better IMO. I can't imagine anyone writing down a long Ba=
se58=0Aencoded string.=0A=A0=0AThat depends on your use case. A list of wo=
rds is totally fine for someone to write down, a long string of case sensi=
tive letters is easier to put into a QR code.=0A=0A=0A- BIP 39 only offers=
one fixed length of entropy, always 12 words, no option to increase or de=
crease the length.=0A=0ANot true, BIP39 supports 12/18/24 words (=3D 128/1=
92/256 bits of entropy).=0A=A0=0AI stand corrected.=0A=0A=0A- BIP 39 doesn=
't have a genesis date field, so no optimization during blockchain rescan.=
=0A=0AThis is nice addition, indeed. But we needed to limit the data as=0A=
possible in order not to increase the number of words needed to be noted=0A=
down.=0A=A0=0AMy proposal didn't have this either initially, but it was de=
emed an essential feature for SPV clients.=0A=0A=0A- BIP 39 doesn't have p=
assword typo detection. No easy way to recover a password if you know most=
of it.=0A=0AIt has a detection. Not correction though.=0A=A0=0AIf I under=
stand the code correctly (and please correct me if I'm wrong), the validat=
ion only happens on the mnemonic list, not on the password:=0A=0A"Describe=
d method also provides plausible deniability, because every passphrase gen=
erates a valid seed (and thus deterministic wallet) but only the correct o=
ne will make the desired wallet available"=0A=0ASo upon entering a passwor=
d with a typo, the user will not be notified of an error, but be presented=
with a wallet balance of 0, after the blockchain has been scanned. I'm so=
rry, but that's not the kind of experience I would want to present to my u=
sers.=0A=0A=0A- BIP 39 does not have a user selectable KDF, only 2048 roun=
d PBKDF2-HMAC-SHA512.=0A- BIP 39 can't outsource the KDF computation to a =
3rd party.=0A=0ATrue, but having one or two solid options are better than =
having=0Agazillions of possible options.=0A=A0=0A5 defined KDFs out of a p=
ossible 32 is hardly "gazillions".=0A=0A- BIP 39 wallet implementors can u=
se their own word lists, breaking cross wallet compatibility.=0A=0ATrue, b=
ut they are encouraged to use the list provided. Possibility to=0Aoutsourc=
e KDF outside of your "standard" breaks much more compatibility=0Athan thi=
s.=0A=A0=0AWould you care to elaborate how optional outsourcing of the KDF=
breaks compatibility?=0A=0Ajp=0A=0A=
--Boundary_(ID_CKLxorly3Iyv6nT+FElvig)
Content-type: multipart/related;
boundary="Boundary_(ID_62p/hF7SnXG+aZ/xu/4xqQ)"; type="text/html"
--Boundary_(ID_62p/hF7SnXG+aZ/xu/4xqQ)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable
<html><body><div><br><br>On Mar 12, 2014, at 08:55 AM, Pavol Rusnak <stick@gk2.sk&g=
t; wrote:<br><br></div><div><blockquote type=3D"cite"><div class=3D"msg-qu=
ote"><div class=3D"_stretch">On 03/12/2014 04:45 PM, Jean-Paul Kogelman wr=
ote:<br><blockquote class=3D"quoted-plain-text" type=3D"cite">Yes I am. Th=
ere are some differences between BIP 39 and my proposal though.</blockquot=
e><blockquote class=3D"quoted-plain-text" type=3D"cite"></blockquote><bloc=
kquote class=3D"quoted-plain-text" type=3D"cite">- BIP 39 offers an easy l=
ist of words, no gnarly string of case sensitive letters and numbers.</blo=
ckquote><br> Which is better IMO. I can't imagine anyone writing down a lo=
ng Base58<br> encoded string.<br> </div></div></blockquote><span> </s=
pan></div><div>That depends on your use case. A list of words is totally f=
ine for someone to write down, a long string of case sensitive letters is =
easier to put into a QR code.</div><div><br><blockquote type=3D"cite"><div=
class=3D"msg-quote"><div class=3D"_stretch"><br><blockquote class=3D"quot=
ed-plain-text" type=3D"cite">- BIP 39 only offers one fixed length of entr=
opy, always 12 words, no option to increase or decrease the length.</block=
quote><br> Not true, BIP39 supports 12/18/24 words (=3D 128/192/256 bits o=
f entropy).<br> </div></div></blockquote><span> </span></div><div>I s=
tand corrected.</div><div><br></div><div><blockquote type=3D"cite"><div cl=
ass=3D"msg-quote"><div class=3D"_stretch"><br><blockquote class=3D"quoted-=
plain-text" type=3D"cite">- BIP 39 doesn't have a genesis date field, so n=
o optimization during blockchain rescan.</blockquote><br> This is nice add=
ition, indeed. But we needed to limit the data as<br> possible in order no=
t to increase the number of words needed to be noted<br> down.<br> </div><=
/div></blockquote><span> </span></div><div>My proposal didn't have th=
is either initially, but it was deemed an essential feature for SPV client=
s.</div><div><br></div><div><blockquote type=3D"cite"><div class=3D"msg-qu=
ote"><div class=3D"_stretch"><br><blockquote class=3D"quoted-plain-text" t=
ype=3D"cite">- BIP 39 doesn't have password typo detection. No easy way to=
recover a password if you know most of it.</blockquote><br> It has a dete=
ction. Not correction though.<br> </div></div></blockquote><span> </s=
pan></div><div>If I understand the code correctly (and please correct me i=
f I'm wrong), the validation only happens on the mnemonic list, not on the=
password:</div><div><br></div><div><span style=3D"color: rgb(51, 51, 51);=
font-family: Helvetica, arial, freesans, clean, sans-serif; line-height: =
25.5px;">"Described method also provides plausible deniability, because ev=
ery passphrase generates a valid seed (and thus deterministic wallet) but =
only the correct one will make the desired wallet available"</span></div><=
div><span style=3D"color: rgb(51, 51, 51); font-family: Helvetica, arial, =
freesans, clean, sans-serif; line-height: 25.5px;"><br></span></div><div><=
span style=3D"color: rgb(51, 51, 51); font-family: Helvetica, arial, frees=
ans, clean, sans-serif; line-height: 25.5px;">So upon entering a password =
with a typo, the user will not be notified of an error, but be presented w=
ith a wallet balance of 0, after the blockchain has been scanned. I'm sorr=
y, but that's not the kind of experience I would want to present to my use=
rs.</span></div><div><br><blockquote type=3D"cite"><div class=3D"msg-quote=
"><div class=3D"_stretch"><br><blockquote class=3D"quoted-plain-text" type=
=3D"cite">- BIP 39 does not have a user selectable KDF, only 2048 round PB=
KDF2-HMAC-SHA512.</blockquote><blockquote class=3D"quoted-plain-text" type=
=3D"cite">- BIP 39 can't outsource the KDF computation to a 3rd party.</bl=
ockquote><br> True, but having one or two solid options are better than ha=
ving<br> gazillions of possible options.<br> </div></div></blockquote><spa=
n> </span></div><div>5 defined KDFs out of a possible 32 is hardly "g=
azillions".</div><div><br></div><div><blockquote type=3D"cite"><div class=3D=
"msg-quote"><div class=3D"_stretch"><blockquote class=3D"quoted-plain-text=
" type=3D"cite">- BIP 39 wallet implementors can use their own word lists,=
breaking cross wallet compatibility.</blockquote><br> True, but they are =
encouraged to use the list provided. Possibility to<br> outsource KDF outs=
ide of your "standard" breaks much more compatibility<br> than this.<br> <=
/div></div></blockquote><span> </span></div><div>Would you care to el=
aborate how optional outsourcing of the KDF breaks compatibility?</div><di=
v><br></div><div>jp</div><div><br></div></body></html>=
--Boundary_(ID_62p/hF7SnXG+aZ/xu/4xqQ)--
--Boundary_(ID_CKLxorly3Iyv6nT+FElvig)--
|
