Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.41 as permitted sender)
	client-ip=209.85.214.41; envelope-from=laanwj@gmail.com;
	helo=mail-bk0-f41.google.com; 
MIME-Version: 1.0
In-Reply-To: <B09A5DE3EF411243BB3328232CD25A5D99898977D9@MAILR023.mail.lan>
References: <B09A5DE3EF411243BB3328232CD25A5D998989775B@MAILR023.mail.lan>
	<CAAS2fgR0zH6JZWm-qLR3HcTC_m5o4N7V4wnGMM01q4yiS4CDwQ@mail.gmail.com>
	<B09A5DE3EF411243BB3328232CD25A5D99898977D9@MAILR023.mail.lan>
Date: Fri, 8 Nov 2013 16:41:00 +0100
Message-ID: <CA+s+GJBvVOYcu8_1XfO_B155qn5+3nVfzx0oCU_+KXWm=Yj3Vw@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Mike Caldwell <mcaldwell@swipeclock.com>
Content-Type: multipart/alternative; boundary=089e013a295687760704eaac3582
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 38
Precedence: list

--089e013a295687760704eaac3582
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Mike,

I tried (and eventually succeded) to implement BIP 0038 today in Python and
have a few comments on your BIP,

- The BIP does not describe how flag 0x04 (lotsequence_present) should
exactly be used in decoding (it does not indicate how ownersalt /
ownerentropy is handled differently). I figured this out eventually from
the C# and JS implementations.

- Under "Now we will encrypt seedb. Derive a second key from passpoint
using scrypt" it says "Split the result into two 16-byte halves and call
them derivedhalf1 and derivedhalf2.". This should be two *32-byte* halves
as the results is 64 bytes.

Regards,
Wladimir



On Fri, Oct 25, 2013 at 10:46 PM, Mike Caldwell <mcaldwell@swipeclock.com>w=
rote:

> Gregory,
>
> No problem, thanks for providing the IRC recap, and glad I've finally mad=
e
> "radio contact" with the list.  Perhaps there can be some long overdue
> discussion on the topic.
>
> I see Kogelman's improvements to my proposal as being of merit and may
> very well be sufficient to supersede what I've originally proposed.  I
> suppose the main thing I'm wanting to ensure is that the identity of my
> original proposal is maintained.  Regardless of whether a paper wallet or
> physical bitcoin with a single address is poor form or whether my proposa=
l
> is rejected or superseded, I hope there can be a consensus that "BIP38" c=
an
> continue to be understood to mean "Password-protected private key proposa=
l
> by Mike Caldwell", and that it can appear in the lists of BIPs alongside
> others.
>
> Regarding "BIP 22"... I in fact did not originally attempt to post to the
> list over what I had created and called BIP 22 once upon a time, I
> literally just created a wiki entry contrary to advice in BIP 1 that I ha=
d
> not read at the time.  I recognize it's totally legitimate to feel and ac=
t
> upon the appearance that BIP 38 was created in a similar shortcut fashion=
.
>  Certainly, the next thing I propose will be in the form of a draft outsi=
de
> the BIP "numberspace" and I won't solicit a BIP number without an
> established consensus in the future.  That said, I'm asking for BIP 38 to
> stand and be recognized as in existence, so as to not confuse those who
> call it by that name and who have already chosen to do something with it
> (whether that's to implement it, or to draft improvements to it like
> Kogelman).
>
> If I did BIP 38 over again, there's a couple shortcomings of my own that =
I
> wouldn't mind seeing addressed in another iteration, and the right venue
> for that may very well be to contribute to Kogelman's work.  My particula=
r
> improvements might include wanting the ability to outsource the
> computationally expensive step to another service at a minimized risk to
> the user, potentially the ability to have special-purpose "encrypted
> minikeys" (sort of how ARM has Thumb for places where the tradeoff makes
> sense), and a typo check with better privacy (I currently use
> sha256(address)[0...3] which may unintentionally reveal the bitcoin
> address, if it's funded, to someone who has the encrypted key but doesn't
> know the password).
>
> mike
>
>
>
> -----Original Message-----
> From: Gregory Maxwell [mailto:gmaxwell@gmail.com]
> Sent: Friday, October 25, 2013 2:05 PM
> To: Mike Caldwell
> Cc: bitcoin-development@lists.sourceforge.net
> Subject: Re: [Bitcoin-development] BIP 38
>
> On Fri, Oct 25, 2013 at 11:50 AM, Mike Caldwell <mcaldwell@swipeclock.com=
>
> wrote:
> > I have noticed that there was a recent change to BIP 0038
> > (Password-Protected Private Key) on the Wiki, which is a proposal I
> > wrote in late 2012.  Gregory, it looks to me as though you have made
> > this change, and I=E2=80=99m hoping for your help here.  The change sug=
gests
> > that the number was never assigned, and that there has been no
> > discussion regarding the proposal on this list.
>
> Greetings, (repeating from our discussion on IRC)
>
> No prior messages about your proposal have made it to the list, and no
> mention of the assignment had been made in the wiki.
>
> The first I ever heard of this scheme was long after you'd written the
> document when I attempted to assign the number to something else then
> noticed something existed at that name.
>
> Since you had previously created BIP documents without public discussion
> (e.g. "BIP 22"
> https://en.bitcoin.it/wiki/OP_CHECKSIGEX_DRAFT_BIP [...] Or, I wonder did
> your emails just get eaten that time too?), I'd just assumed something
> similar had happened here.
>
> I didn't take any action at the time I first noticed it, but after someon=
e
> complained about bitcoin-qt "not confirming with BIP38" to me today it wa=
s
> clear to me that people were confusing this with something that was
> "officially" (as much as anything is) supported, so I moved the document
> out.  (I've since moved it back, having heard from you that you thought
> that it had actually been assigned/announced).
>
> With respect to moving it forward: Having a wallet which can only a singl=
e
> address is poor form. Jean-Paul Kogelman has a draft proposal which is
> based on your BIP38 work though the encoding scheme is different, having
> been revised in response to public discussion.
>
> Perhaps efforts here can be combined?
>
> -------------------------------------------------------------------------=
-----
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register =
>
> http://pubads.g.doubleclick.net/gampad/clk?id=3D60135991&iu=3D/4140/ostg.=
clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--089e013a295687760704eaac3582
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello Mike,<div><br></div><div>I tried (and eventually suc=
ceded) to implement BIP 0038 today in Python and have a few comments on you=
r BIP,</div><div><br></div><div>- The BIP does not describe how flag 0x04 (=
lotsequence_present) should exactly be used in decoding (it does not indica=
te how ownersalt / ownerentropy is handled differently). I figured this out=
 eventually from the C# and JS implementations.</div>
<div><br></div>- Under &quot;Now we will encrypt seedb. Derive a second key=
 from passpoint using scrypt&quot; it says &quot;Split the result into two =
16-byte halves and call them derivedhalf1 and derivedhalf2.&quot;. This sho=
uld be two *32-byte* halves as the results is 64 bytes.<div>
<br><div>Regards,</div><div>Wladimir</div><div><br></div></div></div><div c=
lass=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Oct 25, 201=
3 at 10:46 PM, Mike Caldwell <span dir=3D"ltr">&lt;<a href=3D"mailto:mcaldw=
ell@swipeclock.com" target=3D"_blank">mcaldwell@swipeclock.com</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Gregory,<br>
<br>
No problem, thanks for providing the IRC recap, and glad I&#39;ve finally m=
ade &quot;radio contact&quot; with the list. =C2=A0Perhaps there can be som=
e long overdue discussion on the topic.<br>
<br>
I see Kogelman&#39;s improvements to my proposal as being of merit and may =
very well be sufficient to supersede what I&#39;ve originally proposed. =C2=
=A0I suppose the main thing I&#39;m wanting to ensure is that the identity =
of my original proposal is maintained. =C2=A0Regardless of whether a paper =
wallet or physical bitcoin with a single address is poor form or whether my=
 proposal is rejected or superseded, I hope there can be a consensus that &=
quot;BIP38&quot; can continue to be understood to mean &quot;Password-prote=
cted private key proposal by Mike Caldwell&quot;, and that it can appear in=
 the lists of BIPs alongside others.<br>

<br>
Regarding &quot;BIP 22&quot;... I in fact did not originally attempt to pos=
t to the list over what I had created and called BIP 22 once upon a time, I=
 literally just created a wiki entry contrary to advice in BIP 1 that I had=
 not read at the time. =C2=A0I recognize it&#39;s totally legitimate to fee=
l and act upon the appearance that BIP 38 was created in a similar shortcut=
 fashion. =C2=A0Certainly, the next thing I propose will be in the form of =
a draft outside the BIP &quot;numberspace&quot; and I won&#39;t solicit a B=
IP number without an established consensus in the future. =C2=A0That said, =
I&#39;m asking for BIP 38 to stand and be recognized as in existence, so as=
 to not confuse those who call it by that name and who have already chosen =
to do something with it (whether that&#39;s to implement it, or to draft im=
provements to it like Kogelman).<br>

<br>
If I did BIP 38 over again, there&#39;s a couple shortcomings of my own tha=
t I wouldn&#39;t mind seeing addressed in another iteration, and the right =
venue for that may very well be to contribute to Kogelman&#39;s work. =C2=
=A0My particular improvements might include wanting the ability to outsourc=
e the computationally expensive step to another service at a minimized risk=
 to the user, potentially the ability to have special-purpose &quot;encrypt=
ed minikeys&quot; (sort of how ARM has Thumb for places where the tradeoff =
makes sense), and a typo check with better privacy (I currently use sha256(=
address)[0...3] which may unintentionally reveal the bitcoin address, if it=
&#39;s funded, to someone who has the encrypted key but doesn&#39;t know th=
e password).<br>

<br>
mike<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Gregory Maxwell [mailto:<a href=3D"mailto:gmaxwell@gmail.com">gmaxwel=
l@gmail.com</a>]<br>
Sent: Friday, October 25, 2013 2:05 PM<br>
To: Mike Caldwell<br>
Cc: <a href=3D"mailto:bitcoin-development@lists.sourceforge.net">bitcoin-de=
velopment@lists.sourceforge.net</a><br>
Subject: Re: [Bitcoin-development] BIP 38<br>
<br>
On Fri, Oct 25, 2013 at 11:50 AM, Mike Caldwell &lt;<a href=3D"mailto:mcald=
well@swipeclock.com">mcaldwell@swipeclock.com</a>&gt; wrote:<br>
&gt; I have noticed that there was a recent change to BIP 0038<br>
&gt; (Password-Protected Private Key) on the Wiki, which is a proposal I<br=
>
&gt; wrote in late 2012. =C2=A0Gregory, it looks to me as though you have m=
ade<br>
&gt; this change, and I=E2=80=99m hoping for your help here. =C2=A0The chan=
ge suggests<br>
&gt; that the number was never assigned, and that there has been no<br>
&gt; discussion regarding the proposal on this list.<br>
<br>
Greetings, (repeating from our discussion on IRC)<br>
<br>
No prior messages about your proposal have made it to the list, and no ment=
ion of the assignment had been made in the wiki.<br>
<br>
The first I ever heard of this scheme was long after you&#39;d written the =
document when I attempted to assign the number to something else then notic=
ed something existed at that name.<br>
<br>
Since you had previously created BIP documents without public discussion (e=
.g. &quot;BIP 22&quot;<br>
<a href=3D"https://en.bitcoin.it/wiki/OP_CHECKSIGEX_DRAFT_BIP" target=3D"_b=
lank">https://en.bitcoin.it/wiki/OP_CHECKSIGEX_DRAFT_BIP</a> [...] Or, I wo=
nder did your emails just get eaten that time too?), I&#39;d just assumed s=
omething similar had happened here.<br>

<br>
I didn&#39;t take any action at the time I first noticed it, but after some=
one complained about bitcoin-qt &quot;not confirming with BIP38&quot; to me=
 today it was clear to me that people were confusing this with something th=
at was &quot;officially&quot; (as much as anything is) supported, so I move=
d the document out. =C2=A0(I&#39;ve since moved it back, having heard from =
you that you thought that it had actually been assigned/announced).<br>

<br>
With respect to moving it forward: Having a wallet which can only a single =
address is poor form. Jean-Paul Kogelman has a draft proposal which is base=
d on your BIP38 work though the encoding scheme is different, having been r=
evised in response to public discussion.<br>

<br>
Perhaps efforts here can be combined?<br>
---------------------------------------------------------------------------=
---<br>
October Webinars: Code for Performance<br>
Free Intel webinars can help you accelerate application performance.<br>
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most fr=
om<br>
the latest Intel processors and coprocessors. See abstracts and register &g=
t;<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60135991&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60135991&amp;iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>

--089e013a295687760704eaac3582--