Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VZdg4-0005Kh-GT for bitcoin-development@lists.sourceforge.net; Fri, 25 Oct 2013 09:27:32 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmx.de designates 212.227.15.19 as permitted sender) client-ip=212.227.15.19; envelope-from=thomasv1@gmx.de; helo=mout.gmx.net; Received: from mout.gmx.net ([212.227.15.19]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1VZdg3-00036D-4P for bitcoin-development@lists.sourceforge.net; Fri, 25 Oct 2013 09:27:32 +0000 Received: from [192.168.1.27] ([86.73.30.143]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Metpl-1VKYYn3Bsn-00Obc6 for ; Fri, 25 Oct 2013 11:27:24 +0200 Message-ID: <526A397C.2080006@gmx.de> Date: Fri, 25 Oct 2013 11:27:24 +0200 From: Thomas Voegtlin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:5ezkZSp68X5jFv+6WnTXRC5tdTHxAMgLrKojt8HpcHCau8VJplW 9yjrNfXZSkFo0vCcRWmB2NGDs4Ws88Q8nSh7xdcS3roPx5qaFBQSce4pq/tLs8ZXGEHgaH2 TjjBlDE8zrTS4C1qajYDb48thExxANxEG0r1s+uz8fCZ1WusPzMRZy5N3oTP3QCYN8Q1L5h OT6ljyu6dmiUJfCyJ5PXQ== 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.15.19 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) 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bitcointalk.org] X-Headers-End: 1VZdg3-00036D-4P Subject: Re: [Bitcoin-development] Proposal to replace BIP0039 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, 25 Oct 2013 09:27:32 -0000 slush wrote : > Two years ago I proposed exactly this and you refused to add extra > information to mnemonic, because "it isn't necessary" and "it makes it > longer to mnemonization". What changed since then? I was wrong, and I fully acknowledge it. My concern was that adding extra information would make the mnemonic longer than 12 words. In addition, you proposed to allocate these extra bits for a checksum, not for metadata. However, a checksum does not really add any information, because Electrum checks the existence of a wallet directly from the blockchain. So, my feeling at that time was that adding extra bits would increase the risks (a longer seed is harder to memorize, increases the probability of mistakes, etc), and did not bring any real benefit. However, you showed since then how to solve this by using a slightly longer dictionary, and I do like your solution, I find it absolutely brilliant. In addition, I realize now that metadata (ie a "version number") is crucially needed, for the reasons mentioned in my previous post. > Hm, what exactly do you need to store about wallet structure? I lived > in opinion that everything is able to recover using CKD function to > generate new addresses and blockchain lookups for their balances. BIP32 gives a lot of freedom to wallet developers: it does not specify which branches of the HD tree shall be used for which purpose. However, if you want to recover a wallet from its mnemonic (a requirement for Electrum), then you need to know which branches to explore. In Electrum 1.9 I had to make some choices about branch allocation. However, the decisions that I made are certainly not final, so it is important to be able to change them in the future. Thus, this metadata needs to be added to the mnemonic. > Yes, that's true. It isn't possible to make everybody 100% happy. At > least I wanted to be constructive and asked you to replace the most > problematic words. No pull request from you so far. The solution I propose is very different from BIP39, and it does not require to predefine a dictionary. My proposal is actually somewhat similar to Pieter Wuille's proposal, which I discovered after his recent post. ( https://bitcointalk.org/index.php?topic=102349.0 ) > Yes, it was original idea. So far I don't think this is a problem. Of > course some words may have some meaning across languages, but it > should be easy to avoid them. There are tens of thousands words in > every language and we need to pick "only" 2048 words to wordlist. > ... > Are your worries about overlapping words across languages a real issue? No, there are not so many words that are frequent enough. Overlapping will be an issue, especially if we go for a 4096 words dictionary. > If I understand this well, it is basically one-way algorithm "mnemonic > -> seed", right? Seed cannot be printed out as mnemonic, because > there's hashing involved, but the bi-directionality has been the > original requirement for such algorithm (at least in Electrum and bip39). You are right, this encoding is not symmetric. Bi-directionality has never been a requirement for Electrum. May I ask why you need bi-directionality in Trezor? (the only reason I can think of is if you want to export a bip32 branch into another wallet, but this would create a very long mnemonic string) > Then, how is this different to picking 12 random words from dictionary > and hashing them together? I don't see any benefit in that "mining" > part of the proposal (except that it is lowering the entropy for given > length of mnemonic). it makes it possible to hash a utf8 string, and to retrieve the metadata from the hash. Thus we don't need to spend ages arguing about the best choice of a dictionary, and to set it in stone.