summaryrefslogtreecommitdiff
path: root/0e/d3d81c22b89ae04348dd9f474fcf0609bb185e
blob: 58b79afb3cca89aae4d164bc6211a5ac67318c51 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
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 <thomasv1@gmx.de>) 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
	<bitcoin-development@lists.sourceforge.net>;
	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 <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
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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.