Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W5Olw-0002aA-R3 for bitcoin-development@lists.sourceforge.net; Tue, 21 Jan 2014 00:00:52 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmx.de designates 212.227.17.22 as permitted sender) client-ip=212.227.17.22; envelope-from=thomasv1@gmx.de; helo=mout.gmx.net; Received: from mout.gmx.net ([212.227.17.22]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1W5Olu-0003f6-Qt for bitcoin-development@lists.sourceforge.net; Tue, 21 Jan 2014 00:00:52 +0000 Received: from [192.168.1.27] ([86.73.30.122]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M39zL-1VDiQ842n1-00swb9 for ; Tue, 21 Jan 2014 01:00:44 +0100 Message-ID: <52DDB8AB.4010103@gmx.de> Date: Tue, 21 Jan 2014 01:00:43 +0100 From: Thomas Voegtlin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <20140120223502.GA1055@petertodd.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080101000707070900040601" X-Provags-ID: V03:K0:kfmcVwh+QYFF0iZUOhiKnyOaIRWanQ8tpHUSRUD4RqntoBnSe1b sc9zF9oTlwAlSJf2haPIb9eICYOmKuBy/VfeXM070+0DZVPMce67xn/ip+q4XExvHz3rVkX Zsr12fE35E9oU8kRRUaM9Kx7cjnXA+Qo2uMj1/JCe1Gzuz+Nw/0dAB8W1q0EegMQJdmguQh VHFIbYS3PpQk3fa0ctliQ== X-Spam-Score: 0.8 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (thomasv1[at]gmx.de) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.17.22 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (thomasv1[at]gmx.de) 1.0 HTML_MESSAGE BODY: HTML included in message 1.0 FREEMAIL_REPLY From and body contain different freemails X-Headers-End: 1W5Olu-0003f6-Qt Subject: Re: [Bitcoin-development] BIP0039: Final call X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 00:00:53 -0000 This is a multi-part message in MIME format. --------------080101000707070900040601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 > > 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 > --------------080101000707070900040601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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> 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
 


--------------080101000707070900040601--