Date: Thu, 12 Mar 2015 02:38:29 +0000 (UTC)
From: Thy Shizzle <thashiznets@yahoo.com.au>
To: "c1.sf-bitcoin@niftybox.net" <c1.sf-bitcoin@niftybox.net>
Message-ID: <190821851.4415282.1426127909995.JavaMail.yahoo@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_4415281_641691130.1426127909992"
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
Precedence: list
Reply-To: Thy Shizzle <thashiznets@yahoo.com.au>

------=_Part_4415281_641691130.1426127909992
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Right you are!
I saw Thomas's email about Electrum 2.0 not supporting BIP39.
It seems he had the idea that the wordlist was a strict requirement yet it =
is not, it is unfortunate that Electrum did not go the route of BIP39. The =
wordlist is irrelevant and merely used to help build mnemonics.
Also as I've shown, you can work a version into it, I was going to actually=
 propose it to the BIP39 authors but didn't think it was an issue.
I think BIP39 is fantastic.
I think Electrum 2.0 (And everyone)=C2=A0should use BIP39=C2=A0 On 2015-03-=
11 06:21 PM, Thy Shizzle wrote:
> Hmmmm I don't think it's fair to say that there has been a failure to
> standardise. From what I read earlier among the wallets, mostly it came
> down to if a version was noted and the date. Assuming no date is
> provided, it just means you are scanning the block chain from day 0 for
> transactions right? Hardly a big deal as you will still recover funds rig=
ht?

Unfortunately there's more incompatibility than just the date issue:

* seed: some follow BIP39, and some roll their own
* HD structure: some follow BIP44, some BIP32 derivation, and some roll
their own

So actually very few wallets are seed-compatible, even ignoring the date
question.

>=20
> Version right now is irrelevant as there is only one version of BIP39
> currently, probably this will change as 2048 iterations of HMACSHA512
> will likely need to be up scaled in the future, I thought about adding
> one extra word into the mnemonic to signify version, so if you have a 12
> word mnemonic then you have 12 words + 1 word version. Version 1 has no
> extra word, version 2 uses the first word on the list, version 3 uses
> the second word on the wordlist, so on and so forth. Least that's what I
> was thinking of doing if I ever had to record a version, won't effect
> anything because entropy increases in blocks of 3 words so one extra
> word can simply be thrown on the end.

That's a reasonable solution.

>=20
> So in summary I feel that date can be handled by assuming day 0, and
> version is not an issue yet but may become one and probably it is a good
> idea to think about standardising a version into BIP39, I have
> provided a seed idea for discussion.
>=20
> I don't think it is quite the doom and gloom I'm reading :)
>=20
>=20
> devrandom:
> "I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig.=C2=A0 The mobile has a key, the desktop=
 has
> a key and a third-party security oracle has a third key.=C2=A0 The oracle
> would have different security thresholds for countersigning the mobile.
>=20
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
>=20
> That said, I do agree that mnemonic phrases should be portable, and find
> it unfortunate that the ecosystem is failing to standardize on phrase
> handling."

--=20
devrandom / Miron
------=_Part_4415281_641691130.1426127909992
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial,=
 Lucida Grande, Sans-Serif;font-size:16px"><div id=3D"yui_3_16_0_1_14261226=
60566_21977" dir=3D"ltr">Right you are!</div><div id=3D"yui_3_16_0_1_142612=
2660566_21954" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1426122660566_=
21978" dir=3D"ltr">I saw Thomas's email about Electrum 2.0 not supporting B=
IP39.</div><div id=3D"yui_3_16_0_1_1426122660566_21952" dir=3D"ltr"><br></d=
iv><div id=3D"yui_3_16_0_1_1426122660566_21951" dir=3D"ltr">It seems he had=
 the idea that the wordlist was a strict requirement yet it is not, it is u=
nfortunate that Electrum did not go the route of BIP39. The wordlist is irr=
elevant and merely used to help build mnemonics.</div><div id=3D"yui_3_16_0=
_1_1426122660566_22047" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_14261=
22660566_22046" dir=3D"ltr">Also as I've shown, you can work a version into=
 it, I was going to actually propose it to the BIP39 authors but didn't thi=
nk it was an issue.</div><div id=3D"yui_3_16_0_1_1426122660566_21950" dir=
=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1426122660566_21964" dir=3D"ltr"=
>I think BIP39 is fantastic.</div><div id=3D"yui_3_16_0_1_1426122660566_219=
67" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1426122660566_21968" dir=
=3D"ltr">I think Electrum 2.0 (And everyone)&nbsp;should use BIP39</div><di=
v id=3D"yui_3_16_0_1_1426122660566_21949">&nbsp; </div><div id=3D"yui_3_16_=
0_1_1426122660566_21947">On 2015-03-11 06:21 PM, Thy Shizzle wrote:<br>
&gt; Hmmmm I don't think it's fair to say that there has been a failure to<=
br>
&gt; standardise. From what I read earlier among the wallets, mostly it cam=
e<br>
&gt; down to if a version was noted and the date. Assuming no date is<br>
&gt; provided, it just means you are scanning the block chain from day 0 fo=
r<br>
&gt; transactions right? Hardly a big deal as you will still recover funds =
right?<br>
<br>
Unfortunately there's more incompatibility than just the date issue:<br>
<br>
* seed: some follow BIP39, and some roll their own<br>
* HD structure: some follow BIP44, some BIP32 derivation, and some roll<br>
their own<br>
<br>
So actually very few wallets are seed-compatible, even ignoring the date<br=
>
question.<br>
<br>
&gt; <br>
&gt; Version right now is irrelevant as there is only one version of BIP39<=
br>
&gt; currently, probably this will change as 2048 iterations of HMACSHA512<=
br>
&gt; will likely need to be up scaled in the future, I thought about adding=
<br>
&gt; one extra word into the mnemonic to signify version, so if you have a =
12<br>
&gt; word mnemonic then you have 12 words + 1 word version. Version 1 has n=
o<br>
&gt; extra word, version 2 uses the first word on the list, version 3 uses<=
br>
&gt; the second word on the wordlist, so on and so forth. Least that's what=
 I<br>
&gt; was thinking of doing if I ever had to record a version, won't effect<=
br>
&gt; anything because entropy increases in blocks of 3 words so one extra<b=
r>
&gt; word can simply be thrown on the end.<br>
<br>
That's a reasonable solution.<br>
<br>
&gt; <br>
&gt; So in summary I feel that date can be handled by assuming day 0, and<b=
r>
&gt; version is not an issue yet but may become one and probably it is a go=
od<br>
&gt; idea to think about standardising a version into BIP39, I have<br>
&gt; provided a seed idea for discussion.<br>
&gt; <br>
&gt; I don't think it is quite the doom and gloom I'm reading :)<br>
&gt; <br>
&gt; <br>
&gt; devrandom:<br>
&gt; "I'd like to offer that the best practice for the shared wallet use ca=
se<br>
&gt; should be multi-device multi-sig.&nbsp; The mobile has a key, the desk=
top has<br>
&gt; a key and a third-party security oracle has a third key.&nbsp; The ora=
cle<br>
&gt; would have different security thresholds for countersigning the mobile=
.<br>
&gt; <br>
&gt; This way you can have the same overall wallet on all devices, but<br>
&gt; different security profiles on different keys.<br>
&gt; <br>
&gt; That said, I do agree that mnemonic phrases should be portable, and fi=
nd<br>
&gt; it unfortunate that the ecosystem is failing to standardize on phrase<=
br>
&gt; handling."<br>
<br>
-- <br>
devrandom / Miron</div></div></body></html>
------=_Part_4415281_641691130.1426127909992--