From: slush <slush@centrum•cz>
To: Thomas Voegtlin <thomasv1@gmx•de>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal to replace BIP0039
Date: Thu, 31 Oct 2013 11:41:27 +0100 [thread overview]
Message-ID: <CAJna-Hj+q7oyTj8SWiVESPt5Web-mLuDhv7yA8zF5wRD81aBXA@mail.gmail.com> (raw)
In-Reply-To: <52721F47.30206@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 3987 bytes --]
Strange, I didn't receive the response from sipa in separate message, so
I'll respond to him at first place.
Le 26/10/2013 23:30, Pieter Wuille a écrit :
> 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.
Although many strange practices how to use whole bip32 space are possible,
I think that we may (should?) agree on some "good enough" way how to
discover already used addresses in bip32 space. I read Electrum sources
about bip32 and I see that Electrum still uses quite flat structure (fixed
amount of branches, indexes from 0 to n), which is of course very sane way.
So if I migrate seed to another (non-Electrum) software, I only need to
discover close neighbourhood of the path "0", similarly like Electrum is
doing with "gap limit" in plain old Electrum algorithm, except in two
dimensions (paths 0, 1, 2, 3, 4, 5, 0/0, 0/1, 0/2, 0/3, 0/4, 0/5, 1/0, 1/1,
...5/5 for gap limit "5"). I don't say such operation is cheap, but this
discovery needs to be done only during the import.
For the reason that I think this is the only sane algorithm of general use
of bip32 space, I still don't see why we do need some extra metadata. I
would understand this if Electrum will use for some strange reason
addresses in higher address space like 2^32-1 or so, but this is not going
to happen at least in Electrum.
> 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.
Well, I can imagine that the bip32 compatible software will do full scan of
address space using some gap factor (actually I think "5" is too low by
default) or it can ask for wallet metadata like which software used such
tree before, to speedup scanning process.
I see that Thomas wants to make this automatic and hidden to user and
generally I agree that hiding the compexity to user is a good practice, but
actually this particular situation sounds to me as an exact oposite of
original statement "no metadata in mnemonic".
> 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',
ECDSA has one very nice option - (almost) any random data can be used as a
private key. There are very nice schemas possible by using this feature and
requiring private key to be specially crafted just because the user wanted
to use mnemonic schema is very strong limitation to me.
To be specific, we (in cooperation with / inspired by Timo Hanke) developed
method how to prove that the seed generated by Trezor has been created
using combination of computer-provided entropy and device-provided entropy,
without leaking full private information to other computer, just because we
want Trezor to be blackbox-testable and fully deterministic (seed
generation is currently the only operation which uses any source of RNG).
To limit the complexity of such algorithm it is better to produce plain
seed (128, 192 or 256 bits, depends on settings) and then transform the
result of such "deterministic seed" to mnemonic, so for us the
bi-directionality is quite strong requirement. *Maybe* it would be possible
to combine such algorithm and one-way mnemonic together, but it would
complicate the design and I'm sure you understand that we want to keep
things as clear and simple as possible, especially while handling with seed
generation.
> I would strongly prefer if it had at least some strengthening built-in, to
> decrease the impact of worst-case situations.
Agree (hardening is default in bip39).
Marek
[-- Attachment #2: Type: text/html, Size: 5013 bytes --]
next prev parent reply other threads:[~2013-10-31 10:42 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
2013-10-31 10:41 ` slush [this message]
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=CAJna-Hj+q7oyTj8SWiVESPt5Web-mLuDhv7yA8zF5wRD81aBXA@mail.gmail.com \
--to=slush@centrum$(echo .)cz \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=thomasv1@gmx$(echo .)de \
/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