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
184
185
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1YVv4i-0004ua-LX
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Mar 2015 04:50:24 +0000
X-ACL-Warn:
Received: from mail-wi0-f176.google.com ([209.85.212.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YVv4g-0002uk-Ob
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Mar 2015 04:50:24 +0000
Received: by wiwl15 with SMTP id l15so17171246wiw.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 11 Mar 2015 21:50:16 -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=ZITejQNzKYyhxX2wdHVd9Z4xgu+HXlIaLcjmSEXl+pw=;
b=fEgApvjVxdT7N8Q5r29RlVWyD45pgDkEFRJGeO9gOOqe+U1aN+oCJthZhru+gTPS8c
C6Fb2rCDBRRad9iXqE1qYB2EUUL9HegMeoqTinjGRd8WW9BafXYaahhwyIBjj3PGgpQZ
Rp9r6fjExJ61cvqTPUCvRlx/SXF+R+tgnRaLGh5exyLj/fvmJYAwtCzZKs+JlG0GS0hn
U3cqpWpcfxP8G0u2/Qj6ffHHTRP2M1GIum/oWBM/uCMvBGVBjQRHTkxm2R+CY4MSsz7N
mdPuzPGlVJtQIne1m0rp+Td8bQrmK/RL7hzId/bRIwzdhjY3qD/95eNbQZj1mU26u9uy
RCiQ==
X-Gm-Message-State: ALoCoQmxNJlfjCUXNATiTuwN7+oc5Z+24M0j3/pa1PxhqGaMiKnqWcRz33owsEVByLJyaKa+Wq0b
X-Received: by 10.194.63.16 with SMTP id c16mr84547678wjs.117.1426131858028;
Wed, 11 Mar 2015 20:44:18 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.28.180.138 with HTTP; Wed, 11 Mar 2015 20:43:47 -0700 (PDT)
In-Reply-To: <CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com>
References: <54F32EED.6040103@electrum.org>
<CANEZrP23buJF0ENfrKGRuzpQ3Uod09s-kRcb3CBw1-OmUxEyZg@mail.gmail.com>
<550057FD.6030402@electrum.org>
<CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com>
From: slush <slush@centrum.cz>
Date: Thu, 12 Mar 2015 04:43:47 +0100
X-Google-Sender-Auth: k1uRNVRVv7a9xZ_ptrtLdRZFKco
Message-ID: <CAJna-HhHkmOTqNW2R6=Cih+tM_Eeu5o1LBxA4ZNzp-6vm1p6fg@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=047d7b86da3acd14a705110f3247
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)
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1YVv4g-0002uk-Ob
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
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, 12 Mar 2015 04:50:24 -0000
--047d7b86da3acd14a705110f3247
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn <mike@plan99.net> wrote:
>
> - Electrum v2 with a version number but no date
> - myTREZOR with no version and no date and BIP44 key derivation. Some
> seeds I believe are now being generated with 24 words instead of 12.
> - MultiBit HD with no version and a date in a custom form that creates
> non-date-like codes you are expected to write down. I think BIP32 and BIP44
> are both supported (sorta).
> - GreenAddress with no version, no date and BIP32
> - Other bitcoinj based wallets, with no version and a date written
> down in normal human form, BIP32 only.
>
> To my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just
different scheme for key derivation (myTREZOR uses full BIP44, Multibit HD
uses BIP44 with first account only and GreenAddress uses another scheme
because it's multisig only wallet).
I disagree with the need of some version "magic flags" or creation date
stored in the mnemnonic, for those reasons:
a) If we fail in the way how mnemonic algo is defined, then some magic,
extra version flag won't save our asses, because we'll fail in meaning of
its meaning. Then it will be completely useless, as implementations cannot
rely on it. I know Thomas was sound proponent of this solution, but he was
unable to give any reasonable rules about who/how define meaning of version
flag.
b) "Creation date" is just a short-term hack. Considering that mnemonic
words are kind of cold storage (longterm storage), it *really* does not
make much difference in 2020, if your wallet has been created in 02/2014 or
10/2016. If there's performance issue with scanning of the blockchain,
creation date don't save our asses. We need to find another solution, and
as a bonus, we don't need users to know some weird numbers on top of
mnemonic itself.
> From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed
between wallet providers. There is some recommendations regarding the
wordlists to help with things such as predictive text, so mobile apps can
easily predict the word being typed in after a few chars etc.
Exactly! After some community feedback, we changed BIP39 algo to be one-way
only, which means you can use *any* wordlist to create the mnemonic, and
any other implementation can derive BIP32 root node even without knowing
that particular wordlist. Namely this has been changed because of
constructive criticism of ThomasV, and from discussion on the mailing list
I had a feeling that we've found a consensus. I was *very* surprised that
Electrum 2.0 started to use yet another algo "just because".
Shortly said, I think BIP39 does perfect job and there's no need to use
anything else.
Cheers,
Marek
--047d7b86da3acd14a705110f3247
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn <span dir=3D"ltr"><<a hr=
ef=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_ex=
tra"><ul><li>Electrum v2 with a version number but no date</li><li>myTREZOR=
with no version and no date and BIP44 key derivation. Some seeds I believe=
are now being generated with 24 words instead of 12.</li><li>MultiBit HD w=
ith no version and a date in a custom form that creates non-date-like codes=
you are expected to write down. I think BIP32 and BIP44 are both supported=
(sorta).</li><li>GreenAddress with no version, no date and BIP32</li><li>O=
ther bitcoinj based wallets, with no version and a date written down in nor=
mal human form, BIP32 only.</li></ul></div></div></div></blockquote><div>To=
my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just diff=
erent scheme for key derivation (myTREZOR uses full BIP44, Multibit HD uses=
BIP44 with first account only and GreenAddress uses another scheme because=
it's multisig only wallet).</div><div><br></div><div>I disagree with t=
he need of some version "magic flags" or creation date stored in =
the mnemnonic, for those reasons:</div><div><br></div><div>a) If we fail in=
the way how mnemonic algo is defined, then some magic, extra version flag =
won't save our asses, because we'll fail in meaning of its meaning.=
Then it will be completely useless, as implementations cannot rely on it. =
I know Thomas was sound proponent of this solution, but he was unable to gi=
ve any reasonable rules about who/how define meaning of version flag.</div>=
<div><br></div><div>b) "Creation date" is just a short-term hack.=
Considering that mnemonic words are kind of cold storage (longterm storage=
), it *really* does not make much difference in 2020, if your wallet has be=
en created in 02/2014 or 10/2016. If there's performance issue with sca=
nning of the blockchain, creation date don't save our asses. We need to=
find another solution, and as a bonus, we don't need users to know som=
e weird numbers on top of mnemonic itself.</div><div><br></div><div>>=A0=
<span style=3D"color:rgb(0,0,0);font-family:'Helvetica Neue-Light',=
'Helvetica Neue Light','Helvetica Neue',Helvetica,Arial,=
9;Lucida Grande',sans-serif;font-size:16px">From my interpretation of B=
IP39, wordlists DO NOT=A0REQUIRE to be fixed between wallet providers.=A0Th=
ere is some recommendations regarding the wordlists to help with things suc=
h as predictive text, so mobile apps can easily predict the word being type=
d in after a few chars etc.</span></div><div><span style=3D"color:rgb(0,0,0=
);font-family:'Helvetica Neue-Light','Helvetica Neue Light'=
,'Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-seri=
f;font-size:16px"><br></span></div><div><span style=3D"color:rgb(0,0,0);fon=
t-family:'Helvetica Neue-Light','Helvetica Neue Light','=
;Helvetica Neue',Helvetica,Arial,'Lucida Grande',sans-serif;fon=
t-size:16px">Exactly! After some community feedback, we changed BIP39 algo =
to be one-way only, which means you can use *any* wordlist to create the mn=
emonic, and any other implementation can derive BIP32 root node even withou=
t knowing that particular wordlist. Namely this has been changed because of=
constructive criticism of ThomasV, and from discussion on the mailing list=
I had a feeling that we've found a consensus. I was *very* surprised t=
hat Electrum 2.0 started to use yet another algo "just because".<=
/span></div><div><br></div><div><div>Shortly said, I think BIP39 does perfe=
ct job and there's no need to use anything else.</div></div><div><br></=
div><div>Cheers,</div><div>Marek</div></div></div></div>
--047d7b86da3acd14a705110f3247--
|
