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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <will.yager@gmail.com>) id 1WNpFk-0007RD-S0
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 19:55:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.173 as permitted sender)
client-ip=209.85.216.173; envelope-from=will.yager@gmail.com;
helo=mail-qc0-f173.google.com;
Received: from mail-qc0-f173.google.com ([209.85.216.173])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WNpFh-0000Jm-9a
for bitcoin-development@lists.sourceforge.net;
Wed, 12 Mar 2014 19:55:48 +0000
Received: by mail-qc0-f173.google.com with SMTP id r5so12013246qcx.32
for <bitcoin-development@lists.sourceforge.net>;
Wed, 12 Mar 2014 12:55:39 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.224.89.71 with SMTP id d7mr28618863qam.54.1394654139904;
Wed, 12 Mar 2014 12:55:39 -0700 (PDT)
Received: by 10.140.31.135 with HTTP; Wed, 12 Mar 2014 12:55:39 -0700 (PDT)
In-Reply-To: <5320B7F1.8060701@gk2.sk>
References: <44fcb02b-3784-45a6-816a-312c78d940cd@me.com>
<5320B7F1.8060701@gk2.sk>
Date: Wed, 12 Mar 2014 14:55:39 -0500
Message-ID: <CAG8oi1M_jnn9vzHjN5h+0x-dYEKudgJ-DEqOKrdv-sCDaFV3NA@mail.gmail.com>
From: William Yager <will.yager@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c3e16697f87a04f46e3875
X-Spam-Score: 0.6 (/)
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
(will.yager[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1WNpFh-0000Jm-9a
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:55:49 -0000
--001a11c3e16697f87a04f46e3875
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Mar 12, 2014 at 2:39 PM, Pavol Rusnak <stick@gk2.sk> wrote:
> On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote:
> > So upon entering a password 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 sorry, but that's not the kind of experience I would
> want to
> > present to my users.
>
> Sure, you can have either plausible deniability or typo checking, not
> both at the same time.
>
>
The proposed BIP uses a bloom filter, so it has both plausible deniability *and
*typo checking. The bloom filter is optimized for two elements and will
catch something like 99.9975% of typos, despite allowing two different
passwords.
> Would you care to elaborate how optional outsourcing of the KDF breaks
> > compatibility?
>
> I'm afraid one would end up with code generated in one client that is
> unusable in a different client, because the client's developer thought
> that using fancier algorithm instead of the proposed ones was a good idea.
>
>
This is clearly in violation of the spec. You could argue this about
anything in Bitcoin. What if a developer decided to replace SHA256 with
SHA3 in their implementation of a Bitcoin client? Obviously this would
cause issues.
Will
--001a11c3e16697f87a04f46e3875
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Mar 12, 2014 at 2:39 PM, Pavol Rusnak <span dir=3D=
"ltr"><<a href=3D"mailto:stick@gk2.sk" target=3D"_blank">stick@gk2.sk</a=
>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<div class=3D"">On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote:<br>
> So upon entering a password with a typo, the user will not be notified=
of an<br>
> error, but be presented with a wallet balance of 0, after the blockcha=
in has<br>
> been scanned. I'm sorry, but that's not the kind of experience=
I would want to<br>
> present to my users.<br>
<br>
</div>Sure, you can have either plausible deniability or typo checking, not=
<br>
both at the same time.<br>
<div class=3D""><br></div></blockquote><div><br></div><div>The proposed BIP=
uses a bloom filter, so it has both plausible deniability <i>and </i>typo =
checking. The bloom filter is optimized for two elements and will catch som=
ething like 99.9975% of typos, despite allowing two different passwords.</d=
iv>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"">
> Would you care to elaborate how optional outsourcing of the KDF breaks=
<br>
> compatibility?<br>
<br>
</div>I'm afraid one would end up with code generated in one client tha=
t is<br>
unusable in a different client, because the client's developer thought<=
br>
that using fancier algorithm instead of the proposed ones was a good idea.<=
br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>This is clearly in violation of the spec. You could argue thi=
s about anything in Bitcoin. What if a developer decided to replace SHA256 =
with SHA3 in their implementation of a Bitcoin client? Obviously this would=
cause issues.=A0</div>
<div><br></div><div>Will</div></div></div></div>
--001a11c3e16697f87a04f46e3875--
|
