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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YVkDD-0004q3-5m
for bitcoin-development@lists.sourceforge.net;
Wed, 11 Mar 2015 17:14:27 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.49 as permitted sender)
client-ip=74.125.82.49; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f49.google.com;
Received: from mail-wg0-f49.google.com ([74.125.82.49])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YVkDB-0005kf-Ik
for bitcoin-development@lists.sourceforge.net;
Wed, 11 Mar 2015 17:14:27 +0000
Received: by wghl18 with SMTP id l18so10764642wgh.5
for <bitcoin-development@lists.sourceforge.net>;
Wed, 11 Mar 2015 10:14:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.223.103 with SMTP id qt7mr76243277wjc.35.1426094059612;
Wed, 11 Mar 2015 10:14:19 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Wed, 11 Mar 2015 10:14:19 -0700 (PDT)
In-Reply-To: <550057FD.6030402@electrum.org>
References: <54F32EED.6040103@electrum.org>
<CANEZrP23buJF0ENfrKGRuzpQ3Uod09s-kRcb3CBw1-OmUxEyZg@mail.gmail.com>
<550057FD.6030402@electrum.org>
Date: Wed, 11 Mar 2015 10:14:19 -0700
X-Google-Sender-Auth: Zk1m54WikTuGbR7PKIDbp7MoFnk
Message-ID: <CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Thomas Voegtlin <thomasv@electrum.org>
Content-Type: multipart/alternative; boundary=001a11c3b7c4d6f442051106655c
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YVkDB-0005kf-Ik
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: Wed, 11 Mar 2015 17:14:27 -0000
--001a11c3b7c4d6f442051106655c
Content-Type: text/plain; charset=UTF-8
Sigh. The wallet words system is turning into kind of a mess.
I thought the word list is in fact not a fixed part of the spec, because
the entropy is a hash of the words. But perhaps I'm misunderstanding
something.
The main problem regular SPV wallets have with BIP39 is that there is no
birth time included in the data. Therefore we must ask users to write down
a timestamp as well, so we know where to start rescanning the chain. It
sounds like the Electrum version doesn't fix this, so now we have at least
FIVE incompatible results from a 12 word list:
- 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.
I really hope we can recover from this somehow because otherwise all
wallets will have to provide the user with a complicated matrix of
possibilities and software combinations, and in practice many won't bother
so these word combinations will actually end up being wallet specific for
no particularly good reason, just very minor details like the presence or
absence of single fields.
It feels like we somehow fell flat on our faces just before the finishing
line. This is deeply unfortunate. Compatibility and UX consistency is
important!
Currently, I don't have any bright ideas for how to get everyone back onto
the same page with a fully compatible system that is acceptable to all. If
anyone else has suggestions, I'm all ears.
--001a11c3b7c4d6f442051106655c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sigh. The wallet words system is turning into kind of a me=
ss.<div><br></div><div>I thought the word list is in fact not a fixed part =
of the spec, because the entropy is a hash of the words. But perhaps I'=
m misunderstanding something.<br><div><div class=3D"gmail_extra"><br></div>=
</div><div class=3D"gmail_extra">The main problem regular SPV wallets have =
with BIP39 is that there is no birth time included in the data. Therefore w=
e must ask users to write down a timestamp as well, so we know where to sta=
rt rescanning the chain. It sounds like the Electrum version doesn't fi=
x this, so now we have at least FIVE incompatible results from a 12 word li=
st:</div><div class=3D"gmail_extra"><ul><li>Electrum v2 with a version numb=
er but no date</li><li>myTREZOR with no version and no date and BIP44 key d=
erivation. Some seeds I believe are now being generated with 24 words inste=
ad of 12.</li><li>MultiBit HD with no version and a date in a custom form t=
hat creates non-date-like codes you are expected to write down. I think BIP=
32 and BIP44 are both supported (sorta).</li><li>GreenAddress with no versi=
on, no date and BIP32</li><li>Other bitcoinj based wallets, with no version=
and a date written down in normal human form, BIP32 only.</li></ul><div>I =
really hope we can recover from this somehow because otherwise all wallets =
will have to provide the user with a complicated matrix of possibilities an=
d software combinations, and in practice many won't bother so these wor=
d combinations will actually end up being wallet specific for no particular=
ly good reason, just very minor details like the presence or absence of sin=
gle fields.</div><div><br></div><div>It feels like we somehow fell flat on =
our faces just before the finishing line. This is deeply unfortunate. Compa=
tibility and UX consistency is important!</div><div><br></div><div>Currentl=
y, I don't have any bright ideas for how to get everyone back onto the =
same page with a fully compatible system that is acceptable to all. If anyo=
ne else has suggestions, I'm all ears.</div></div></div></div>
--001a11c3b7c4d6f442051106655c--
|
