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; 
MIME-Version: 1.0
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
Subject: Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet
 root key with optional encryption
Precedence: list

--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">&lt;<a href=3D"mailto:stick@gk2.sk" target=3D"_blank">stick@gk2.sk</a=
>&gt;</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>
&gt; So upon entering a password with a typo, the user will not be notified=
 of an<br>
&gt; error, but be presented with a wallet balance of 0, after the blockcha=
in has<br>
&gt; been scanned. I&#39;m sorry, but that&#39;s not the kind of experience=
 I would want to<br>
&gt; 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"">
&gt; Would you care to elaborate how optional outsourcing of the KDF breaks=
<br>
&gt; compatibility?<br>
<br>
</div>I&#39;m afraid one would end up with code generated in one client tha=
t is<br>
unusable in a different client, because the client&#39;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--