Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W6juj-0007jI-0t for bitcoin-development@lists.sourceforge.net; Fri, 24 Jan 2014 16:47:29 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmx.de designates 212.227.17.20 as permitted sender) client-ip=212.227.17.20; envelope-from=thomasv1@gmx.de; helo=mout.gmx.net; Received: from mout.gmx.net ([212.227.17.20]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1W6juh-0001LR-RV for bitcoin-development@lists.sourceforge.net; Fri, 24 Jan 2014 16:47:28 +0000 Received: from [192.168.1.27] ([86.73.30.122]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LqALY-1VbmsD2B60-00dneg for ; Fri, 24 Jan 2014 17:47:21 +0100 Message-ID: <52E29919.7030404@gmx.de> Date: Fri, 24 Jan 2014 17:47:21 +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> <52DDB8AB.4010103@gmx.de> <20140124090532.GB15398@savin> In-Reply-To: <20140124090532.GB15398@savin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:EIBOwCR1FtEy9X0F3FphuORIUKNnYexaCtTUlV9+SKvUJay981k EI5vkRbC4hic6/ZdZUKQSRk7EUsUU7Zs60zSuklf3+Vpm4/MD8cB+d1oXnJIMtOb1UPAVAx 4hun2eTiRVLGyGvdvzJqlzZ684ZQs64hFo3BTA9rYm1wfHkY2Tzxoxi7Kfnnx3+rCzXmm+t gV5Btxo/qzWcww++4z/+g== X-Spam-Score: -1.2 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.17.20 listed in list.dnswl.org] -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 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (thomasv1[at]gmx.de) X-Headers-End: 1W6juh-0001LR-RV 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: Fri, 24 Jan 2014 16:47:29 -0000 Le 24/01/2014 10:05, Peter Todd a écrit : > On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote: >> 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. > Is it? Surely the trezor can bruteforce, say, 8 bits == 0. How many > SHA256/sec can the trezor hardware do? Generating your seed is a > one-time thing after all - that taking 10-30s doesn't seem like a big > deal to me. > > Even a 1/256th "checksum" will really cut down on the number of mistakes > made and money lost. slush, correct me if I'm wrong, but I don't think that's the only reason: They want to generate a seed by combining entropy from the trezor device and from the user's computer; In addition, they want the computer to be able to check that the seed actually was derived from the entropy it provided, using only a master public key (the computer does not have access to the seed) This is why they designed bip39 that way. I think the new bip39 proposal could be used in Electrum as an option for trezor, but I am reluctant to make it default, because it imposes its own dictionary.