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.
On Fri, Oct 25, 2013 at 10:46 PM, Mike Caldwell <mcaldw...@swipeclock.com>wrote:
> 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
> 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
> 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).
> -----Original Message-----
> From: Gregory Maxwell [mailto:gmaxw...@gmail.com]
> Sent: Friday, October 25, 2013 2:05 PM
> To: Mike Caldwell
> Cc: email@example.com
> Subject: Re: [Bitcoin-development] BIP 38
> On Fri, Oct 25, 2013 at 11:50 AM, Mike Caldwell <mcaldw...@swipeclock.com>
> > 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
> the latest Intel processors and coprocessors. See abstracts and register >
> Bitcoin-development mailing list
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
Bitcoin-development mailing list