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
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
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 <marek@palatinus.cz>) id 1VZQ4B-00015a-Lf
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Oct 2013 18:55:31 +0000
X-ACL-Warn:
Received: from mail-vc0-f170.google.com ([209.85.220.170])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VZQ49-0003Um-MC
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Oct 2013 18:55:31 +0000
Received: by mail-vc0-f170.google.com with SMTP id hv10so1593759vcb.15
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Oct 2013 11:55:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc:content-type;
bh=/F4hK1KznWQyytC/HsvKEwk1lLujWVRkGw5F0DlkehA=;
b=Sd0NuMbKUcwJCVOcm0LCwWDLKmaCkTayYICGWnAFgUDXGD13atj+zDa5uUy7d2wQ/P
CR/H/Q6XUxiB8DiCf5JLy4FLldmelNb3qYCotqpI1w5tdLZQEn4IoSqvY5ZSV7xA9NdB
SBVN+tMRlgMgBEAfcAkG1GSLLylGkrpIS1JSA6IKpzUoit9jEcJc9Q9+//cJH92qjJKo
4rj3j29y3rM+XBNDZtFTKBGaO5hCpmbmcpqADndByojE/yEbCwVz1cFr2FnOpswLMDUN
jiiuu9ktbij0ZzFkl6meETNMzuDM6I+ZsuF9ymkYT+ftqi00UALlt2NZo9WFyEf4zLIA
BmoA==
X-Gm-Message-State: ALoCoQmEP/UFRBjhx+MviJF1QU29Q508SRj90kgVJ/G40pOFlXlgfGvswH0B+aDP4AdymrkO/dxD
X-Received: by 10.58.208.130 with SMTP id me2mr2082498vec.13.1382640924007;
Thu, 24 Oct 2013 11:55:24 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.59.1.2 with HTTP; Thu, 24 Oct 2013 11:54:53 -0700 (PDT)
In-Reply-To: <trinity-ba3941a0-f758-4372-b431-c64e9b44328a-1382635758149@3capp-gmx-bs09>
References: <trinity-ba3941a0-f758-4372-b431-c64e9b44328a-1382635758149@3capp-gmx-bs09>
From: slush <slush@centrum.cz>
Date: Thu, 24 Oct 2013 20:54:53 +0200
X-Google-Sender-Auth: SGZo00djJhodQTxOC_MVznT_6F4
Message-ID: <CAJna-HjgpRhLdVGh+prx54VezHaH1vXGpPotW1Xkz2tiAiWrbg@mail.gmail.com>
To: "thomasV1@gmx.de" <thomasV1@gmx.de>
Content-Type: multipart/alternative; boundary=047d7bdc192c20c22604e9812d61
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(slush[at]centrum.cz)
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: gmx.de]
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1VZQ49-0003Um-MC
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
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: Thu, 24 Oct 2013 18:55:32 -0000
--047d7bdc192c20c22604e9812d61
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Oct 24, 2013 at 7:29 PM, <thomasV1@gmx.de> wrote:
>
> My initial problem was that BIP0039 is not backward compatible with
> Electrum. When trying to solve that, I realized that the seed encoding used
> in Electrum does not help, because it does not contain a version number
> information. However, BIP0039 suffers the same shortcoming: it does nothing
> to help a future replacement, it wants to be final. My first recommendation
> is to allocate a few bits of the mnemonic, in order to encode a "version
> number" along with the checksum bits.
>
>
On topic of "it wants to be final" and "it is incompatible with Electrum":
None of this is true. Firstly, it *is* possible to implement both algorithm
into the client at the same time, so user will be able to recover wallet
using Electrum or bip39 mnemonic and - what is worse - you already *know*
about this solution. Still you're spreading FUD about it on IRC, on emails
behind my back and here on mailing list.
The solution for Electrum client - as we discussed two weeks ago on IRC -
is that:
a) User type down the mnemonic (created with Electrum or BIP39)
b1) Only if *all* words are presented in both dictionaries and it has valid
BIP39 checksum (which is quite rare situation itself!), the mnemonic can be
consider to be both Electrum or BIP39.
b2) In most of cases we end up here, because the most common situation is
that with given words, only Electrum *or* BIP39 seed can be recovered.
----
c) Consider the mnemonic as Electrum. Create first few addresses and do a
lookup. If there are transactions in address history, this is Electrum
mnemonic.
d) If there were no used address in c), build seed using BIP39 and do the
same lookup. If there's history, this is BIP39 mnemonic.
e) If there are no history on both algorithm, then pick prefered one for
given client (it should not hurt which one, because first use of given
mnemonic will "freeze" given algorithm for next time of mnemonic recovery).
Well, because only Electrum uses some mnemonic algorithm to this date, such
decision tree need to be implemented only in Electrum. You cannot tell that
"it is too complicated" or "ambiguous", because you're using the same
algorithm of deciding between Electrum deterministic / BIP32.
I must admit that I'm quite annoyed of such discussion, because we already
discussed all this privately, you didn't tell me any reason why this should
not work and still I see that this is coming back as a boomerang.
slush
--047d7bdc192c20c22604e9812d61
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Thu, Oct 24, 2013 at 7:29 PM, <span dir=3D"ltr"><<a href=3D"mailto:t=
homasV1@gmx.de" target=3D"_blank">thomasV1@gmx.de</a>></span> wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
My initial problem was that BIP0039 is not backward compatible with Electru=
m. When trying to solve that, I realized that the seed encoding used in Ele=
ctrum does not help, because it does not contain a version number informati=
on. However, BIP0039 suffers the same shortcoming: it does nothing to help =
a future replacement, it wants to be final. My first recommendation is to a=
llocate a few bits of the mnemonic, in order to encode a "version numb=
er" along with the checksum bits.<br>
<br></blockquote><div>=A0</div><div style>On topic of "it wants to be =
final" and "it is incompatible with Electrum": None of this =
is true. Firstly, it *is* possible to implement both algorithm into the cli=
ent at the same time, so user will be able to recover wallet using Electrum=
or bip39 mnemonic and - what is worse - you already *know* about this solu=
tion. Still you're spreading FUD about it on IRC, on emails behind my b=
ack and here on mailing list.</div>
<div style><br></div><div style>The solution for Electrum client - as we di=
scussed two weeks ago on IRC - is that:</div><div style><br></div><div styl=
e>a) User type down the mnemonic (created with Electrum or BIP39)</div>
<div style>b1) Only if *all* words are presented in both dictionaries and i=
t has valid BIP39 checksum (which is quite rare situation itself!), the mne=
monic can be consider to be both Electrum or BIP39.</div><div style>b2) In =
most of cases we end up here, because the most common situation is that wit=
h given words, only Electrum *or* BIP39 seed can be recovered.</div>
<div style>----</div><div style>c) Consider the mnemonic as Electrum. Creat=
e first few addresses and do a lookup. If there are transactions in address=
history, this is Electrum mnemonic.</div><div style>d) If there were no us=
ed address in c), build seed using BIP39 and do the same lookup. If there&#=
39;s history, this is BIP39 mnemonic.</div>
<div style>e) If there are no history on both algorithm, then pick prefered=
one for given client (it should not hurt which one, because first use of g=
iven mnemonic will "freeze" given algorithm for next time of mnem=
onic recovery).</div>
<div style><br></div><div style>Well, because only Electrum uses some mnemo=
nic algorithm to this date, such decision tree need to be implemented only =
in Electrum. You cannot tell that "it is too complicated" or &quo=
t;ambiguous", because you're using the same algorithm of deciding =
between Electrum deterministic / BIP32.</div>
<div style><br></div><div style>I must admit that I'm quite annoyed of =
such discussion, because we already discussed all this privately, you didn&=
#39;t tell me any reason why this should not work and still I see that this=
is coming back as a boomerang.</div>
<div style><br></div><div style>slush</div></div></div></div>
--047d7bdc192c20c22604e9812d61--
|
