Date: Thu, 12 Mar 2015 05:12:47 +0000 (UTC)
From: Thy Shizzle <thashiznets@yahoo.com.au>
To: "slush@centrum.cz" <slush@centrum.cz>
Message-ID: <892666269.4459743.1426137167385.JavaMail.yahoo@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_4459742_498376856.1426137167380"
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_4459742_498376856.1426137167380
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes I agree with this sentiment.
As for the version, don't forget we can kinda "brute force" our way to dete=
rmine a version, because lets say there is 10 versions, we can generate the=
 seed for all 10 versions and then check to see which seed was in use (has =
transacted) and then use that seed. If no transactions are found, we could =
restore the wallet with the seed of the latest and greatest version. Not re=
ally any need to store the version, sure it may save some time but as Marek=
 rightly says, this is for restoration of a wallet from cold storage not an=
 everyday thing so the extra time to brute force the version etc is accepta=
ble as a trade off for not forcing the remembering of a version.
BIP39 is beautiful.
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn <mike@plan99.net> wrote:

  =20
   - Electrum v2 with a version number but no date
   - myTREZOR with no version and no date and BIP44 key derivation. Some se=
eds 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 n=
on-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 di=
fferent scheme for key derivation (myTREZOR uses full BIP44, Multibit HD us=
es BIP44 with first account only and GreenAddress uses another scheme becau=
se it's multisig only wallet).
I disagree with the need of some version "magic flags" or creation date sto=
red in the mnemnonic, for those reasons:
a) If we fail in the way how mnemonic algo is defined, then some magic, ext=
ra 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 unab=
le to give any reasonable rules about who/how define meaning of version fla=
g.
b) "Creation date" is just a short-term hack. Considering that mnemonic wor=
ds are kind of cold storage (longterm storage), it *really* does not make m=
uch difference in 2020, if your wallet has been created in 02/2014 or 10/20=
16. 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.
>=C2=A0From my interpretation of BIP39, wordlists DO NOT=C2=A0REQUIRE to be=
 fixed between wallet providers.=C2=A0There is some recommendations regardi=
ng the wordlists to help with things such as predictive text, so mobile app=
s 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 a=
ny other implementation can derive BIP32 root node even without knowing tha=
t particular wordlist. Namely this has been changed because of constructive=
 criticism of ThomasV, and from discussion on the mailing list I had a feel=
ing 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 any=
thing else.
Cheers,Marek
------=_Part_4459742_498376856.1426137167380
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_31668" dir=3D"ltr">Yes I agree with this sentiment.</div><div id=3D"y=
ui_3_16_0_1_1426122660566_31911" dir=3D"ltr"><br></div><div id=3D"yui_3_16_=
0_1_1426122660566_31917" dir=3D"ltr">As for the version, don't forget we ca=
n kinda "brute force" our way to determine a version, because lets say ther=
e is 10 versions, we can generate the seed for all 10 versions and then che=
ck to see which seed was in use (has transacted) and then use that seed. If=
 no transactions are found, we could restore the wallet with the seed of th=
e latest and greatest version. Not really any need to store the version, su=
re it may save some time but as Marek rightly says, this is for restoration=
 of a wallet from cold storage not an everyday thing so the extra time to b=
rute force the version etc is acceptable as a trade off for not forcing the=
 remembering of a version.</div><div id=3D"yui_3_16_0_1_1426122660566_31974=
" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1426122660566_31984" dir=3D=
"ltr">BIP39 is beautiful.</div><div id=3D"yui_3_16_0_1_1426122660566_31675"=
><br></div><div id=3D"yui_3_16_0_1_1426122660566_31669">On Wed, Mar 11, 201=
5 at 6:14 PM, Mike Hearn <span id=3D"yui_3_16_0_1_1426122660566_31667" dir=
=3D"ltr">&lt;<a tabindex=3D"-1" id=3D"yui_3_16_0_1_1426122660566_31666" hre=
f=3D"mailto:mike@plan99.net" target=3D"_parent"><font id=3D"yui_3_16_0_1_14=
26122660566_31665" color=3D"#0066cc">mike@plan99.net</font></a>&gt;</span> =
wrote:<br></div><blockquote id=3D"yui_3_16_0_1_1426122660566_31663" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div id=3D=
"yui_3_16_0_1_1426122660566_31662" dir=3D"ltr"><div id=3D"yui_3_16_0_1_1426=
122660566_31661"><div id=3D"yui_3_16_0_1_1426122660566_31660"><ul id=3D"yui=
_3_16_0_1_1426122660566_31659"><li id=3D"yui_3_16_0_1_1426122660566_31664">=
Electrum v2 with a version number but no date</li><li id=3D"yui_3_16_0_1_14=
26122660566_31658">myTREZOR with no version and no date and BIP44 key deriv=
ation. Some seeds I believe are now being generated with 24 words instead o=
f 12.</li><li id=3D"yui_3_16_0_1_1426122660566_31674">MultiBit HD with no v=
ersion 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 id=3D"yui_3_16_0_1_1426122660566_31828">GreenAddress with no vers=
ion, no date and BIP32</li><li id=3D"yui_3_16_0_1_1426122660566_31670">Othe=
r bitcoinj based wallets, with no version and a date written down in normal=
 human form, BIP32 only.</li></ul></div></div></div></blockquote><div id=3D=
"yui_3_16_0_1_1426122660566_31685">To my knowledge, myTREZOR, Multibit HD a=
nd GreenAddress uses BIP39, just different scheme for key derivation (myTRE=
ZOR uses full BIP44, Multibit HD uses BIP44 with first account only and Gre=
enAddress uses another scheme because it's multisig only wallet).</div><div=
 id=3D"yui_3_16_0_1_1426122660566_31652"><br></div><div id=3D"yui_3_16_0_1_=
1426122660566_31653">I disagree with the need of some version "magic flags"=
 or creation date stored in the mnemnonic, for those reasons:</div><div id=
=3D"yui_3_16_0_1_1426122660566_31654"><br></div><div id=3D"yui_3_16_0_1_142=
6122660566_31655">a) If we fail in the way how mnemonic algo is defined, th=
en 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 implement=
ations cannot rely on it. I know Thomas was sound proponent of this solutio=
n, but he was unable to give any reasonable rules about who/how define mean=
ing of version flag.</div><div id=3D"yui_3_16_0_1_1426122660566_31656"><br>=
</div><div id=3D"yui_3_16_0_1_1426122660566_31657">b) "Creation date" is ju=
st a short-term hack. Considering that mnemonic words are kind of cold stor=
age (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 performan=
ce issue with scanning of the blockchain, creation date don't save our asse=
s. 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.</div><div id=3D"yui_3_1=
6_0_1_1426122660566_31682"><br></div><div>&gt;&nbsp;<span style=3D'color: r=
gb(0, 0, 0); font-family: "Helvetica Neue-Light","Helvetica Neue Light","He=
lvetica Neue",Helvetica,Arial,"Lucida Grande",sans-serif; font-size: 16px;'=
From my interpretation of BIP39, wordlists DO NOT&nbsp;REQUIRE to be fixed=
 between wallet providers.&nbsp;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.</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",sa=
ns-serif; font-size: 16px;'><br></span></div><div><span style=3D'color: rgb=
(0, 0, 0); font-family: "Helvetica Neue-Light","Helvetica Neue Light","Helv=
etica Neue",Helvetica,Arial,"Lucida Grande",sans-serif; font-size: 16px;'>E=
xactly! 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 an=
y 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 feeli=
ng that we've found a consensus. I was *very* surprised that Electrum 2.0 s=
tarted to use yet another algo "just because".</span></div><div><br></div><=
div><div>Shortly said, I think BIP39 does perfect job and there's no need t=
o use anything else.</div></div><div><br></div><div>Cheers,</div><div id=3D=
"yui_3_16_0_1_1426122660566_32019">Marek</div></div></body></html>
------=_Part_4459742_498376856.1426137167380--