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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
Precedence: list

--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&#39;=
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&#39;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&#39;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&#39;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&#39;m all ears.</div></div></div></div>

--001a11c3b7c4d6f442051106655c--