From: Thomas Voegtlin <thomasv1@gmx•de>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Proposal to replace BIP0039
Date: Thu, 31 Oct 2013 10:13:43 +0100 [thread overview]
Message-ID: <52721F47.30206@gmx.de> (raw)
In-Reply-To: <CAPg+sBiuLJJV3pB-EF3O9sgB_Z3tuLhEg9k=A9mcxJvgy3UQSw@mail.gmail.com>
Indeed, I want to include a version number in the seed phrase because
there are
multiple ways to define the tree structure used with BIP32. It is
certainly too early
to make final decisions on that, or to achieve a common standard.
Also, I can imagine that bip32 itself might be superseeded in the future.
I understand that encapsulating a version number in the seed phrase might
not be as important for other wallets as it is for Electrum. So it is
probably not
necessary to propose another BIP for that. I will simply implement it
for Electrum,
and I will try to do it in such a way that other wallets can use the
same format.
The other question we might be solving is strenghtening (your proposal).
I consider
that this is not a strong requirement for Electrum, because it does not
let the user
choose their seed phrase. However, if a few bits of the seed phrase are
allocated
for metadata, then I guess strenghtening can be part of it. That's
another good
reason to have a version number encapsulated in the seed.
I too wonder why the transformation needs to be bidirectional in bip39.
Le 26/10/2013 23:30, Pieter Wuille a écrit :
> Let's first try to agree on what we are solving.
>
> It seems that Thomas wants - in addition to the cryptographic data -
> to encode the tree structure, or at least version information about
> what features are used in it, inside the seed.
>
> I'm not sure whether we're ready to standardize on something like that
> yet, not having established best practices regarding different wallet
> structures. I do think we first need to see what possibilities and
> developments are possible related to it.
>
> In addition, information about the wallet structure is strictly less
> secret than the key data - it is even less confidential than address
> book data, transaction annotations, labels and comments and
> bookkeeping information. It could be backed up anywhere and everywhere
> without any repercussions, as far as I can see. I understand that in
> the case of Electrum, there is a strong reason to want this
> encapsulated together with the seed, but it's not really a requirement
> for most wallets.
> (if really needed, any key derivation scheme that starts from random
> strings can be augmented with metadata by enforcing property-bits on a
> hash of the string (so not of the output), as this data doesn't need
> protection from brute-forcing).
>
> Regarding other requirements, I wonder why we want the transformation
> to be bidirectional? If it is just about generating master seeds, one
> direction should be enough, and allows far nicer properties w.r.t.
> security. If we do settle on a standard for 'brainwallets', I would
> strongly prefer if it had at least some strengthening built-in, to
> decrease the impact of worst-case situations.
> If the reason is backward-compatibility, I think that any client that
> supports seeds already can just keep supporting whatever they
> supported before. Only if it matches both encoding schemes (as
> mentioned before) there is a potential collision (and in that case,
> the user could just be asked).
>
next prev parent reply other threads:[~2013-10-31 9:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-24 17:29 thomasV1
2013-10-24 18:09 ` slush
2013-10-25 9:27 ` Thomas Voegtlin
2013-10-24 18:54 ` slush
2013-10-26 15:24 ` Thomas Voegtlin
2013-10-26 20:47 ` slush
2013-10-26 21:30 ` Pieter Wuille
2013-10-31 9:13 ` Thomas Voegtlin [this message]
2013-10-31 10:41 ` slush
2013-10-31 11:07 ` Peter Todd
2013-11-02 9:44 ` Thomas Voegtlin
2013-11-03 6:41 ` Timo Hanke
2013-11-03 7:03 ` Thomas Voegtlin
2013-11-03 7:40 ` Timo Hanke
2013-11-03 8:39 ` Thomas Voegtlin
2013-11-04 15:10 ` Timo Hanke
2013-11-16 23:41 ` Pavol Rusnak
2013-11-16 23:49 ` Pavol Rusnak
2013-11-17 0:42 ` Timo Hanke
2013-11-17 0:49 ` Pavol Rusnak
2013-10-31 11:11 ` slush
2013-10-31 11:18 ` slush
2013-11-02 10:10 ` Thomas Voegtlin
2013-10-24 21:55 ` Luke-Jr
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=52721F47.30206@gmx.de \
--to=thomasv1@gmx$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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