public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Wladimir <laanwj@gmail•com>
To: Mike Caldwell <mcaldwell@swipeclock•com>
Cc: "bitcoin-development@lists•sourceforge.net"
	<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 38
Date: Fri, 8 Nov 2013 16:41:00 +0100	[thread overview]
Message-ID: <CA+s+GJBvVOYcu8_1XfO_B155qn5+3nVfzx0oCU_+KXWm=Yj3Vw@mail.gmail.com> (raw)
In-Reply-To: <B09A5DE3EF411243BB3328232CD25A5D99898977D9@MAILR023.mail.lan>

[-- 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 --]

      reply	other threads:[~2013-11-08 15:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-25 18:50 Mike Caldwell
2013-10-25 20:05 ` Gregory Maxwell
2013-10-25 20:46   ` Mike Caldwell
2013-11-08 15:41     ` Wladimir [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+s+GJBvVOYcu8_1XfO_B155qn5+3nVfzx0oCU_+KXWm=Yj3Vw@mail.gmail.com' \
    --to=laanwj@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=mcaldwell@swipeclock$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox