From: Thomas Voegtlin <thomasv1@gmx.de>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP0039: Final call
Date: Tue, 21 Jan 2014 01:00:43 +0100 [thread overview]
Message-ID: <52DDB8AB.4010103@gmx.de> (raw)
In-Reply-To: <CAJna-HgStwQQUiNZfJrFS1SduuzEEVrF=qmVe23uqZUNhHkOHA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]
Hi slush,
Thank you for your new proposal; it seems to be a compromise.
@Christophe Biocca:
If the wordlist becomes part of the standard, then we will run into
problems of collisions once users ask for wordlists in every language.
IMO the right approach is to implement checksums that do not depend
on the wordlist (eg the 'brute force' method, Hash(mnemonic||1) mod 2^k
== 0 )
this would also allow us to implement sipa's variable stretching proposal.
I understand this is not possible because of the computational
requirements of devices such as trezor.
I am leaning toward considering these devices as a nonstandard case,
instead of enforcing a given wordlist in the standard.
Thomas
Le 21/01/2014 00:18, slush a écrit :
>
> On Tue, Jan 21, 2014 at 12:06 AM, Christophe Biocca
> <christophe.biocca@gmail.com <mailto:christophe.biocca@gmail.com>> wrote:
>
> I remember the wordlist choice getting bikeshedded to death a
> month ago.
>
> I would just include the wordlist as part of the standard (as a
> recommendation) so that fully compliant implementations can correct a
> user's typos regardless of the original generator.
>
>
> That's exactly our attitude. We realized that have a community-wide
> agreement on the wordlist itself is simply imposible, so to reach at
> least some consensus we split the proposal to two parts - one what is
> essential to call itself a "bip39 compatible", i.e. converting the
> mnemonic to bip32 node and second which is optional, including our
> proposed wordlist, which has some advanced features like checksums
> etc. Now it is up to client developers to decide if they really insist
> on their superior wordlist or if they'll implement checksums following
> the full specification.
>
> Those who don't like it will have to deal with the compatibility
> concerns themselves, or get an alternate wordlist approved as a BIP.
>
> Odds are no one will go that route.
>
> At least Trezor and bitcoinj (Multibit) seems to be going in this way,
> which is 100% of clients which expressed interest in bip39 :-).
>
> slush
>
[-- Attachment #2: Type: text/html, Size: 4467 bytes --]
next prev parent reply other threads:[~2014-01-21 0:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-20 17:42 [Bitcoin-development] BIP0039: Final call slush
2014-01-20 19:55 ` Mike Hearn
2014-01-20 20:02 ` Luke-Jr
2014-01-20 21:47 ` slush
2014-01-20 22:01 ` Mark Friedenbach
2014-01-20 22:05 ` Brooks Boyd
2014-01-20 22:35 ` Peter Todd
2014-01-20 23:06 ` Christophe Biocca
2014-01-20 23:18 ` slush
2014-01-21 0:00 ` Thomas Voegtlin [this message]
2014-01-24 9:05 ` Peter Todd
2014-01-24 16:47 ` Thomas Voegtlin
2014-01-20 23:14 ` Adam Back
2014-01-20 23:18 ` Mark Friedenbach
[not found] <mailman.423274.1390277261.21953.bitcoin-development@lists.sourceforge.net>
2014-01-21 5:43 ` Tamas Blummer
2014-01-21 10:01 ` Gary Rowe
2014-01-21 10:11 ` Mike Hearn
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=52DDB8AB.4010103@gmx.de \
--to=thomasv1@gmx.de \
--cc=bitcoin-development@lists.sourceforge.net \
/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