Re: [Bitcoin-development] BIP 38

[Wladimir <laanwj@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5982 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 7082 bytes --]