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


-----Original Message-----
From: Gregory Maxwell []
Sent: Friday, October 25, 2013 2:05 PM
To: Mike Caldwell
Subject: Re: [Bitcoin-development] BIP 38

On Fri, Oct 25, 2013 at 11:50 AM, Mike Caldwell <> 
> 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" [...] 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 >
Bitcoin-development mailing list

Reply via email to