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 wrote: > Gregory, > > No problem, thanks for providing the IRC recap, and glad I've finally made > "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 proposal > is rejected or superseded, I hope there can be a consensus that "BIP38" can > continue to be understood to mean "Password-protected 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 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 had > not read at the time. I recognize it's totally legitimate to feel and act > 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 outside > 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 particular > 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’m hoping for your help here. The change 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 > 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 someone > complained about bitcoin-qt "not confirming with BIP38" to me today it was > 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 single > 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=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >