Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VeoBI-0000JE-DG for bitcoin-development@lists.sourceforge.net; Fri, 08 Nov 2013 15:41:08 +0000 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; Received: from mail-bk0-f41.google.com ([209.85.214.41]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VeoBG-0008It-Oo for bitcoin-development@lists.sourceforge.net; Fri, 08 Nov 2013 15:41:08 +0000 Received: by mail-bk0-f41.google.com with SMTP id na10so954696bkb.14 for ; Fri, 08 Nov 2013 07:41:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.204.108.73 with SMTP id e9mr34719bkp.51.1383925260176; Fri, 08 Nov 2013 07:41:00 -0800 (PST) Received: by 10.204.71.206 with HTTP; Fri, 8 Nov 2013 07:41:00 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Nov 2013 16:41:00 +0100 Message-ID: From: Wladimir To: Mike Caldwell Content-Type: multipart/alternative; boundary=089e013a295687760704eaac3582 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: doubleclick.net] -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 (laanwj[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1VeoBG-0008It-Oo Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] BIP 38 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 15:41:08 -0000 --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 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 > 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
Hello Mike,

I tried (and eventually suc= ceded) to implement BIP 0038 today in Python and have a few comments on you= r BIP,

- 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.

- 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 sho= uld be two *32-byte* halves as the results is 64 bytes.

Regards,
Wladimir



On Fri, Oct 25, 201= 3 at 10:46 PM, Mike Caldwell <mcaldwell@swipeclock.com> wrote:
Gregory,

No problem, thanks for providing the IRC recap, and glad I've finally m= ade "radio contact" with the list. =C2=A0Perhaps there can be som= e 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. =C2= =A0I suppose the main thing I'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" can continue to be understood to mean "Password-prote= cted private key proposal 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 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'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 "numberspace" and I won't solicit a B= IP number without an established consensus in the future. =C2=A0That 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 im= provements to it like Kogelman).

If I did BIP 38 over again, there's a couple shortcomings of my own tha= t 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. =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 "encrypt= ed 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 th= e password).

mike



-----Original Message-----
From: Gregory Maxwell [mailto:gmaxwel= l@gmail.com]
Sent: Friday, October 25, 2013 2:05 PM
To: Mike Caldwell
Cc: bitcoin-de= velopment@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. =C2=A0Gregory, it looks to me as though you have m= ade
> this change, and I=E2=80=99m hoping for your help here. =C2=A0The chan= ge suggests
> 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 ment= ion 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 notic= ed 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 wo= nder did your emails just get eaten that time too?), I'd just assumed s= omething similar had happened here.

I didn't take any action at the time I first noticed it, but after some= one complained about bitcoin-qt "not confirming with BIP38" to me= today it was clear to me that people were confusing this with something th= at was "officially" (as much as anything is) supported, so I move= d the document out. =C2=A0(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 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.

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 fr= om
the latest Intel processors and coprocessors. See abstracts and register &g= t;
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D60135991&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--089e013a295687760704eaac3582--