path: root/21/699929770b7c08cf580743f52a93afb443afa1

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 <thyshizzle@outlook.com>) id 1YW2hs-0004uj-EX
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Mar 2015 12:59:20 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of outlook.com
	designates 65.55.34.17 as permitted sender)
	client-ip=65.55.34.17; envelope-from=thyshizzle@outlook.com;
	helo=COL004-OMC1S7.hotmail.com; 
Received: from col004-omc1s7.hotmail.com ([65.55.34.17])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1YW2hp-0000jF-D2
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Mar 2015 12:59:20 +0000
Received: from COL130-W39 ([65.55.34.9]) by COL004-OMC1S7.hotmail.com over TLS
	secured channel with Microsoft SMTPSVC(7.5.7601.22751); 
	Thu, 12 Mar 2015 05:59:11 -0700
X-TMN: [Sq1+Lm+uv+V+c+fcjxsllLROMSEWTjGeIHSzYK9RC6c=]
X-Originating-Email: [thyshizzle@outlook.com]
Message-ID: <COL130-W392A86DB8E091762032107C2060@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_1192efe0-4738-4ad6-a708-b47acfd53f0b_"
From: Thy Shizzle <thyshizzle@outlook.com>
To: Neill Miller <neillm@thecodefactory.org>, "thomasv@electrum.org"
	<thomasv@electrum.org>
Date: Thu, 12 Mar 2015 23:59:11 +1100
Importance: Normal
In-Reply-To: <20150312115137.GN4541@boiler.chaos.net>
References: <692694585.4537988.1426134119107.JavaMail.yahoo@mail.yahoo.com>,
	<20150312115137.GN4541@boiler.chaos.net>
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Mar 2015 12:59:11.0851 (UTC)
	FILETIME=[55EA53B0:01D05CC4]
X-Spam-Score: 0.0 (/)
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
	(thyshizzle[at]outlook.com)
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [65.55.34.17 listed in list.dnswl.org]
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	1.0 FREEMAIL_REPLY         From and body contain different freemails
	-0.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YW2hp-0000jF-D2
Cc: "bitcoin-development@lists.sourceforge.net"
	<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 12:59:20 -0000

--_1192efe0-4738-4ad6-a708-b47acfd53f0b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

@Neill=2C Indeed supplying entropy is necessary for testing etc=2C that's t=
he main reason why I put this in my .NET implementation=2C the test vectors=
 require us to supply entropy and build the mnemonic from the supplied word=
list and you are correct that changes to the word list will null and void t=
he test vectors. Also it allows us to do fun things like swap between langu=
ages so one entropy set can have many seeds based on many languages etc=2C =
just novel little things like that. I'm not at all against a standard wordl=
ist. The point I want to get across is that people seem to think that BIP39=
 is restricted by its word list but not at all. As long as you give a BIP39=
 implementation 12 words or more (in 3 word increments) it will always deri=
ve the same seed bytes=2C independent of any word list and this is the most=
 important message to realise.

@Thomas V if you must record a version=2C why don't you just put an integer=
 at the end of your mnemonic or something? I can't understand why you have =
disregarded BIP39 when designing Electrum 2.0?  12 - 24 words plus a versio=
n integer tacked on the end=2C tell the user to omit the version integer if=
 they want to import to multibit HD or whatever=2C job done!

I really think you need to rethink the use of BIP39 with Electrum Thomas! I=
f you want to maintain a version field and/or date independent of the BIP39=
 spec then do so because at least the seed can still be recreated from anyo=
ne else utilising BIP39!!!

Thy

> Date: Thu=2C 12 Mar 2015 06:51:37 -0500
> From: neillm@thecodefactory.org
> To: thashiznets@yahoo.com.au
> CC: Bitcoin-development@lists.sourceforge.net
> Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
>=20
>=20
> Ok=2C I see your point here=2C and I was referring to rebuilding from
> entropy -- which as you noted is not a real world usage.  It is a
> useful implementation test though and at the very least the existing
> test vectors would need to be regenerated with each word list change.
>=20
> I recently added BIP39 to libbitcoin and our implementation would fail
> with an arbitrarily new word list because we validate the user
> provided word list before converting it to a seed (i.e. we check that
> the encoded entropy/checksum line up and warn the user if that's not
> the case to distinguish a rubbish word list from a BIP39 mnemonic --
> as referenced in the BIP).  You're correct that we could use rubbish
> words=2C but at the moment it's not allowed there.  By removing that
> validating 'restriction'=2C I agree with you that word lists have no
> need to be fixed.  But realistically=2C we still don't allow completely
> arbitrary words to be used because I don't see the word lists changing
> too often=2C nor implementations storing word lists of all words and
> languages.
>=20
> Thanks for clarifying=2C
> -Neill.
>=20
> On Thu=2C Mar 12=2C 2015 at 04:21:59AM +0000=2C Thy Shizzle wrote:
> > "I agree that it's true that a static wordlist is
> >  required once people have started using BIP39 for anything real and
> >  changing the word lists will invalidate any existing mnemonics"
> > ^ This is incorrect I think Neill=2C the reason is that the only thing =
that happens when you change the wordlist is that entropy points to differe=
nt words. But remember=2C entropy is disposed. Yes in my code I allow for t=
he keeping of entropy etc=2C it also lets me "hot swap" between different l=
anguage wordlists etc but in real world implementation the entropy is forgo=
tten and not stored. So changing the wordlist merely allows new mnemonic ph=
rases to be generated but it has a nil impact on previously generated mnemo=
nics UNLESS you are trying to rebuild from entropy but you wouldn't do that=
. You would be rebuilding from the Mnemonic in real world scenario. You rea=
lly can have a word list of total rubbish in BIP39 as long as it is 2048 wo=
rds long that is all! If you input the mnemonic made out of rubbish words s=
o for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd t=
yyty rwetrtr" and no matter what BIP39 implementation you put it in=2C it w=
ill always generate the same seed bytes thus allowing for complete and univ=
ersal seed derivation without any reliance on word list. The word list is m=
erely to generate a mnemonic=2C after that it has no role in seed generatio=
n so you can change it at anytime and it will never effect future mnemonics=
.
> >=20
> > On Thu=2C Mar 12=2C 2015 at 02:16:38AM +0000=2C Thy Shizzle wrote:
> > > That's disappointing the Electrum 2.0 doesn't use BIP39.
> >=20
> > Agreed=2C but I don't know the full background on this.
> >=20
> > > Changing the wordlist in the future has ZERO effect on derived seed=
=2C whatever mnemonic you provide will always generate the same seed=2C BIP=
39 is not mapping the words back to numbers etc to derive seed.
> >=20
> > That's true for generating new mnemonics (i.e. same entropy can
> > generate any combinations of words)=2C but not for converting a mnemoni=
c
> > to a seed (i.e. a specific wordlist/passphrase should always generate
> > the same seed).  I agree that it's true that a static wordlist is
> > required once people have started using BIP39 for anything real and
> > changing the word lists will invalidate any existing mnemonics (unless
> > your 'new' wordlist simply substitutes one word for another and the
> > index mapping is made public ... which means it's not really an
> > arbitrary word list).
> >=20
> > > Version is something that can be dealt with after the fact=2C hopeful=
ly standardised (curious why didn't you work with the BIP39 to insert versi=
on instead of do something different to BIP39?)
> > > So most of what you are suggesting as problems are not.
> >=20
> > I don't see how this can work given the BIP39 spec as it is today
> > (there's simply no room for a version in the bits).  I do think
> > versioning would be nice=2C but as of now=2C I'm in the camp that think=
s
> > complete wallet interoperability is a bit of a myth -- so long as you
> > can fundamentally move into/out of wallets at will.
> >=20
> > -Neill.
> >=20
> > > As for the common words between languages=2C I have discussed this wi=
th the provider of the Chinese wordlists as they shared some words between =
simplified and traditional=2C but I found it easy to look for a word in the=
 mnemonic that is unique to that language/wordlist and so straight away you=
 can determine the language=2C remembering you get minimum 12 goes at doing=
 that :)
> > > Also then I asked myself=2C do we really care about detecting the lan=
guage? Probably not because we don't need to use the wordlist ever again af=
ter creation=2C we literally accept the mnemonic=2C normalise it then hash =
it into a seed. From what I'm reading=2C Electrum 2.0 really should have BI=
P39=2C it would take almost no effort to put it in and I think you should d=
o that :) I don't have any interest in BIP39 other than it being a standard=
. I think TREZOR may have an interest in it?
> > > Thomas V:
> > > "Thanks Mike=2C and sorry to answer a bit late=3B it has been a busy =
couple
> > > of weeks.
> > >=20
> > > You are correct=2C a BIP39 seed phrase will not work in Electrum=2C a=
nd vice
> > > versa. It is indeed unfortunate. However=2C I believe BIP39 should no=
t be
> > > followed=2C because it reproduces two mistakes I did when I designed =
the
> > > older Electrum seed system. Let me explain.
> > >=20
> > > The first problem I have with BIP39 is that the seed phrase does not
> > > include a version number.
> > >=20
> > > Wallet development is still in an exploratory phase=2C and we should
> > > expect even more innovation in this domain. In this context=2C it is
> > > unwise to make decisions that prevent future innovation.
> > >=20
> > > However=2C when we give a seed phrase to users=2C we have a moral obl=
igation
> > > to keep supporting this seed phrase in future versions. We cannot sim=
ply
> > > announce to Electrum users that their old seed phrase is not supporte=
d
> > > anymore=2C because we created a new version of the software that uses=
 a
> > > different derivation. This could lead to financial losses for users w=
ho
> > > are unaware of these technicalities. Well=2C at least=2C that is how =
I feel
> > > about it.
> > >=20
> > > BIP39 and Electrum v2 have a very different ways of handling future
> > > innovation. Electrum v2 seed phrases include an explicit version numb=
er=2C
> > > that indicates how the wallet addresses should be derived. In contras=
t=2C
> > > BIP39 seed phrases do not include a version number at all. BIP39 is
> > > meant to be combined with BIP43=2C which stipulates that the wallet
> > > structure should depend on the BIP32 derivation path used for the wal=
let
> > > (although BIP43 is not followed by all BIP39 compatible wallets). Thu=
s=2C
> > > innovation in BIP43 is allowed only within the framework of BIP32. In
> > > addition=2C having to explore the branches of the BIP32 tree in order=
 to
> > > determine the type of wallet attached to a seed might be somewhat
> > > inefficient.
> > >=20
> > > The second problem I see with BIP39 is that it requires a fixed
> > > wordlist. Of course=2C this forbids innovation in the wordlist itself=
=2C but
> > > that's not the main problem. When you write a new standard=2C it is
> > > important to keep this standard minimal=2C given the goal you want to
> > > achieve. I believe BIP39 could (and should) have been written without
> > > including the wordlist in the standard.
> > >=20
> > > There are two ways to derive a master key from a mnemonic phrase:
> > >  1. A bidirectional mapping between words and numbers=2C as in old
> > > Electrum versions. Pros: bidirectional means that you can do Shamir
> > > secret sharing of your seed. Cons: It requires a fixed wordlist.
> > >  2. Use a hash of the seed phrase (pbkdf). Pros: a fixed wordlist is =
not
> > > required. Cons: the mapping isn't bidirectional.
> > >=20
> > > Electrum v1 uses (1). Electrum v2 uses (2).
> > >=20
> > > Early versions of BIP39 used (1)=2C and later they switched to (2).
> > > However=2C BIP39 uses (2) only in order to derive the wallet keys=2C =
not for
> > > its checksum. The BIP39 checksum uses (1)=2C and it does requires a f=
ixed
> > > wordlist. This is just plainly inconsistent. As a result=2C you have
> > > neither wordlist flexibility=2C nor Shamir secret sharing.
> > >=20
> > > Having a fixed wordlist is very unfortunate. First=2C it means that B=
IP39
> > > will probably never leave the 'draft' stage=2C until all languages of=
 the
> > > world have been added. Second=2C once you add a wordlist for a new
> > > language=2C you cannot change it anymore=2C because it will break exi=
sting
> > > seed phrases=3B therefore you have to be extremely careful in the way=
 you
> > > design these wordlists. Third=2C languages often have words in common=
.
> > > When you add a new language to the list=2C you should not use words
> > > already used by existing wordlists=2C in order to ensure that the lan=
guage
> > > can be detected. It leads to a first come first served situation=2C t=
hat
> > > might not be sustainable in the future.
> > >=20
> > > In order to support the old Electrum v1 seeds=2C all future versions =
of
> > > Electrum will have to include the old wordlist. In addition=2C when
> > > generating new seed phrases=2C Electrum now has to avoid collisions w=
ith
> > > old seed phrases=2C because the old ones did not have a version numbe=
r.
> > > This is painful enough=2C I will not repeat the same errors twice.
> > >=20
> > > Electrum v2 derives both its private keys and its checksum/version
> > > number using a hash of the seed phrase. This means that wordlists can=
 be
> > > added and modified in the future=2C without breaking existing seed
> > > phrases. It also means that it will be very easy for other wallets to
> > > support Electrum seedphrases: it requires about 20 lines of code=2C a=
nd no
> > > wordlist is required."
> > >=20
> > >=20
> > > Thomas
> > >=20
> > >=20
> > > Le 02/03/2015 16:37=2C Mike Hearn a =E9crit :
> > > > Congrats Thomas! Glad to see Electrum 2 finally launch.
> > > >=20
> > > >=20
> > > >> * New seed derivation method (not compatible with BIP39).
> > > >=20
> > > >=20
> > > > Does this mean a "12 words" wallet created by Electrum won't work i=
f
> > > > imported into some other wallet that supports BIP39? Vice versa? Th=
is seems
> > > > unfortunate. I guess if seeds are being represented with 12 words
> > > > consistently=2C people will expect them to work everywhere.
> > > >=20
> > >=20
> > > ---------------------------------------------------------------------=
---------
> > > Dive into the World of Parallel Programming The Go Parallel Website=
=2C sponsored
> > > by Intel and developed in partnership with Slashdot Media=2C is your =
hub for all
> > > things parallel software development=2C from weekly thought leadershi=
p blogs to
> > > news=2C videos=2C case studies=2C tutorials and more. Take a look and=
 join the=20
> > > conversation now. http://goparallel.sourceforge.net/
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development@lists.sourceforge.net
> > > Bitcoin-development --
> > > |   |
> > > |   |   |   |   |   |
> > > | Bitcoin-development --To see the collection of prior postings to th=
e list=2C visit the Bitcoin-development Archives. |
> > > |  |
> > > | View on lists.sourceforge.net | Preview by Yahoo |
> > > |  |
> > > |   |
> > >=20
> > >  =20
> > >=20
> > > =20
> > >   =20
> >=20
> > > ---------------------------------------------------------------------=
---------
> > > Dive into the World of Parallel Programming The Go Parallel Website=
=2C sponsored
> > > by Intel and developed in partnership with Slashdot Media=2C is your =
hub for all
> > > things parallel software development=2C from weekly thought leadershi=
p blogs to
> > > news=2C videos=2C case studies=2C tutorials and more. Take a look and=
 join the=20
> > > conversation now. http://goparallel.sourceforge.net/
> >=20
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
> -------------------------------------------------------------------------=
-----
> Dive into the World of Parallel Programming The Go Parallel Website=2C sp=
onsored
> by Intel and developed in partnership with Slashdot Media=2C is your hub =
for all
> things parallel software development=2C from weekly thought leadership bl=
ogs to
> news=2C videos=2C case studies=2C tutorials and more. Take a look and joi=
n the=20
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 		 	   		  =

--_1192efe0-4738-4ad6-a708-b47acfd53f0b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>@Neill=2C Indeed supplying entro=
py is necessary for testing etc=2C that's the main reason why I put this in=
 my .NET implementation=2C the test vectors require us to supply entropy an=
d build the mnemonic from the supplied wordlist and you are correct that ch=
anges to the word list will null and void the test vectors. Also it allows =
us to do fun things like swap between languages so one entropy set can have=
 many seeds based on many languages etc=2C just novel little things like th=
at. I'm not at all against a standard wordlist. The point I want to get acr=
oss is that people seem to think that BIP39 is restricted by its word list =
but not at all. As long as you give a BIP39 implementation 12 words or more=
 (in 3 word increments) it will always derive the same seed bytes=2C indepe=
ndent of any word list and this is the most important message to realise.<b=
r><br>@Thomas V if you must record a version=2C why don't you just put an i=
nteger at the end of your mnemonic or something? I can't understand why you=
 have disregarded BIP39 when designing Electrum 2.0?&nbsp=3B 12 - 24 words =
plus a version integer tacked on the end=2C tell the user to omit the versi=
on integer if they want to import to multibit HD or whatever=2C job done!<b=
r><br>I really think you need to rethink the use of BIP39 with Electrum Tho=
mas! If you want to maintain a version field and/or date independent of the=
 BIP39 spec then do so because at least the seed can still be recreated fro=
m anyone else utilising BIP39!!!<br><br>Thy<br><br><div>&gt=3B Date: Thu=2C=
 12 Mar 2015 06:51:37 -0500<br>&gt=3B From: neillm@thecodefactory.org<br>&g=
t=3B To: thashiznets@yahoo.com.au<br>&gt=3B CC: Bitcoin-development@lists.s=
ourceforge.net<br>&gt=3B Subject: Re: [Bitcoin-development] Electrum 2.0 ha=
s been tagged<br>&gt=3B <br>&gt=3B <br>&gt=3B Ok=2C I see your point here=
=2C and I was referring to rebuilding from<br>&gt=3B entropy -- which as yo=
u noted is not a real world usage.  It is a<br>&gt=3B useful implementation=
 test though and at the very least the existing<br>&gt=3B test vectors woul=
d need to be regenerated with each word list change.<br>&gt=3B <br>&gt=3B I=
 recently added BIP39 to libbitcoin and our implementation would fail<br>&g=
t=3B with an arbitrarily new word list because we validate the user<br>&gt=
=3B provided word list before converting it to a seed (i.e. we check that<b=
r>&gt=3B the encoded entropy/checksum line up and warn the user if that's n=
ot<br>&gt=3B the case to distinguish a rubbish word list from a BIP39 mnemo=
nic --<br>&gt=3B as referenced in the BIP).  You're correct that we could u=
se rubbish<br>&gt=3B words=2C but at the moment it's not allowed there.  By=
 removing that<br>&gt=3B validating 'restriction'=2C I agree with you that =
word lists have no<br>&gt=3B need to be fixed.  But realistically=2C we sti=
ll don't allow completely<br>&gt=3B arbitrary words to be used because I do=
n't see the word lists changing<br>&gt=3B too often=2C nor implementations =
storing word lists of all words and<br>&gt=3B languages.<br>&gt=3B <br>&gt=
=3B Thanks for clarifying=2C<br>&gt=3B -Neill.<br>&gt=3B <br>&gt=3B On Thu=
=2C Mar 12=2C 2015 at 04:21:59AM +0000=2C Thy Shizzle wrote:<br>&gt=3B &gt=
=3B "I agree that it's true that a static wordlist is<br>&gt=3B &gt=3B  req=
uired once people have started using BIP39 for anything real and<br>&gt=3B =
&gt=3B  changing the word lists will invalidate any existing mnemonics"<br>=
&gt=3B &gt=3B ^ This is incorrect I think Neill=2C the reason is that the o=
nly thing that happens when you change the wordlist is that entropy points =
to different words. But remember=2C entropy is disposed. Yes in my code I a=
llow for the keeping of entropy etc=2C it also lets me "hot swap" between d=
ifferent language wordlists etc but in real world implementation the entrop=
y is forgotten and not stored. So changing the wordlist merely allows new m=
nemonic phrases to be generated but it has a nil impact on previously gener=
ated mnemonics UNLESS you are trying to rebuild from entropy but you wouldn=
't do that. You would be rebuilding from the Mnemonic in real world scenari=
o. You really can have a word list of total rubbish in BIP39 as long as it =
is 2048 words long that is all! If you input the mnemonic made out of rubbi=
sh words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyu=
y sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you put it =
in=2C it will always generate the same seed bytes thus allowing for complet=
e and universal seed derivation without any reliance on word list. The word=
 list is merely to generate a mnemonic=2C after that it has no role in seed=
 generation so you can change it at anytime and it will never effect future=
 mnemonics.<br>&gt=3B &gt=3B <br>&gt=3B &gt=3B On Thu=2C Mar 12=2C 2015 at =
02:16:38AM +0000=2C Thy Shizzle wrote:<br>&gt=3B &gt=3B &gt=3B That's disap=
pointing the Electrum 2.0 doesn't use BIP39.<br>&gt=3B &gt=3B <br>&gt=3B &g=
t=3B Agreed=2C but I don't know the full background on this.<br>&gt=3B &gt=
=3B <br>&gt=3B &gt=3B &gt=3B Changing the wordlist in the future has ZERO e=
ffect on derived seed=2C whatever mnemonic you provide will always generate=
 the same seed=2C BIP39 is not mapping the words back to numbers etc to der=
ive seed.<br>&gt=3B &gt=3B <br>&gt=3B &gt=3B That's true for generating new=
 mnemonics (i.e. same entropy can<br>&gt=3B &gt=3B generate any combination=
s of words)=2C but not for converting a mnemonic<br>&gt=3B &gt=3B to a seed=
 (i.e. a specific wordlist/passphrase should always generate<br>&gt=3B &gt=
=3B the same seed).&nbsp=3B I agree that it's true that a static wordlist i=
s<br>&gt=3B &gt=3B required once people have started using BIP39 for anythi=
ng real and<br>&gt=3B &gt=3B changing the word lists will invalidate any ex=
isting mnemonics (unless<br>&gt=3B &gt=3B your 'new' wordlist simply substi=
tutes one word for another and the<br>&gt=3B &gt=3B index mapping is made p=
ublic ... which means it's not really an<br>&gt=3B &gt=3B arbitrary word li=
st).<br>&gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B Version is something that ca=
n be dealt with after the fact=2C hopefully standardised (curious why didn'=
t you work with the BIP39 to insert version instead of do something differe=
nt to BIP39?)<br>&gt=3B &gt=3B &gt=3B So most of what you are suggesting as=
 problems are not.<br>&gt=3B &gt=3B <br>&gt=3B &gt=3B I don't see how this =
can work given the BIP39 spec as it is today<br>&gt=3B &gt=3B (there's simp=
ly no room for a version in the bits).&nbsp=3B I do think<br>&gt=3B &gt=3B =
versioning would be nice=2C but as of now=2C I'm in the camp that thinks<br=
>&gt=3B &gt=3B complete wallet interoperability is a bit of a myth -- so lo=
ng as you<br>&gt=3B &gt=3B can fundamentally move into/out of wallets at wi=
ll.<br>&gt=3B &gt=3B <br>&gt=3B &gt=3B -Neill.<br>&gt=3B &gt=3B <br>&gt=3B =
&gt=3B &gt=3B As for the common words between languages=2C I have discussed=
 this with the provider of the Chinese wordlists as they shared some words =
between simplified and traditional=2C but I found it easy to look for a wor=
d in the mnemonic that is unique to that language/wordlist and so straight =
away you can determine the language=2C remembering you get minimum 12 goes =
at doing that :)<br>&gt=3B &gt=3B &gt=3B Also then I asked myself=2C do we =
really care about detecting the language? Probably not because we don't nee=
d to use the wordlist ever again after creation=2C we literally accept the =
mnemonic=2C normalise it then hash it into a seed. From what I'm reading=2C=
 Electrum 2.0 really should have BIP39=2C it would take almost no effort to=
 put it in and I think you should do that :) I don't have any interest in B=
IP39 other than it being a standard. I think TREZOR may have an interest in=
 it?<br>&gt=3B &gt=3B &gt=3B Thomas V:<br>&gt=3B &gt=3B &gt=3B "Thanks Mike=
=2C and sorry to answer a bit late=3B it has been a busy couple<br>&gt=3B &=
gt=3B &gt=3B of weeks.<br>&gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B You=
 are correct=2C a BIP39 seed phrase will not work in Electrum=2C and vice<b=
r>&gt=3B &gt=3B &gt=3B versa. It is indeed unfortunate. However=2C I believ=
e BIP39 should not be<br>&gt=3B &gt=3B &gt=3B followed=2C because it reprod=
uces two mistakes I did when I designed the<br>&gt=3B &gt=3B &gt=3B older E=
lectrum seed system. Let me explain.<br>&gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=
=3B &gt=3B The first problem I have with BIP39 is that the seed phrase does=
 not<br>&gt=3B &gt=3B &gt=3B include a version number.<br>&gt=3B &gt=3B &gt=
=3B <br>&gt=3B &gt=3B &gt=3B Wallet development is still in an exploratory =
phase=2C and we should<br>&gt=3B &gt=3B &gt=3B expect even more innovation =
in this domain. In this context=2C it is<br>&gt=3B &gt=3B &gt=3B unwise to =
make decisions that prevent future innovation.<br>&gt=3B &gt=3B &gt=3B <br>=
&gt=3B &gt=3B &gt=3B However=2C when we give a seed phrase to users=2C we h=
ave a moral obligation<br>&gt=3B &gt=3B &gt=3B to keep supporting this seed=
 phrase in future versions. We cannot simply<br>&gt=3B &gt=3B &gt=3B announ=
ce to Electrum users that their old seed phrase is not supported<br>&gt=3B =
&gt=3B &gt=3B anymore=2C because we created a new version of the software t=
hat uses a<br>&gt=3B &gt=3B &gt=3B different derivation. This could lead to=
 financial losses for users who<br>&gt=3B &gt=3B &gt=3B are unaware of thes=
e technicalities. Well=2C at least=2C that is how I feel<br>&gt=3B &gt=3B &=
gt=3B about it.<br>&gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B BIP39 and =
Electrum v2 have a very different ways of handling future<br>&gt=3B &gt=3B =
&gt=3B innovation. Electrum v2 seed phrases include an explicit version num=
ber=2C<br>&gt=3B &gt=3B &gt=3B that indicates how the wallet addresses shou=
ld be derived. In contrast=2C<br>&gt=3B &gt=3B &gt=3B BIP39 seed phrases do=
 not include a version number at all. BIP39 is<br>&gt=3B &gt=3B &gt=3B mean=
t to be combined with BIP43=2C which stipulates that the wallet<br>&gt=3B &=
gt=3B &gt=3B structure should depend on the BIP32 derivation path used for =
the wallet<br>&gt=3B &gt=3B &gt=3B (although BIP43 is not followed by all B=
IP39 compatible wallets). Thus=2C<br>&gt=3B &gt=3B &gt=3B innovation in BIP=
43 is allowed only within the framework of BIP32. In<br>&gt=3B &gt=3B &gt=
=3B addition=2C having to explore the branches of the BIP32 tree in order t=
o<br>&gt=3B &gt=3B &gt=3B determine the type of wallet attached to a seed m=
ight be somewhat<br>&gt=3B &gt=3B &gt=3B inefficient.<br>&gt=3B &gt=3B &gt=
=3B <br>&gt=3B &gt=3B &gt=3B The second problem I see with BIP39 is that it=
 requires a fixed<br>&gt=3B &gt=3B &gt=3B wordlist. Of course=2C this forbi=
ds innovation in the wordlist itself=2C but<br>&gt=3B &gt=3B &gt=3B that's =
not the main problem. When you write a new standard=2C it is<br>&gt=3B &gt=
=3B &gt=3B important to keep this standard minimal=2C given the goal you wa=
nt to<br>&gt=3B &gt=3B &gt=3B achieve. I believe BIP39 could (and should) h=
ave been written without<br>&gt=3B &gt=3B &gt=3B including the wordlist in =
the standard.<br>&gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B There are tw=
o ways to derive a master key from a mnemonic phrase:<br>&gt=3B &gt=3B &gt=
=3B &nbsp=3B1. A bidirectional mapping between words and numbers=2C as in o=
ld<br>&gt=3B &gt=3B &gt=3B Electrum versions. Pros: bidirectional means tha=
t you can do Shamir<br>&gt=3B &gt=3B &gt=3B secret sharing of your seed. Co=
ns: It requires a fixed wordlist.<br>&gt=3B &gt=3B &gt=3B &nbsp=3B2. Use a =
hash of the seed phrase (pbkdf). Pros: a fixed wordlist is not<br>&gt=3B &g=
t=3B &gt=3B required. Cons: the mapping isn't bidirectional.<br>&gt=3B &gt=
=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B Electrum v1 uses (1). Electrum v2 uses =
(2).<br>&gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B Early versions of BIP=
39 used (1)=2C and later they switched to (2).<br>&gt=3B &gt=3B &gt=3B Howe=
ver=2C BIP39 uses (2) only in order to derive the wallet keys=2C not for<br=
>&gt=3B &gt=3B &gt=3B its checksum. The BIP39 checksum uses (1)=2C and it d=
oes requires a fixed<br>&gt=3B &gt=3B &gt=3B wordlist. This is just plainly=
 inconsistent. As a result=2C you have<br>&gt=3B &gt=3B &gt=3B neither word=
list flexibility=2C nor Shamir secret sharing.<br>&gt=3B &gt=3B &gt=3B <br>=
&gt=3B &gt=3B &gt=3B Having a fixed wordlist is very unfortunate. First=2C =
it means that BIP39<br>&gt=3B &gt=3B &gt=3B will probably never leave the '=
draft' stage=2C until all languages of the<br>&gt=3B &gt=3B &gt=3B world ha=
ve been added. Second=2C once you add a wordlist for a new<br>&gt=3B &gt=3B=
 &gt=3B language=2C you cannot change it anymore=2C because it will break e=
xisting<br>&gt=3B &gt=3B &gt=3B seed phrases=3B therefore you have to be ex=
tremely careful in the way you<br>&gt=3B &gt=3B &gt=3B design these wordlis=
ts. Third=2C languages often have words in common.<br>&gt=3B &gt=3B &gt=3B =
When you add a new language to the list=2C you should not use words<br>&gt=
=3B &gt=3B &gt=3B already used by existing wordlists=2C in order to ensure =
that the language<br>&gt=3B &gt=3B &gt=3B can be detected. It leads to a fi=
rst come first served situation=2C that<br>&gt=3B &gt=3B &gt=3B might not b=
e sustainable in the future.<br>&gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=
=3B In order to support the old Electrum v1 seeds=2C all future versions of=
<br>&gt=3B &gt=3B &gt=3B Electrum will have to include the old wordlist. In=
 addition=2C when<br>&gt=3B &gt=3B &gt=3B generating new seed phrases=2C El=
ectrum now has to avoid collisions with<br>&gt=3B &gt=3B &gt=3B old seed ph=
rases=2C because the old ones did not have a version number.<br>&gt=3B &gt=
=3B &gt=3B This is painful enough=2C I will not repeat the same errors twic=
e.<br>&gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B Electrum v2 derives bot=
h its private keys and its checksum/version<br>&gt=3B &gt=3B &gt=3B number =
using a hash of the seed phrase. This means that wordlists can be<br>&gt=3B=
 &gt=3B &gt=3B added and modified in the future=2C without breaking existin=
g seed<br>&gt=3B &gt=3B &gt=3B phrases. It also means that it will be very =
easy for other wallets to<br>&gt=3B &gt=3B &gt=3B support Electrum seedphra=
ses: it requires about 20 lines of code=2C and no<br>&gt=3B &gt=3B &gt=3B w=
ordlist is required."<br>&gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B <br>=
&gt=3B &gt=3B &gt=3B Thomas<br>&gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=
=3B <br>&gt=3B &gt=3B &gt=3B Le 02/03/2015 16:37=2C Mike Hearn a =E9crit :<=
br>&gt=3B &gt=3B &gt=3B &gt=3B Congrats Thomas! Glad to see Electrum 2 fina=
lly launch.<br>&gt=3B &gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B &gt=3B =
<br>&gt=3B &gt=3B &gt=3B &gt=3B&gt=3B * New seed derivation method (not com=
patible with BIP39).<br>&gt=3B &gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=
=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B &gt=3B Does this mean a "12 words" wall=
et created by Electrum won't work if<br>&gt=3B &gt=3B &gt=3B &gt=3B importe=
d into some other wallet that supports BIP39? Vice versa? This seems<br>&gt=
=3B &gt=3B &gt=3B &gt=3B unfortunate. I guess if seeds are being represente=
d with 12 words<br>&gt=3B &gt=3B &gt=3B &gt=3B consistently=2C people will =
expect them to work everywhere.<br>&gt=3B &gt=3B &gt=3B &gt=3B <br>&gt=3B &=
gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B -------------------------------------=
-----------------------------------------<br>&gt=3B &gt=3B &gt=3B Dive into=
 the World of Parallel Programming The Go Parallel Website=2C sponsored<br>=
&gt=3B &gt=3B &gt=3B by Intel and developed in partnership with Slashdot Me=
dia=2C is your hub for all<br>&gt=3B &gt=3B &gt=3B things parallel software=
 development=2C from weekly thought leadership blogs to<br>&gt=3B &gt=3B &g=
t=3B news=2C videos=2C case studies=2C tutorials and more. Take a look and =
join the <br>&gt=3B &gt=3B &gt=3B conversation now. http://goparallel.sourc=
eforge.net/<br>&gt=3B &gt=3B &gt=3B _______________________________________=
________<br>&gt=3B &gt=3B &gt=3B Bitcoin-development mailing list<br>&gt=3B=
 &gt=3B &gt=3B Bitcoin-development@lists.sourceforge.net<br>&gt=3B &gt=3B &=
gt=3B Bitcoin-development --<br>&gt=3B &gt=3B &gt=3B | &nbsp=3B |<br>&gt=3B=
 &gt=3B &gt=3B | &nbsp=3B | &nbsp=3B | &nbsp=3B | &nbsp=3B | &nbsp=3B |<br>=
&gt=3B &gt=3B &gt=3B | Bitcoin-development --To see the collection of prior=
 postings to the list=2C visit the Bitcoin-development Archives. |<br>&gt=
=3B &gt=3B &gt=3B |&nbsp=3B |<br>&gt=3B &gt=3B &gt=3B | View on lists.sourc=
eforge.net | Preview by Yahoo |<br>&gt=3B &gt=3B &gt=3B |&nbsp=3B |<br>&gt=
=3B &gt=3B &gt=3B | &nbsp=3B |<br>&gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &g=
t=3B&nbsp=3B &nbsp=3B<br>&gt=3B &gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B&nbsp=
=3B <br>&gt=3B &gt=3B &gt=3B&nbsp=3B&nbsp=3B&nbsp=3B <br>&gt=3B &gt=3B <br>=
&gt=3B &gt=3B &gt=3B ------------------------------------------------------=
------------------------<br>&gt=3B &gt=3B &gt=3B Dive into the World of Par=
allel Programming The Go Parallel Website=2C sponsored<br>&gt=3B &gt=3B &gt=
=3B by Intel and developed in partnership with Slashdot Media=2C is your hu=
b for all<br>&gt=3B &gt=3B &gt=3B things parallel software development=2C f=
rom weekly thought leadership blogs to<br>&gt=3B &gt=3B &gt=3B news=2C vide=
os=2C case studies=2C tutorials and more. Take a look and join the <br>&gt=
=3B &gt=3B &gt=3B conversation now. http://goparallel.sourceforge.net/<br>&=
gt=3B &gt=3B <br>&gt=3B &gt=3B &gt=3B _____________________________________=
__________<br>&gt=3B &gt=3B &gt=3B Bitcoin-development mailing list<br>&gt=
=3B &gt=3B &gt=3B Bitcoin-development@lists.sourceforge.net<br>&gt=3B &gt=
=3B &gt=3B https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
<br>&gt=3B <br>&gt=3B -----------------------------------------------------=
-------------------------<br>&gt=3B Dive into the World of Parallel Program=
ming The Go Parallel Website=2C sponsored<br>&gt=3B by Intel and developed =
in partnership with Slashdot Media=2C is your hub for all<br>&gt=3B things =
parallel software development=2C from weekly thought leadership blogs to<br=
>&gt=3B news=2C videos=2C case studies=2C tutorials and more. Take a look a=
nd join the <br>&gt=3B conversation now. http://goparallel.sourceforge.net/=
<br>&gt=3B _______________________________________________<br>&gt=3B Bitcoi=
n-development mailing list<br>&gt=3B Bitcoin-development@lists.sourceforge.=
net<br>&gt=3B https://lists.sourceforge.net/lists/listinfo/bitcoin-developm=
ent<br></div> 		 	   		  </div></body>
</html>=

--_1192efe0-4738-4ad6-a708-b47acfd53f0b_--