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; 
Message-ID: <526A397C.2080006@gmx.de>
Date: Fri, 25 Oct 2013 11:27:24 +0200
From: Thomas Voegtlin <thomasv1@gmx.de>
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: <trinity-ba3941a0-f758-4372-b431-c64e9b44328a-1382635758149@3capp-gmx-bs09>
	<CAJna-HhzGmdoaaoFkp8tBeKCZ4DhDpNO43wzzk_ke7-kH2smbg@mail.gmail.com>
In-Reply-To: <CAJna-HhzGmdoaaoFkp8tBeKCZ4DhDpNO43wzzk_ke7-kH2smbg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Proposal to replace BIP0039
Precedence: list


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.