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