public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
To: Pavol Rusnak <stick@gk2.sk>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption
Date: Wed, 12 Mar 2014 19:26:39 +0000 (GMT)	[thread overview]
Message-ID: <44fcb02b-3784-45a6-816a-312c78d940cd@me.com> (raw)
In-Reply-To: <53208356.7010209@gk2.sk>

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



On Mar 12, 2014, at 08:55 AM, Pavol Rusnak <stick@gk2.sk> wrote:

On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:
Yes I am. There are some differences between BIP 39 and my proposal though.
- BIP 39 offers an easy list of words, no gnarly string of case sensitive letters and numbers.

Which is better IMO. I can't imagine anyone writing down a long Base58
encoded string.
 
That depends on your use case. A list of words is totally fine for someone to write down, a long string of case sensitive letters is easier to put into a QR code.


- BIP 39 only offers one fixed length of entropy, always 12 words, no option to increase or decrease the length.

Not true, BIP39 supports 12/18/24 words (= 128/192/256 bits of entropy).
 
I stand corrected.


- BIP 39 doesn't have a genesis date field, so no optimization during blockchain rescan.

This is nice addition, indeed. But we needed to limit the data as
possible in order not to increase the number of words needed to be noted
down.
 
My proposal didn't have this either initially, but it was deemed an essential feature for SPV clients.


- BIP 39 doesn't have password typo detection. No easy way to recover a password if you know most of it.

It has a detection. Not correction though.
 
If I understand the code correctly (and please correct me if I'm wrong), the validation only happens on the mnemonic list, not on the password:

"Described method also provides plausible deniability, because every passphrase generates a valid seed (and thus deterministic wallet) but only the correct one will make the desired wallet available"

So upon entering a password with a typo, the user will not be notified of an error, but be presented with a wallet balance of 0, after the blockchain has been scanned. I'm sorry, but that's not the kind of experience I would want to present to my users.


- BIP 39 does not have a user selectable KDF, only 2048 round PBKDF2-HMAC-SHA512.
- BIP 39 can't outsource the KDF computation to a 3rd party.

True, but having one or two solid options are better than having
gazillions of possible options.
 
5 defined KDFs out of a possible 32 is hardly "gazillions".

- BIP 39 wallet implementors can use their own word lists, breaking cross wallet compatibility.

True, but they are encouraged to use the list provided. Possibility to
outsource KDF outside of your "standard" breaks much more compatibility
than this.
 
Would you care to elaborate how optional outsourcing of the KDF breaks compatibility?

jp


[-- Attachment #2.1: Type: text/html, Size: 4502 bytes --]

  parent reply	other threads:[~2014-03-12 19:26 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <op.w0hd2nthyldrnw@laptop-air>
2013-07-19 18:15 ` [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet master seed with optional encryption Jean-Paul Kogelman
2013-07-22 13:14   ` Mike Hearn
2013-07-22 14:33     ` Jean-Paul Kogelman
2013-07-22 21:37     ` Jean-Paul Kogelman
2013-11-16  2:47       ` Gregory Maxwell
2013-11-16  3:09         ` Jean-Paul Kogelman
2013-12-26 11:48           ` Jean-Paul Kogelman
2014-03-12  3:17             ` [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key " Jean-Paul Kogelman
2014-03-12 13:11               ` Pavol Rusnak
2014-03-12 15:45                 ` Jean-Paul Kogelman
2014-03-12 15:55                   ` Pavol Rusnak
2014-03-12 16:49                     ` Gary Rowe
2014-03-12 18:00                       ` William Yager
2014-03-12 19:35                       ` Jean-Paul Kogelman
2014-03-12 19:41                         ` Gary Rowe
2014-03-12 19:26                     ` Jean-Paul Kogelman [this message]
2014-03-12 19:39                       ` Pavol Rusnak
2014-03-12 19:55                         ` William Yager
2014-03-12 20:04                           ` Pavol Rusnak
2014-03-12 20:10                             ` William Yager
2014-03-12 20:24                               ` Pavol Rusnak
2014-03-12 20:37                                 ` William Yager
2014-03-12 20:42                                   ` Pavol Rusnak
2014-03-12 20:49                                     ` William Yager
2014-03-12 21:08                                 ` Jean-Paul Kogelman
2014-03-12 21:15                                   ` William Yager
2014-04-22  0:05 William Yager
2014-04-24 19:39 ` William Yager

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=44fcb02b-3784-45a6-816a-312c78d940cd@me.com \
    --to=jeanpaulkogelman@me.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=stick@gk2.sk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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