Re: [Bitcoin-development] Electrum 2.0 has been tagged

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

[-- Attachment #1: Type: text/plain, Size: 10528 bytes --]

 "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, the reason is that the only thing that happens when you change the wordlist is that entropy points to different words. But remember, entropy is disposed. Yes in my code I allow for the keeping of entropy etc, it also lets me "hot swap" between different language wordlists etc but in real world implementation the entropy is forgotten and not stored. So changing the wordlist merely allows new mnemonic phrases to be generated but it has a nil impact on previously generated 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 scenario. 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 rubbish words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you put it in, it will always generate the same seed bytes thus allowing for complete and universal seed derivation without any reliance on word list. The word list is merely to generate a mnemonic, after that it has no role in seed generation so you can change it at anytime and it will never effect future mnemonics.

On Thu, Mar 12, 2015 at 02:16:38AM +0000, Thy Shizzle wrote:
> That's disappointing the Electrum 2.0 doesn't use BIP39.

Agreed, but I don't know the full background on this.

> Changing the wordlist in the future has ZERO effect on derived seed, whatever mnemonic you provide will always generate the same seed, BIP39 is not mapping the words back to numbers etc to derive seed.

That's true for generating new mnemonics (i.e. same entropy can
generate any combinations of words), but not for converting a mnemonic
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).

> Version is something that can be dealt with after the fact, hopefully standardised (curious why didn't you work with the BIP39 to insert version instead of do something different to BIP39?)
> So most of what you are suggesting as problems are not.

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, but as of now, I'm in the camp that thinks
complete wallet interoperability is a bit of a myth -- so long as you
can fundamentally move into/out of wallets at will.

-Neill.

> As for the common words between languages, I have discussed this with the provider of the Chinese wordlists as they shared some words between simplified and traditional, 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, remembering you get minimum 12 goes at doing that :)
> Also then I asked myself, do we really care about detecting the language? Probably not because we don't need to use the wordlist ever again after creation, we literally accept the mnemonic, normalise it then hash it into a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it would take almost no effort to put it in and I think you should do 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, and sorry to answer a bit late; it has been a busy couple
> of weeks.
> 
> You are correct, a BIP39 seed phrase will not work in Electrum, and vice
> versa. It is indeed unfortunate. However, I believe BIP39 should not be
> followed, because it reproduces two mistakes I did when I designed the
> older Electrum seed system. Let me explain.
> 
> The first problem I have with BIP39 is that the seed phrase does not
> include a version number.
> 
> Wallet development is still in an exploratory phase, and we should
> expect even more innovation in this domain. In this context, it is
> unwise to make decisions that prevent future innovation.
> 
> However, when we give a seed phrase to users, we have a moral obligation
> to keep supporting this seed phrase in future versions. We cannot simply
> announce to Electrum users that their old seed phrase is not supported
> anymore, because we created a new version of the software that uses a
> different derivation. This could lead to financial losses for users who
> are unaware of these technicalities. Well, at least, that is how I feel
> about it.
> 
> BIP39 and Electrum v2 have a very different ways of handling future
> innovation. Electrum v2 seed phrases include an explicit version number,
> that indicates how the wallet addresses should be derived. In contrast,
> BIP39 seed phrases do not include a version number at all. BIP39 is
> meant to be combined with BIP43, which stipulates that the wallet
> structure should depend on the BIP32 derivation path used for the wallet
> (although BIP43 is not followed by all BIP39 compatible wallets). Thus,
> innovation in BIP43 is allowed only within the framework of BIP32. In
> addition, 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.
> 
> The second problem I see with BIP39 is that it requires a fixed
> wordlist. Of course, this forbids innovation in the wordlist itself, but
> that's not the main problem. When you write a new standard, it is
> important to keep this standard minimal, given the goal you want to
> achieve. I believe BIP39 could (and should) have been written without
> including the wordlist in the standard.
> 
> There are two ways to derive a master key from a mnemonic phrase:
>  1. A bidirectional mapping between words and numbers, 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.
> 
> Electrum v1 uses (1). Electrum v2 uses (2).
> 
> Early versions of BIP39 used (1), and later they switched to (2).
> However, BIP39 uses (2) only in order to derive the wallet keys, not for
> its checksum. The BIP39 checksum uses (1), and it does requires a fixed
> wordlist. This is just plainly inconsistent. As a result, you have
> neither wordlist flexibility, nor Shamir secret sharing.
> 
> Having a fixed wordlist is very unfortunate. First, it means that BIP39
> will probably never leave the 'draft' stage, until all languages of the
> world have been added. Second, once you add a wordlist for a new
> language, you cannot change it anymore, because it will break existing
> seed phrases; therefore you have to be extremely careful in the way you
> design these wordlists. Third, languages often have words in common.
> When you add a new language to the list, you should not use words
> already used by existing wordlists, in order to ensure that the language
> can be detected. It leads to a first come first served situation, that
> might not be sustainable in the future.
> 
> In order to support the old Electrum v1 seeds, all future versions of
> Electrum will have to include the old wordlist. In addition, when
> generating new seed phrases, Electrum now has to avoid collisions with
> old seed phrases, because the old ones did not have a version number.
> This is painful enough, I will not repeat the same errors twice.
> 
> 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, 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, and no
> wordlist is required."
> 
> 
> Thomas
> 
> 
> Le 02/03/2015 16:37, Mike Hearn a écrit :
> > Congrats Thomas! Glad to see Electrum 2 finally launch.
> > 
> > 
> >> * New seed derivation method (not compatible with BIP39).
> > 
> > 
> > Does this mean a "12 words" wallet created by Electrum won't work if
> > imported into some other wallet that supports BIP39? Vice versa? This seems
> > unfortunate. I guess if seeds are being represented with 12 words
> > consistently, people will expect them to work everywhere.
> > 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> 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 the list, visit the Bitcoin-development Archives. |
> |  |
> | View on lists.sourceforge.net | Preview by Yahoo |
> |  |
> |   |
> 
>   
> 
>  
>    

> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/

> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 12599 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Neill Miller]

Ok, I see your point here, 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.

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, but at the moment it's not allowed there.  By removing that
validating 'restriction', I agree with you that word lists have no
need to be fixed.  But realistically, we still don't allow completely
arbitrary words to be used because I don't see the word lists changing
too often, nor implementations storing word lists of all words and
languages.

Thanks for clarifying,
-Neill.

On Thu, Mar 12, 2015 at 04:21:59AM +0000, 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, the reason is that the only thing that happens when you change the wordlist is that entropy points to different words. But remember, entropy is disposed. Yes in my code I allow for the keeping of entropy etc, it also lets me "hot swap" between different language wordlists etc but in real world implementation the entropy is forgotten and not stored. So changing the wordlist merely allows new mnemonic phrases to be generated but it has a nil impact on previously generated 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 scenario. 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 rubbish words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you put it in, it will always generate the same seed bytes thus allowing for complete and universal seed derivation without any reliance on word list. The word list is merely to generate a mnemonic, after that it has no role in seed generation so you can change it at anytime and it will never effect future mnemonics.
> 
> On Thu, Mar 12, 2015 at 02:16:38AM +0000, Thy Shizzle wrote:
> > That's disappointing the Electrum 2.0 doesn't use BIP39.
> 
> Agreed, but I don't know the full background on this.
> 
> > Changing the wordlist in the future has ZERO effect on derived seed, whatever mnemonic you provide will always generate the same seed, BIP39 is not mapping the words back to numbers etc to derive seed.
> 
> That's true for generating new mnemonics (i.e. same entropy can
> generate any combinations of words), but not for converting a mnemonic
> 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).
> 
> > Version is something that can be dealt with after the fact, hopefully standardised (curious why didn't you work with the BIP39 to insert version instead of do something different to BIP39?)
> > So most of what you are suggesting as problems are not.
> 
> 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, but as of now, I'm in the camp that thinks
> complete wallet interoperability is a bit of a myth -- so long as you
> can fundamentally move into/out of wallets at will.
> 
> -Neill.
> 
> > As for the common words between languages, I have discussed this with the provider of the Chinese wordlists as they shared some words between simplified and traditional, 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, remembering you get minimum 12 goes at doing that :)
> > Also then I asked myself, do we really care about detecting the language? Probably not because we don't need to use the wordlist ever again after creation, we literally accept the mnemonic, normalise it then hash it into a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it would take almost no effort to put it in and I think you should do 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, and sorry to answer a bit late; it has been a busy couple
> > of weeks.
> > 
> > You are correct, a BIP39 seed phrase will not work in Electrum, and vice
> > versa. It is indeed unfortunate. However, I believe BIP39 should not be
> > followed, because it reproduces two mistakes I did when I designed the
> > older Electrum seed system. Let me explain.
> > 
> > The first problem I have with BIP39 is that the seed phrase does not
> > include a version number.
> > 
> > Wallet development is still in an exploratory phase, and we should
> > expect even more innovation in this domain. In this context, it is
> > unwise to make decisions that prevent future innovation.
> > 
> > However, when we give a seed phrase to users, we have a moral obligation
> > to keep supporting this seed phrase in future versions. We cannot simply
> > announce to Electrum users that their old seed phrase is not supported
> > anymore, because we created a new version of the software that uses a
> > different derivation. This could lead to financial losses for users who
> > are unaware of these technicalities. Well, at least, that is how I feel
> > about it.
> > 
> > BIP39 and Electrum v2 have a very different ways of handling future
> > innovation. Electrum v2 seed phrases include an explicit version number,
> > that indicates how the wallet addresses should be derived. In contrast,
> > BIP39 seed phrases do not include a version number at all. BIP39 is
> > meant to be combined with BIP43, which stipulates that the wallet
> > structure should depend on the BIP32 derivation path used for the wallet
> > (although BIP43 is not followed by all BIP39 compatible wallets). Thus,
> > innovation in BIP43 is allowed only within the framework of BIP32. In
> > addition, 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.
> > 
> > The second problem I see with BIP39 is that it requires a fixed
> > wordlist. Of course, this forbids innovation in the wordlist itself, but
> > that's not the main problem. When you write a new standard, it is
> > important to keep this standard minimal, given the goal you want to
> > achieve. I believe BIP39 could (and should) have been written without
> > including the wordlist in the standard.
> > 
> > There are two ways to derive a master key from a mnemonic phrase:
> >  1. A bidirectional mapping between words and numbers, 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.
> > 
> > Electrum v1 uses (1). Electrum v2 uses (2).
> > 
> > Early versions of BIP39 used (1), and later they switched to (2).
> > However, BIP39 uses (2) only in order to derive the wallet keys, not for
> > its checksum. The BIP39 checksum uses (1), and it does requires a fixed
> > wordlist. This is just plainly inconsistent. As a result, you have
> > neither wordlist flexibility, nor Shamir secret sharing.
> > 
> > Having a fixed wordlist is very unfortunate. First, it means that BIP39
> > will probably never leave the 'draft' stage, until all languages of the
> > world have been added. Second, once you add a wordlist for a new
> > language, you cannot change it anymore, because it will break existing
> > seed phrases; therefore you have to be extremely careful in the way you
> > design these wordlists. Third, languages often have words in common.
> > When you add a new language to the list, you should not use words
> > already used by existing wordlists, in order to ensure that the language
> > can be detected. It leads to a first come first served situation, that
> > might not be sustainable in the future.
> > 
> > In order to support the old Electrum v1 seeds, all future versions of
> > Electrum will have to include the old wordlist. In addition, when
> > generating new seed phrases, Electrum now has to avoid collisions with
> > old seed phrases, because the old ones did not have a version number.
> > This is painful enough, I will not repeat the same errors twice.
> > 
> > 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, 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, and no
> > wordlist is required."
> > 
> > 
> > Thomas
> > 
> > 
> > Le 02/03/2015 16:37, Mike Hearn a écrit :
> > > Congrats Thomas! Glad to see Electrum 2 finally launch.
> > > 
> > > 
> > >> * New seed derivation method (not compatible with BIP39).
> > > 
> > > 
> > > Does this mean a "12 words" wallet created by Electrum won't work if
> > > imported into some other wallet that supports BIP39? Vice versa? This seems
> > > unfortunate. I guess if seeds are being represented with 12 words
> > > consistently, people will expect them to work everywhere.
> > > 
> > 
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub for all
> > things parallel software development, from weekly thought leadership blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the 
> > 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 the list, visit the Bitcoin-development Archives. |
> > |  |
> > | View on lists.sourceforge.net | Preview by Yahoo |
> > |  |
> > |   |
> > 
> >   
> > 
> >  
> >    
> 
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub for all
> > things parallel software development, from weekly thought leadership blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the 
> > conversation now. http://goparallel.sourceforge.net/
> 
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

[-- Attachment #1: Type: text/plain, Size: 14751 bytes --]

@Neill, Indeed supplying entropy is necessary for testing etc, that's the main reason why I put this in my .NET implementation, the test vectors require us to supply entropy and build the mnemonic from the supplied wordlist and you are correct that changes 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, just novel little things like that. I'm not at all against a standard wordlist. 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 derive the same seed bytes, independent of any word list and this is the most important message to realise.

@Thomas V if you must record a version, 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 version integer tacked on the end, tell the user to omit the version integer if they want to import to multibit HD or whatever, job done!

I really think you need to rethink the use of BIP39 with Electrum Thomas! 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 from anyone else utilising BIP39!!!

Thy

> Date: Thu, 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
> 
> 
> Ok, I see your point here, 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.
> 
> 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, but at the moment it's not allowed there.  By removing that
> validating 'restriction', I agree with you that word lists have no
> need to be fixed.  But realistically, we still don't allow completely
> arbitrary words to be used because I don't see the word lists changing
> too often, nor implementations storing word lists of all words and
> languages.
> 
> Thanks for clarifying,
> -Neill.
> 
> On Thu, Mar 12, 2015 at 04:21:59AM +0000, 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, the reason is that the only thing that happens when you change the wordlist is that entropy points to different words. But remember, entropy is disposed. Yes in my code I allow for the keeping of entropy etc, it also lets me "hot swap" between different language wordlists etc but in real world implementation the entropy is forgotten and not stored. So changing the wordlist merely allows new mnemonic phrases to be generated but it has a nil impact on previously generated 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 scenario. 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 rubbish words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you put it in, it will always generate the same seed bytes thus allowing for complete and universal seed derivation without any reliance on word list. The word list is merely to generate a mnemonic, after that it has no role in seed generation so you can change it at anytime and it will never effect future mnemonics.
> > 
> > On Thu, Mar 12, 2015 at 02:16:38AM +0000, Thy Shizzle wrote:
> > > That's disappointing the Electrum 2.0 doesn't use BIP39.
> > 
> > Agreed, but I don't know the full background on this.
> > 
> > > Changing the wordlist in the future has ZERO effect on derived seed, whatever mnemonic you provide will always generate the same seed, BIP39 is not mapping the words back to numbers etc to derive seed.
> > 
> > That's true for generating new mnemonics (i.e. same entropy can
> > generate any combinations of words), but not for converting a mnemonic
> > 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).
> > 
> > > Version is something that can be dealt with after the fact, hopefully standardised (curious why didn't you work with the BIP39 to insert version instead of do something different to BIP39?)
> > > So most of what you are suggesting as problems are not.
> > 
> > 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, but as of now, I'm in the camp that thinks
> > complete wallet interoperability is a bit of a myth -- so long as you
> > can fundamentally move into/out of wallets at will.
> > 
> > -Neill.
> > 
> > > As for the common words between languages, I have discussed this with the provider of the Chinese wordlists as they shared some words between simplified and traditional, 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, remembering you get minimum 12 goes at doing that :)
> > > Also then I asked myself, do we really care about detecting the language? Probably not because we don't need to use the wordlist ever again after creation, we literally accept the mnemonic, normalise it then hash it into a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it would take almost no effort to put it in and I think you should do 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, and sorry to answer a bit late; it has been a busy couple
> > > of weeks.
> > > 
> > > You are correct, a BIP39 seed phrase will not work in Electrum, and vice
> > > versa. It is indeed unfortunate. However, I believe BIP39 should not be
> > > followed, because it reproduces two mistakes I did when I designed the
> > > older Electrum seed system. Let me explain.
> > > 
> > > The first problem I have with BIP39 is that the seed phrase does not
> > > include a version number.
> > > 
> > > Wallet development is still in an exploratory phase, and we should
> > > expect even more innovation in this domain. In this context, it is
> > > unwise to make decisions that prevent future innovation.
> > > 
> > > However, when we give a seed phrase to users, we have a moral obligation
> > > to keep supporting this seed phrase in future versions. We cannot simply
> > > announce to Electrum users that their old seed phrase is not supported
> > > anymore, because we created a new version of the software that uses a
> > > different derivation. This could lead to financial losses for users who
> > > are unaware of these technicalities. Well, at least, that is how I feel
> > > about it.
> > > 
> > > BIP39 and Electrum v2 have a very different ways of handling future
> > > innovation. Electrum v2 seed phrases include an explicit version number,
> > > that indicates how the wallet addresses should be derived. In contrast,
> > > BIP39 seed phrases do not include a version number at all. BIP39 is
> > > meant to be combined with BIP43, which stipulates that the wallet
> > > structure should depend on the BIP32 derivation path used for the wallet
> > > (although BIP43 is not followed by all BIP39 compatible wallets). Thus,
> > > innovation in BIP43 is allowed only within the framework of BIP32. In
> > > addition, 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.
> > > 
> > > The second problem I see with BIP39 is that it requires a fixed
> > > wordlist. Of course, this forbids innovation in the wordlist itself, but
> > > that's not the main problem. When you write a new standard, it is
> > > important to keep this standard minimal, given the goal you want to
> > > achieve. I believe BIP39 could (and should) have been written without
> > > including the wordlist in the standard.
> > > 
> > > There are two ways to derive a master key from a mnemonic phrase:
> > >  1. A bidirectional mapping between words and numbers, 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.
> > > 
> > > Electrum v1 uses (1). Electrum v2 uses (2).
> > > 
> > > Early versions of BIP39 used (1), and later they switched to (2).
> > > However, BIP39 uses (2) only in order to derive the wallet keys, not for
> > > its checksum. The BIP39 checksum uses (1), and it does requires a fixed
> > > wordlist. This is just plainly inconsistent. As a result, you have
> > > neither wordlist flexibility, nor Shamir secret sharing.
> > > 
> > > Having a fixed wordlist is very unfortunate. First, it means that BIP39
> > > will probably never leave the 'draft' stage, until all languages of the
> > > world have been added. Second, once you add a wordlist for a new
> > > language, you cannot change it anymore, because it will break existing
> > > seed phrases; therefore you have to be extremely careful in the way you
> > > design these wordlists. Third, languages often have words in common.
> > > When you add a new language to the list, you should not use words
> > > already used by existing wordlists, in order to ensure that the language
> > > can be detected. It leads to a first come first served situation, that
> > > might not be sustainable in the future.
> > > 
> > > In order to support the old Electrum v1 seeds, all future versions of
> > > Electrum will have to include the old wordlist. In addition, when
> > > generating new seed phrases, Electrum now has to avoid collisions with
> > > old seed phrases, because the old ones did not have a version number.
> > > This is painful enough, I will not repeat the same errors twice.
> > > 
> > > 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, 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, and no
> > > wordlist is required."
> > > 
> > > 
> > > Thomas
> > > 
> > > 
> > > Le 02/03/2015 16:37, Mike Hearn a écrit :
> > > > Congrats Thomas! Glad to see Electrum 2 finally launch.
> > > > 
> > > > 
> > > >> * New seed derivation method (not compatible with BIP39).
> > > > 
> > > > 
> > > > Does this mean a "12 words" wallet created by Electrum won't work if
> > > > imported into some other wallet that supports BIP39? Vice versa? This seems
> > > > unfortunate. I guess if seeds are being represented with 12 words
> > > > consistently, people will expect them to work everywhere.
> > > > 
> > > 
> > > ------------------------------------------------------------------------------
> > > Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> > > by Intel and developed in partnership with Slashdot Media, is your hub for all
> > > things parallel software development, from weekly thought leadership blogs to
> > > news, videos, case studies, tutorials and more. Take a look and join the 
> > > 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 the list, visit the Bitcoin-development Archives. |
> > > |  |
> > > | View on lists.sourceforge.net | Preview by Yahoo |
> > > |  |
> > > |   |
> > > 
> > >   
> > > 
> > >  
> > >    
> > 
> > > ------------------------------------------------------------------------------
> > > Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> > > by Intel and developed in partnership with Slashdot Media, is your hub for all
> > > things parallel software development, from weekly thought leadership blogs to
> > > news, videos, case studies, tutorials and more. Take a look and join the 
> > > conversation now. http://goparallel.sourceforge.net/
> > 
> > > _______________________________________________
> > > Bitcoin-development mailing list
> > > Bitcoin-development@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 17086 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[devrandom]

On 2015-03-12 04:51 AM, Neill Miller wrote:
> 
> Ok, I see your point here, 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.
> 
> 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, but at the moment it's not allowed there.  By removing that
> validating 'restriction', I agree with you that word lists have no
> need to be fixed.  But realistically, we still don't allow completely
> arbitrary words to be used because I don't see the word lists changing
> too often, nor implementations storing word lists of all words and
> languages.

A good way to go about this from a UX point of view is warn the user
that their "phrase is non-standard", but allow them to insist.

> 
> Thanks for clarifying,
> -Neill.
> 
> On Thu, Mar 12, 2015 at 04:21:59AM +0000, 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, the reason is that the only thing that happens when you change the wordlist is that entropy points to different words. But remember, entropy is disposed. Yes in my code I allow for the keeping of entropy etc, it also lets me "hot swap" between different language wordlists etc but in real world implementation the entropy is forgotten and not stored. So changing the wordlist merely allows new mnemonic phrases to be generated but it has a nil impact on previously generated 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 scenario. 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 rubbish words so for e.g "uyuy jkjasd sdsd sdsdd yuuyu sdsds iooioi sdasds uyuyuy sdsdsd tyyty rwetrtr" and no matter what BIP39 implementation you put it in, it will always generate the same seed
 bytes thus allowing for complete and universal seed derivation without any reliance on word list. The word list is merely to generate a mnemonic, after that it has no role in seed generation so you can change it at anytime and it will never effect future mnemonics.
>>
>> On Thu, Mar 12, 2015 at 02:16:38AM +0000, Thy Shizzle wrote:
>>> That's disappointing the Electrum 2.0 doesn't use BIP39.
>>
>> Agreed, but I don't know the full background on this.
>>
>>> Changing the wordlist in the future has ZERO effect on derived seed, whatever mnemonic you provide will always generate the same seed, BIP39 is not mapping the words back to numbers etc to derive seed.
>>
>> That's true for generating new mnemonics (i.e. same entropy can
>> generate any combinations of words), but not for converting a mnemonic
>> 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).
>>
>>> Version is something that can be dealt with after the fact, hopefully standardised (curious why didn't you work with the BIP39 to insert version instead of do something different to BIP39?)
>>> So most of what you are suggesting as problems are not.
>>
>> 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, but as of now, I'm in the camp that thinks
>> complete wallet interoperability is a bit of a myth -- so long as you
>> can fundamentally move into/out of wallets at will.
>>
>> -Neill.
>>
>>> As for the common words between languages, I have discussed this with the provider of the Chinese wordlists as they shared some words between simplified and traditional, 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, remembering you get minimum 12 goes at doing that :)
>>> Also then I asked myself, do we really care about detecting the language? Probably not because we don't need to use the wordlist ever again after creation, we literally accept the mnemonic, normalise it then hash it into a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it would take almost no effort to put it in and I think you should do 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, and sorry to answer a bit late; it has been a busy couple
>>> of weeks.
>>>
>>> You are correct, a BIP39 seed phrase will not work in Electrum, and vice
>>> versa. It is indeed unfortunate. However, I believe BIP39 should not be
>>> followed, because it reproduces two mistakes I did when I designed the
>>> older Electrum seed system. Let me explain.
>>>
>>> The first problem I have with BIP39 is that the seed phrase does not
>>> include a version number.
>>>
>>> Wallet development is still in an exploratory phase, and we should
>>> expect even more innovation in this domain. In this context, it is
>>> unwise to make decisions that prevent future innovation.
>>>
>>> However, when we give a seed phrase to users, we have a moral obligation
>>> to keep supporting this seed phrase in future versions. We cannot simply
>>> announce to Electrum users that their old seed phrase is not supported
>>> anymore, because we created a new version of the software that uses a
>>> different derivation. This could lead to financial losses for users who
>>> are unaware of these technicalities. Well, at least, that is how I feel
>>> about it.
>>>
>>> BIP39 and Electrum v2 have a very different ways of handling future
>>> innovation. Electrum v2 seed phrases include an explicit version number,
>>> that indicates how the wallet addresses should be derived. In contrast,
>>> BIP39 seed phrases do not include a version number at all. BIP39 is
>>> meant to be combined with BIP43, which stipulates that the wallet
>>> structure should depend on the BIP32 derivation path used for the wallet
>>> (although BIP43 is not followed by all BIP39 compatible wallets). Thus,
>>> innovation in BIP43 is allowed only within the framework of BIP32. In
>>> addition, 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.
>>>
>>> The second problem I see with BIP39 is that it requires a fixed
>>> wordlist. Of course, this forbids innovation in the wordlist itself, but
>>> that's not the main problem. When you write a new standard, it is
>>> important to keep this standard minimal, given the goal you want to
>>> achieve. I believe BIP39 could (and should) have been written without
>>> including the wordlist in the standard.
>>>
>>> There are two ways to derive a master key from a mnemonic phrase:
>>>  1. A bidirectional mapping between words and numbers, 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.
>>>
>>> Electrum v1 uses (1). Electrum v2 uses (2).
>>>
>>> Early versions of BIP39 used (1), and later they switched to (2).
>>> However, BIP39 uses (2) only in order to derive the wallet keys, not for
>>> its checksum. The BIP39 checksum uses (1), and it does requires a fixed
>>> wordlist. This is just plainly inconsistent. As a result, you have
>>> neither wordlist flexibility, nor Shamir secret sharing.
>>>
>>> Having a fixed wordlist is very unfortunate. First, it means that BIP39
>>> will probably never leave the 'draft' stage, until all languages of the
>>> world have been added. Second, once you add a wordlist for a new
>>> language, you cannot change it anymore, because it will break existing
>>> seed phrases; therefore you have to be extremely careful in the way you
>>> design these wordlists. Third, languages often have words in common.
>>> When you add a new language to the list, you should not use words
>>> already used by existing wordlists, in order to ensure that the language
>>> can be detected. It leads to a first come first served situation, that
>>> might not be sustainable in the future.
>>>
>>> In order to support the old Electrum v1 seeds, all future versions of
>>> Electrum will have to include the old wordlist. In addition, when
>>> generating new seed phrases, Electrum now has to avoid collisions with
>>> old seed phrases, because the old ones did not have a version number.
>>> This is painful enough, I will not repeat the same errors twice.
>>>
>>> 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, 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, and no
>>> wordlist is required."
>>>
>>>
>>> Thomas
>>>
>>>
>>> Le 02/03/2015 16:37, Mike Hearn a écrit :
>>>> Congrats Thomas! Glad to see Electrum 2 finally launch.
>>>>
>>>>
>>>>> * New seed derivation method (not compatible with BIP39).
>>>>
>>>>
>>>> Does this mean a "12 words" wallet created by Electrum won't work if
>>>> imported into some other wallet that supports BIP39? Vice versa? This seems
>>>> unfortunate. I guess if seeds are being represented with 12 words
>>>> consistently, people will expect them to work everywhere.
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>>> things parallel software development, from weekly thought leadership blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the 
>>> 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 the list, visit the Bitcoin-development Archives. |
>>> |  |
>>> | View on lists.sourceforge.net | Preview by Yahoo |
>>> |  |
>>> |   |
>>>
>>>    
>>>
>>>   
>>>     
>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>>> things parallel software development, from weekly thought leadership blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the 
>>> conversation now. http://goparallel.sourceforge.net/
>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

-- 
devrandom / Miron

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[devrandom]

On 2015-03-12 03:28 AM, Andreas Schildbach wrote:
> That doesn't work for mobile wallets, because we need to consider the
> offline case. To fix this, we'd need to extend BIP70 to tell the
> merchant where to forward the half-signed transaction to. Then again I'm
> not sure if we want that, for privacy reasons. In any case, practical

Telling the merchant who my security provider is not that different from
a privacy point of view from using their wifi.  In both cases they would
see us connect to the provider.  The connection / payload would be
encrypted of course.

In the mean time, we can un-multisig some of the coins for daily use, up
to a defined velocity limit.  (credit to Mike Hearn's for this idea)

> multisig is still a looong way off.

Let's bring it closer.  p2sh.info shows an exponential increase,
currently at 8%.  At this rate, the majority of the coins will be
multisig near the end of the year.

> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

-- 
devrandom / Miron

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

Den 12 mar 2015 19:52 skrev "Andreas Schildbach" <andreas@schildbach.de>:
>
> I'm afraid this will never fly. Wallets are just too different and
> that's a good thing! For example, by design choice Bitcoin Wallet and
> bitcoinj doesn't support multiple accounts. How would it ever import
> wallets from MultiBit or Mycelium?

I think I covered that with the "importing wallet says what sections it
supports" part. Then you'd only ask for the library to give you the
addresses from the first branch in the main HD wallet. The user would be
told that you by design can't manage the other parts. The user would be
alerted and get the recommendation to send the funds over manually if they
want to switch their wallet. The user might however just want to export
that one single branch if he's a "power user", so he would proceed to use
it that way.

At export, I recommend the wallet will tell the user what extensions and
standards are in use (and which are necessary to recover how much of their
funds in the target wallet). The user would be asked to confirm that the
target wallet client supports these. The user should be given the option to
hand the list of supported functionality in the target wallet (like a list
of BIP numbers?), and tell the wallet to move the funds around so that the
target wallet can successfully import everything and recover all funds.

Actually, thinking about it I think what we really need first is a standard
synchronization / transition protocol. Right now we don't have more than
the address label syncing plugin for Electrum. We need something for
wallets to synchronize state, with the option for having one wallet tell
the other how to send over all funds (for when they use completely
different standards for managing funds). As the most simple option, the
target wallet would provide a list of addresses to the sending wallet when
you switch (this would satisfy Bryan's request).

[-- Attachment #2: Type: text/html, Size: 2148 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Bryan Bishop]

On Wed, Mar 11, 2015 at 11:09 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> For an emergency transition the user is probably better off with an
> explicit unstructured mass private key export, and a sweep function;
> and guaranteeing compatibility with that is much easier; and because
> it moves funds in one direction there is much less chance of going
> from secure to insecure.

I haven't looked at the existing sweep implementations, but it would
be unfortunate if sweep functions were not available that create at
least the same number of keys, or possibly more, for the purposes of
sweeping. I suppose there are different levels of emergency, where
perhaps you want to sweep all at once in a single transaction and lose
out on (already nebulous) privacy benefits. I say nebulous because
broadcasting a bunch of transactions all at the same time during the
sweep can compromise privacy even when the transactions have no common
ancestor outputs.

- Bryan
http://heybryan.org/
1 512 203 0507

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

On 03/12/2015 07:27 PM, Natanael wrote:
> 
> Den 12 mar 2015 17:48 skrev "Mike Hearn" <mike@plan99.net
> <mailto:mike@plan99.net>>:
>>>
>>> b) "Creation date" is just a short-term hack.
>>
>>
>> I agree, but we need things to be easy in the short term as well as
> the long term :) 
>>
>> The long term solution is clearly to have the 12 word seed be an
> encryption key for a wallet backup with all associated metadata. We're
> heading in that direction one step at a time. Unfortunately it will take
> time for wallets to start working this way, and all the pieces to fall
> into place. Restoring from the block chain will be a semi regular
> operation for users until then.
> 
> This have been mentioned a few times before, and what I think is
> necessary is to create a common file format that can be interpreted by a
> library which all wallets can use. I see it as similar as the work to
> create libconsensus for parsing the blockchain.


I'm afraid this will never fly. Wallets are just too different and
that's a good thing! For example, by design choice Bitcoin Wallet and
bitcoinj doesn't support multiple accounts. How would it ever import
wallets from MultiBit or Mycelium?

Bitcoinj-based wallets could probably share the bitcoinj protobuf wallet
format (or whatever format we will be at the time of the "merge" – we
already have tons of requirements piling up!). This would mean bitcoinj
is the "consensus library equivalent" you were mentioning.

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 3387 bytes --]

Den 12 mar 2015 17:48 skrev "Mike Hearn" <mike@plan99.net>:
>>
>> b) "Creation date" is just a short-term hack.
>
>
> I agree, but we need things to be easy in the short term as well as the
long term :)
>
> The long term solution is clearly to have the 12 word seed be an
encryption key for a wallet backup with all associated metadata. We're
heading in that direction one step at a time. Unfortunately it will take
time for wallets to start working this way, and all the pieces to fall into
place. Restoring from the block chain will be a semi regular operation for
users until then.

This have been mentioned a few times before, and what I think is necessary
is to create a common file format that can be interpreted by a library
which all wallets can use. I see it as similar as the work to create
libconsensus for parsing the blockchain.

We need something extensible that can describe how to derive all addresses
used by the user. What HD branches to derive and how, with block numbers
(or bloom filters of block hashes or similar) to note where all previously
known transactions related to the wallet have occurred, and the last known
block (so only new blocks need to be scanned).

A way to describe one HD tree as a multisignature wallet tied to a hardware
wallet if you have that (could include serial number or MAC of the device
for simple identification by the wallet client). A way to describe another
set of addresses as using a custom extension. A way to denote one private
key as being used for stealth addresses together with details for how to
identify the transactions (prefix, mailbox to look in, etc). Labels for
transactions. P2SH script templates so those addresses can be recovered. A
way to describe Copay style multisignature wallets and what server to use
for coordinating with the other coowners. A way to describe threshold
crypto group signature wallets and how to coordinate. Computer parsable
descriptions of HD branches as change addresses, as being used for
receiving payments in merchant payment systems, etc... Also, you should
really be talking to people like accountants and auditors to see what
features they'd like to see when it comes to things like how company
wallets could have rules defined for how to use the various HD branches.

And so on... I think you get my point by now.

The basic idea is that the wallet uses the library to parse the wallet file
and tells the user which sections it understands (can't expect all wallets
to handle custom extensions or stealth addresses, etc), then proceeds to
scan the blockchain for those addresses. Then the user also won't be
surprised that not all funds are found and won't think they're lost.

I think it should be referred to as an import/export format, more than as a
backup format.

You always want the most recent metadata the wallet of origin can provide
when importing, to reduce unnecessary extra work. You don't want really old
backup files. If people add new seeds and various new extensions that can't
be automatically recovered from old wallet backups, they need new backups.
You might as well use the wallet's own internal formats for backup, as the
wallet developer might better know how to optimize for the use cases he
have designed for. But at the same time we should ask wallet developers to
offer conversion tools to generate export format files from custom wallet
data files.

[-- Attachment #2: Type: text/html, Size: 3698 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]

When Jim and I were selecting which combination of HD wallet structures to
support we noted the following:

* BIP39 is a good standard list to select from that mandates words that do
not look similar to each other, a certain spelling (no English US/UK
confusion) and possible foreign language variants provided by experts later
* BIP32 (m/0h/0/0) and BIP44 (m/44h/0h/0h/0/0) allow for maximum
compatibility with other wallets
* including a date in the "wallet words" themselves is open to spoofing
since the generator cannot be sure the date is correct (local time drift,
provided externally by untrusted third party etc)
* a timestamp as optional external metadata is useful to reduce sync times
in SPV
* our experience verified that users will very often enter a timestamp
incorrectly (locale, fat fingers, bad memory etc) so we opted for "number
of days elapsed since Bitcoin genesis block with a modulo 97 checksum
appended" (e.g. 1850/07) to mitigate this
* if a user has no timestamp then blank is the only alternative (no
guessing) which is interpreted as "earliest possible BIP32 date"
* if restoring the user has to select where the "wallet words" came from
(e.g. MultiBit HD, Trezor, Mycelium etc)

Users will naturally assume that they can type their "wallet words" (a more
mainstream-friendly term than "seed phrase") into any wallet and with a bit
of fiddling about get their bitcoins back. As wallet developers it is
within our capability to make that happen and I think we're quite close
already.

[-- Attachment #2: Type: text/html, Size: 1667 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 3306 bytes --]

When Jim and I were selecting which combination of HD wallet structures to
support we noted the following:

* BIP39 is a good standard list to select from that mandates words that do
not look similar to each other, a certain spelling (no English US/UK
confusion) and possible foreign language variants provided by experts later
* BIP32 (m/0h/0/0) and BIP44 (m/44h/0h/0h/0/0) allow for maximum
compatibility with other wallets
* including a date in the "wallet words" themselves is open to spoofing
since the generator cannot be sure the date is correct (local time drift,
provided externally by untrusted third party etc)
* a timestamp as optional external metadata is useful to reduce sync times
in SPV
* our experience verified that users will very often enter a timestamp
incorrectly (locale, fat fingers, bad memory etc) so we opted for "number
of days elapsed since Bitcoin genesis block with a modulo 97 checksum
appended" (e.g. 1850/07) to mitigate this
* if a user has no timestamp then blank is the only alternative (no
guessing) which is interpreted as "earliest possible BIP32 date"
* if restoring the user has to select where the "wallet words" came from
(e.g. MultiBit HD, Trezor, Mycelium etc)

Users will naturally assume that they can type their "wallet words" (a more
mainstream-friendly term than "seed phrase") into any wallet and with a bit
of fiddling about get their bitcoins back. As wallet developers it is
within our capability to make that happen and I think we're quite close
already.

On 12 March 2015 at 16:47, Mike Hearn <mike@plan99.net> wrote:

> b) "Creation date" is just a short-term hack.
>>
>
> I agree, but we need things to be easy in the short term as well as the
> long term :)
>
> The long term solution is clearly to have the 12 word seed be an
> encryption key for a wallet backup with all associated metadata. We're
> heading in that direction one step at a time. Unfortunately it will take
> time for wallets to start working this way, and all the pieces to fall into
> place. Restoring from the block chain will be a semi regular operation for
> users until then.
>
> WRT version number I have no real strong feelings about this. But
> representing short pieces of binary data as words is so convenient, it
> seems likely that it could be similar to addresses: people find other uses
> for this mechanism beyond just storing a raw private key. Bitcoin addresses
> have versions and that's proven to be useful several times, even though in
> theory an address is "just" a hash of a pubkey.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
Bitcoin Solutions Ltd provides bespoke software and consultancy. Find us at
bitcoin-solutions.co.uk.

[-- Attachment #2: Type: text/html, Size: 4743 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

>
> b) "Creation date" is just a short-term hack.
>

I agree, but we need things to be easy in the short term as well as the
long term :)

The long term solution is clearly to have the 12 word seed be an encryption
key for a wallet backup with all associated metadata. We're heading in that
direction one step at a time. Unfortunately it will take time for wallets
to start working this way, and all the pieces to fall into place. Restoring
from the block chain will be a semi regular operation for users until then.

WRT version number I have no real strong feelings about this. But
representing short pieces of binary data as words is so convenient, it
seems likely that it could be similar to addresses: people find other uses
for this mechanism beyond just storing a raw private key. Bitcoin addresses
have versions and that's proven to be useful several times, even though in
theory an address is "just" a hash of a pubkey.

[-- Attachment #2: Type: text/html, Size: 1323 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

Thy, your message threading is broken. Can you make sure your mail
program uses the correct message ID when replying?

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

For reasonably skilled users your points are valid, but I'm sure you
also – like me – encountered the kind of user who has absolutely no clue
but thinks he understands. S/he will ignore warnings and run into
troubles. This generates a huge amount of support cases and likely tears
about lost coins.

The simple fact that someone elses broken RNG implementation/wrapper
could compromise the security of my software frightens me.


On 03/11/2015 08:04 PM, Jim wrote:
> The wallet words system isn't perfect for sure but it does help the user in two main ways:
> 1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening.
> 2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this.
> 
> I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are.
> 
> It can be a simple help page saying:
> "If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this.
> If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this."
> 
> That way users have clear instructions on how to recover their bitcoins.
> Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins.
> 

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

On 03/12/2015 01:11 AM, Gregory Maxwell wrote:

> Ultimately, the most fundamental compatibility is guaranteed:  you can
> always send your funds to another wallet. This always works and
> guarantees that you are never locked in to a single wallet. It is well
> tested and cannot drive any software in to weird or confused states.

This.

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

That doesn't work for mobile wallets, because we need to consider the
offline case. To fix this, we'd need to extend BIP70 to tell the
merchant where to forward the half-signed transaction to. Then again I'm
not sure if we want that, for privacy reasons. In any case, practical
multisig is still a looong way off.


On 03/12/2015 12:50 AM, devrandom wrote:
> I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig.  The mobile has a key, the desktop has
> a key and a third-party security oracle has a third key.  The oracle
> would have different security thresholds for countersigning the mobile.
> 
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
> 
> 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.
> 
> On 2015-03-11 04:22 PM, Mike Hearn wrote:
>> Users will want to have wallets shared between devices, it's as simple
>> as that, especially for mobile/desktop wallets. Trying to stop them from
>> doing that by making things gratuitously incompatible isn't the right
>> approach:  they'll just find workarounds or wallet apps will learn how
>> to import seeds from other apps. Better to just explain the risks and
>> help people mitigate them.
>>
>> On Wed, Mar 11, 2015 at 3:57 PM, Aaron Voisine <voisine@gmail.com
>> <mailto:voisine@gmail.com>> wrote:
>>
>>     I'm not convinced that wallet seed interoperability is such a great
>>     thing. There is a wide variability in the quality and security level
>>     of wallet implementations and platforms. Each new device and wallet
>>     software a user types their seed into increases their attack surface
>>     and exposure to flaws. Their security level is reduced to the lowest
>>     common denominator. I see the need for a "fire exit", certainly, but
>>     we must also remember that fire exits are potential entrances for
>>     intruders.
>>
>>     Aaron Voisine
>>     co-founder and CEO
>>     breadwallet.com <http://breadwallet.com>
>>
>>     On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell
>>     <gmaxwell@gmail.com <mailto:gmaxwell@gmail.com>> wrote:
>>
>>         On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
>>         <ricardojdfilipe@gmail.com <mailto:ricardojdfilipe@gmail.com>>
>>         wrote:
>>         > i guess you look at the glass half full :)
>>         > even though what you say is true, we should aim for wallets not to
>>         > require those instructions, by standardizing these things in BIPs.
>>         > let's hope bitcoin doesn't fail in standards as our industries have in
>>         > the past...
>>
>>         There are genuine principled disagreements on how some things should
>>         be done. There are genuine differences in functionality.
>>
>>         We cannot expect and should not expect complete compatibility.
>>         If you
>>         must have complete compatibility: use the same software (or
>>         maybe not
>>         even then, considering how poor the forward compatibility of some
>>         things has been..).
>>
>>         What we can hope to do, and I think the best we can hope to do,
>>         is to
>>         minimize the amount of gratuitous incompatibility and reduce the
>>         amount of outright flawed constructions (so if there are choices
>>         which
>>         must be made, they're at least choices among relatively good
>>         options).
>>
>>         ------------------------------------------------------------------------------
>>         Dive into the World of Parallel Programming The Go Parallel
>>         Website, sponsored
>>         by Intel and developed in partnership with Slashdot Media, is
>>         your hub for all
>>         things parallel software development, from weekly thought
>>         leadership blogs to
>>         news, videos, case studies, tutorials and more. Take a look and
>>         join the
>>         conversation now. http://goparallel.sourceforge.net/
>>         _______________________________________________
>>         Bitcoin-development mailing list
>>         Bitcoin-development@lists.sourceforge.net
>>         <mailto:Bitcoin-development@lists.sourceforge.net>
>>         https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>     ------------------------------------------------------------------------------
>>     Dive into the World of Parallel Programming The Go Parallel Website,
>>     sponsored
>>     by Intel and developed in partnership with Slashdot Media, is your
>>     hub for all
>>     things parallel software development, from weekly thought leadership
>>     blogs to
>>     news, videos, case studies, tutorials and more. Take a look and join the
>>     conversation now. http://goparallel.sourceforge.net/
>>     _______________________________________________
>>     Bitcoin-development mailing list
>>     Bitcoin-development@lists.sourceforge.net
>>     <mailto:Bitcoin-development@lists.sourceforge.net>
>>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the 
>> conversation now. http://goparallel.sourceforge.net/
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> 

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thomas Voegtlin]

Hi Andreas,

I don't think it's a problem that BIP43 is tied to BIP32.

What I don't like is that you have to explore branches of the derivation
tree, in order to know if there is a wallet. As a result, it is not
possible for the software to give a negative answer, like "this wallet
is empty", because you do not know if you have explored all the possible
derivations; a new one may have been added after the software was written.

With a version number, you can answer "sorry this seed is not recognized
by me", and you do not need to be online to do that.
If you are online, you can answer "this wallet is empty" after exploring it.




Le 11/03/2015 16:31, Andreas Schildbach a écrit :
> Thanks Thomas, for sharing your experience!
> 
> I'd like know why you think it's a problem that BIP43 is tied to BIP32?
> I understand we all agreed at least on the BIP32-derivation spec
> (excluding the BIP32-hierarchy spec)?
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

  Why on earth would you want to derive the mnemonic from the wallet seed? Ever?
Remembering that as an attacker doesn't actually have to do any key stretching, they can just keep trying (what is it 64 bytes from memory?) at a time without any PBKDF2 to attack a seed, it seems that the PBKDF2 is just to slow down anyone attempting to attack through an interface such as a web service or to a TREZOR or whatever, in a real world attack you would not even be performing PBKDF2 you would just brute force the raw bytes and force them into the BIP32 wallet as there is no Authentication scheme that hashes and compares against the result. It purely limits abuse through an online wallet provider or something like that by slowing down seed generation attempts THROUGH that API, it doesn't really add any security to the seed in a real world brute force attack! So yea I think the 2048 iteration count is sufficient for it's purpose because even if it only forces an extra 1ms per seed generation through the API, it is still slower than just brute forcing the 64 bytes straight up, and so they would have no reason to abuse your API that is all :)
"meh... the fact that you can't derive the seed phrase from the wallet seed, and that the password key stretching is so weak as to be ineffectual security theater bugs me. Feels like a pretty big compromise to work on current generation low power embedded devices when the next generation will be more than capable. But I understand the motivation for the compromise.

Aaron Voisine
co-founder and CEO
breadwallet.com"

[-- Attachment #2: Type: text/html, Size: 2855 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Aaron Voisine]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

On Wed, Mar 11, 2015 at 10:12 PM, Thy Shizzle <thashiznets@yahoo.com.au>
wrote:
>
> BIP39 is beautiful.

meh... the fact that you can't derive the seed phrase from the wallet seed,
and that the password key stretching is so weak as to be ineffectual
security theater bugs me. Feels like a pretty big compromise to work on
current generation low power embedded devices when the next generation will
be more than capable. But I understand the motivation for the compromise.

Aaron Voisine
co-founder and CEO
breadwallet.com

[-- Attachment #2: Type: text/html, Size: 671 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

[-- Attachment #1: Type: text/plain, Size: 3424 bytes --]

Yes I agree with this sentiment.
As for the version, don't forget we can kinda "brute force" our way to determine 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 really 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 acceptable 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:

   
   - 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.

To my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just different scheme for key derivation (myTREZOR uses full BIP44, Multibit HD uses BIP44 with first account only and GreenAddress uses another scheme because it's multisig only wallet).
I disagree with the need of some version "magic flags" or creation date stored in the mnemnonic, for those reasons:
a) If we fail in the way how mnemonic algo is defined, then 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 implementations cannot rely on it. I know Thomas was sound proponent of this solution, but he was unable to give any reasonable rules about who/how define meaning of version flag.
b) "Creation date" is just a short-term hack. Considering that mnemonic words are kind of cold storage (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 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.
> From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed between wallet providers. 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.
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 any 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 feeling 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 anything else.
Cheers,Marek

[-- Attachment #2: Type: text/html, Size: 5971 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Gregory Maxwell]

On Thu, Mar 12, 2015 at 2:41 AM, devrandom <c1.sf-bitcoin@niftybox.net> wrote:
> I think there are some important advantages to not being forced to use
> the old wallet to send coins when switching wallets. The three I can
> think of right now are: maintaining transaction history,

Just loading a key doesn't keep transaction history however, if the
loading wallet can't understand or infer metadata about the
transactions. You get some mass of data but to tell actually what the
transactions are, or what they were for, forensic accounting is
required and some data will be potentially unrecoverable.

The best way to preserve historical information is to use reporting
from the wallet in question; which will accurately record the best
available output for this. (E.g. Bitcoin-qt has a CSV export or you
can take a json list-transactions out of it).

> emergency transition when a wallet has a serious (e.g. money losing) bug

This cuts both ways, we've seen significant losses for users in
Bitcoin Core where they've used the console to import keys that they
also used in other insecure clients.

For an emergency transition the user is probably better off with an
explicit unstructured mass private key export, and a sweep function;
and guaranteeing compatibility with that is much easier; and because
it moves funds in one direction there is much less chance of going
from secure to insecure.

> and web
> wallet with server down.

I suppose it would be too much to ask that these web wallets actually
not be totally centrally controlled and have the potential of just
having someone else stand up a server. I guess not. :(

Emergencies being what the are you do with what you can... indeed, I
agree thats a reason that better compatibility is better. (But perhaps
best is that its insane to use software to handle your money that can
just be taken away from you like that...)

> Another important reason to standardize is to reduce the "roll your own
> crypto" temptation on the wallet creator part, where the wallet-specific
> algorithm is more likely to contain weaknesses.
> I do agree that trying to come up with one uber standard will likely
> fail and is probably counter productive.

Careful with this line of thinking: We have no mechanism in the BIP
process to exclude weak cryptography.

A BIP is not a measure of cryptographic integrity. There are existing
BIPs which I consider flawed and would not use or recommend.

It result in some level of review, maybe, and so it can be productive
to at least have more eyes on fewer things; which is a reason I
wouldn't say don't bother trying.

And indeed, I do think that what can be standardized should be, my
words weren't intended to dismiss anyone's efforts, only to encourage
realistic (I think) expectations around what will come of it.

And while I hope for no gratuitous incompatibility, I also hope that
no one working on a wallet hesitates for a minute to offer a new and
interesting functionality just because it doesn't fit into a prefab
shape.

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Neill Miller]

On Thu, Mar 12, 2015 at 02:16:38AM +0000, Thy Shizzle wrote:
> That's disappointing the Electrum 2.0 doesn't use BIP39.

Agreed, but I don't know the full background on this.

> Changing the wordlist in the future has ZERO effect on derived seed, whatever mnemonic you provide will always generate the same seed, BIP39 is not mapping the words back to numbers etc to derive seed.

That's true for generating new mnemonics (i.e. same entropy can
generate any combinations of words), but not for converting a mnemonic
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).

> Version is something that can be dealt with after the fact, hopefully standardised (curious why didn't you work with the BIP39 to insert version instead of do something different to BIP39?)
> So most of what you are suggesting as problems are not.

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, but as of now, I'm in the camp that thinks
complete wallet interoperability is a bit of a myth -- so long as you
can fundamentally move into/out of wallets at will.

-Neill.

> As for the common words between languages, I have discussed this with the provider of the Chinese wordlists as they shared some words between simplified and traditional, 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, remembering you get minimum 12 goes at doing that :)
> Also then I asked myself, do we really care about detecting the language? Probably not because we don't need to use the wordlist ever again after creation, we literally accept the mnemonic, normalise it then hash it into a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it would take almost no effort to put it in and I think you should do 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, and sorry to answer a bit late; it has been a busy couple
> of weeks.
> 
> You are correct, a BIP39 seed phrase will not work in Electrum, and vice
> versa. It is indeed unfortunate. However, I believe BIP39 should not be
> followed, because it reproduces two mistakes I did when I designed the
> older Electrum seed system. Let me explain.
> 
> The first problem I have with BIP39 is that the seed phrase does not
> include a version number.
> 
> Wallet development is still in an exploratory phase, and we should
> expect even more innovation in this domain. In this context, it is
> unwise to make decisions that prevent future innovation.
> 
> However, when we give a seed phrase to users, we have a moral obligation
> to keep supporting this seed phrase in future versions. We cannot simply
> announce to Electrum users that their old seed phrase is not supported
> anymore, because we created a new version of the software that uses a
> different derivation. This could lead to financial losses for users who
> are unaware of these technicalities. Well, at least, that is how I feel
> about it.
> 
> BIP39 and Electrum v2 have a very different ways of handling future
> innovation. Electrum v2 seed phrases include an explicit version number,
> that indicates how the wallet addresses should be derived. In contrast,
> BIP39 seed phrases do not include a version number at all. BIP39 is
> meant to be combined with BIP43, which stipulates that the wallet
> structure should depend on the BIP32 derivation path used for the wallet
> (although BIP43 is not followed by all BIP39 compatible wallets). Thus,
> innovation in BIP43 is allowed only within the framework of BIP32. In
> addition, 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.
> 
> The second problem I see with BIP39 is that it requires a fixed
> wordlist. Of course, this forbids innovation in the wordlist itself, but
> that's not the main problem. When you write a new standard, it is
> important to keep this standard minimal, given the goal you want to
> achieve. I believe BIP39 could (and should) have been written without
> including the wordlist in the standard.
> 
> There are two ways to derive a master key from a mnemonic phrase:
>  1. A bidirectional mapping between words and numbers, 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.
> 
> Electrum v1 uses (1). Electrum v2 uses (2).
> 
> Early versions of BIP39 used (1), and later they switched to (2).
> However, BIP39 uses (2) only in order to derive the wallet keys, not for
> its checksum. The BIP39 checksum uses (1), and it does requires a fixed
> wordlist. This is just plainly inconsistent. As a result, you have
> neither wordlist flexibility, nor Shamir secret sharing.
> 
> Having a fixed wordlist is very unfortunate. First, it means that BIP39
> will probably never leave the 'draft' stage, until all languages of the
> world have been added. Second, once you add a wordlist for a new
> language, you cannot change it anymore, because it will break existing
> seed phrases; therefore you have to be extremely careful in the way you
> design these wordlists. Third, languages often have words in common.
> When you add a new language to the list, you should not use words
> already used by existing wordlists, in order to ensure that the language
> can be detected. It leads to a first come first served situation, that
> might not be sustainable in the future.
> 
> In order to support the old Electrum v1 seeds, all future versions of
> Electrum will have to include the old wordlist. In addition, when
> generating new seed phrases, Electrum now has to avoid collisions with
> old seed phrases, because the old ones did not have a version number.
> This is painful enough, I will not repeat the same errors twice.
> 
> 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, 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, and no
> wordlist is required."
> 
> 
> Thomas
> 
> 
> Le 02/03/2015 16:37, Mike Hearn a écrit :
> > Congrats Thomas! Glad to see Electrum 2 finally launch.
> > 
> > 
> >> * New seed derivation method (not compatible with BIP39).
> > 
> > 
> > Does this mean a "12 words" wallet created by Electrum won't work if
> > imported into some other wallet that supports BIP39? Vice versa? This seems
> > unfortunate. I guess if seeds are being represented with 12 words
> > consistently, people will expect them to work everywhere.
> > 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> 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 the list, visit the Bitcoin-development Archives. |
> |  |
> | View on lists.sourceforge.net | Preview by Yahoo |
> |  |
> |   |
> 
>   
> 
>  
>    

> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/

> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[slush]

[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]

On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn <mike@plan99.net> wrote:

>
>    - 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.
>
> To my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just
different scheme for key derivation (myTREZOR uses full BIP44, Multibit HD
uses BIP44 with first account only and GreenAddress uses another scheme
because it's multisig only wallet).

I disagree with the need of some version "magic flags" or creation date
stored in the mnemnonic, for those reasons:

a) If we fail in the way how mnemonic algo is defined, then 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 implementations cannot
rely on it. I know Thomas was sound proponent of this solution, but he was
unable to give any reasonable rules about who/how define meaning of version
flag.

b) "Creation date" is just a short-term hack. Considering that mnemonic
words are kind of cold storage (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 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.

> From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed
between wallet providers. 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.

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
any 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 feeling 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
anything else.

Cheers,
Marek

[-- Attachment #2: Type: text/html, Size: 4001 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[devrandom]

On 2015-03-11 05:11 PM, Gregory Maxwell wrote:
> On Wed, Mar 11, 2015 at 11:50 PM, devrandom <c1.sf-bitcoin@niftybox.net> wrote:
>> 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.
> 
> The fact remains that there are several apparently unresolvable
> well-principled perspectives on this subject.
> 
> (And I can speak to this personally: There are several BIPs in this
> space that I'd rather not see in product with my name on it.)
> 
> Unless two wallets have exactly the same feature set, cross importing
> keys is going to confuse or break something. Even if you're trying to
> be fairly generic the testing overhead for all possible strategies and
> structures is large. Expecting compatibility here would be like
> expecting two large commercial accounting packages to support the same
> internal file formats. Compatibility is only straight forward when the
> feature set is as limited as possible.

You make some good points.  However, I still hope for standardization by
"profile".  E.g. a "consumer profile" for wallets with just one account,
a "business profile" for small business wallets.  If an application
falls outside of the standardized profiles, they can roll their own or
try to promote a new standard.

I think there are some important advantages to not being forced to use
the old wallet to send coins when switching wallets. The three I can
think of right now are: maintaining transaction history, emergency
transition when a wallet has a serious (e.g. money losing) bug and web
wallet with server down.

Another important reason to standardize is to reduce the "roll your own
crypto" temptation on the wallet creator part, where the wallet-specific
algorithm is more likely to contain weaknesses.

I do agree that trying to come up with one uber standard will likely
fail and is probably counter productive.

> 
> The space for weird behavior to harm users is pretty large... e.g. you
> could load a key into two wallets, such that one can see all the funds
> by the other, but not vice versa and and up losing funds by
> incorrectly assuming you had no coins; or inadvertently rip of your
> business partners by accounting for things incorrectly.
> 
> Even ignoring compatibility, most demanded use cases here are ones
> that create concurrent read/write use of single wallet without some
> coordinating service is inherently somewhat broken because you can
> double spend yourself, and end up with stalled and stuck transactions
> and causing people to think you tried ripping them off.
> 
> I certainly recognize the desirable aspects of just being able to load
> a common wallet, and that inexperienced users expect it to just work.
> But I don't think that expectation is currently very realistic except
> within limited domains. It may be more realistic in the future when
> the role of wallets is better established. I don't see any _harm_ in
> trying to standardize what can be, I just don't expect to see a lot of
> success.
> 
> Ultimately, the most fundamental compatibility is guaranteed:  you can
> always send your funds to another wallet. This always works and
> guarantees that you are never locked in to a single wallet. It is well
> tested and cannot drive any software in to weird or confused states.
> 

-- 
devrandom / Miron

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

[-- Attachment #1: Type: text/plain, Size: 2943 bytes --]

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) should use BIP39  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 right?

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.

> 
> 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.

> 
> 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.
> 
> I don't think it is quite the doom and gloom I'm reading :)
> 
> 
> devrandom:
> "I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig.  The mobile has a key, the desktop has
> a key and a third-party security oracle has a third key.  The oracle
> would have different security thresholds for countersigning the mobile.
> 
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
> 
> 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."

-- 
devrandom / Miron

[-- Attachment #2: Type: text/html, Size: 4250 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[devrandom]

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 right?

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.

> 
> 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.

> 
> 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.
> 
> I don't think it is quite the doom and gloom I'm reading :)
> 
> 
> devrandom:
> "I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig.  The mobile has a key, the desktop has
> a key and a third-party security oracle has a third key.  The oracle
> would have different security thresholds for countersigning the mobile.
> 
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
> 
> 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."

-- 
devrandom / Miron

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thy Shizzle]

[-- Attachment #1: Type: text/plain, Size: 8579 bytes --]

That's disappointing the Electrum 2.0 doesn't use BIP39.
From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed between wallet providers. 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. This would seem to be the reasoning for the reference word lists. Now there is nothing stopping one from implementing a wordlist of say profanities or star wars terms or whatever and still accepting a mnemonic from another provider. Remember if you have a mnemonic from a different wordlist, simply Normalization of the words occurs and then the hashing the mnemonic to derive the seed bytes. It is not really a restriction at all! BIP39 was designed such that the mnemonic generation is decoupled from seed derivation, just like what you are saying Electrum 2.0 can do! The wordlist is only needed for mnemonic generation NOT seed derivation, so Electrum DOES NOT need a copy of the BIP39 word lists to generate the seed from the phrase, there is really not much reason for Electrum not to accept BIP39 mnemonics at the moment! it requires bugger all code! Here is my seed generation code



//literally this is the bulk of the decoupled seed generation code, easy.byte[] salt = Utilities.MergeByteArrays(UTF8Encoding.UTF8.GetBytes(cSaltHeader),_passphraseBytes);return Rfc2898_pbkdf2_hmacsha512.PBKDF2(UTF8Encoding.UTF8.GetBytes(Utilities.NormaliseStringNfkd(MnemonicSentence)), salt);

Changing the wordlist in the future has ZERO effect on derived seed, whatever mnemonic you provide will always generate the same seed, BIP39 is not mapping the words back to numbers etc to derive seed.
Version is something that can be dealt with after the fact, hopefully standardised (curious why didn't you work with the BIP39 to insert version instead of do something different to BIP39?)
So most of what you are suggesting as problems are not.
As for the common words between languages, I have discussed this with the provider of the Chinese wordlists as they shared some words between simplified and traditional, 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, remembering you get minimum 12 goes at doing that :)
Also then I asked myself, do we really care about detecting the language? Probably not because we don't need to use the wordlist ever again after creation, we literally accept the mnemonic, normalise it then hash it into a seed. From what I'm reading, Electrum 2.0 really should have BIP39, it would take almost no effort to put it in and I think you should do 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, and sorry to answer a bit late; it has been a busy couple
of weeks.

You are correct, a BIP39 seed phrase will not work in Electrum, and vice
versa. It is indeed unfortunate. However, I believe BIP39 should not be
followed, because it reproduces two mistakes I did when I designed the
older Electrum seed system. Let me explain.

The first problem I have with BIP39 is that the seed phrase does not
include a version number.

Wallet development is still in an exploratory phase, and we should
expect even more innovation in this domain. In this context, it is
unwise to make decisions that prevent future innovation.

However, when we give a seed phrase to users, we have a moral obligation
to keep supporting this seed phrase in future versions. We cannot simply
announce to Electrum users that their old seed phrase is not supported
anymore, because we created a new version of the software that uses a
different derivation. This could lead to financial losses for users who
are unaware of these technicalities. Well, at least, that is how I feel
about it.

BIP39 and Electrum v2 have a very different ways of handling future
innovation. Electrum v2 seed phrases include an explicit version number,
that indicates how the wallet addresses should be derived. In contrast,
BIP39 seed phrases do not include a version number at all. BIP39 is
meant to be combined with BIP43, which stipulates that the wallet
structure should depend on the BIP32 derivation path used for the wallet
(although BIP43 is not followed by all BIP39 compatible wallets). Thus,
innovation in BIP43 is allowed only within the framework of BIP32. In
addition, 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.

The second problem I see with BIP39 is that it requires a fixed
wordlist. Of course, this forbids innovation in the wordlist itself, but
that's not the main problem. When you write a new standard, it is
important to keep this standard minimal, given the goal you want to
achieve. I believe BIP39 could (and should) have been written without
including the wordlist in the standard.

There are two ways to derive a master key from a mnemonic phrase:
 1. A bidirectional mapping between words and numbers, 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.

Electrum v1 uses (1). Electrum v2 uses (2).

Early versions of BIP39 used (1), and later they switched to (2).
However, BIP39 uses (2) only in order to derive the wallet keys, not for
its checksum. The BIP39 checksum uses (1), and it does requires a fixed
wordlist. This is just plainly inconsistent. As a result, you have
neither wordlist flexibility, nor Shamir secret sharing.

Having a fixed wordlist is very unfortunate. First, it means that BIP39
will probably never leave the 'draft' stage, until all languages of the
world have been added. Second, once you add a wordlist for a new
language, you cannot change it anymore, because it will break existing
seed phrases; therefore you have to be extremely careful in the way you
design these wordlists. Third, languages often have words in common.
When you add a new language to the list, you should not use words
already used by existing wordlists, in order to ensure that the language
can be detected. It leads to a first come first served situation, that
might not be sustainable in the future.

In order to support the old Electrum v1 seeds, all future versions of
Electrum will have to include the old wordlist. In addition, when
generating new seed phrases, Electrum now has to avoid collisions with
old seed phrases, because the old ones did not have a version number.
This is painful enough, I will not repeat the same errors twice.

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, 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, and no
wordlist is required."


Thomas


Le 02/03/2015 16:37, Mike Hearn a écrit :
> Congrats Thomas! Glad to see Electrum 2 finally launch.
> 
> 
>> * New seed derivation method (not compatible with BIP39).
> 
> 
> Does this mean a "12 words" wallet created by Electrum won't work if
> imported into some other wallet that supports BIP39? Vice versa? This seems
> unfortunate. I guess if seeds are being represented with 12 words
> consistently, people will expect them to work everywhere.
> 

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
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 the list, visit the Bitcoin-development Archives. |
|  |
| View on lists.sourceforge.net | Preview by Yahoo |
|  |
|   |

  

 
   

[-- Attachment #2: Type: text/html, Size: 31318 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Gregory Maxwell]

On Wed, Mar 11, 2015 at 11:50 PM, devrandom <c1.sf-bitcoin@niftybox.net> wrote:
> 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.

The fact remains that there are several apparently unresolvable
well-principled perspectives on this subject.

(And I can speak to this personally: There are several BIPs in this
space that I'd rather not see in product with my name on it.)

Unless two wallets have exactly the same feature set, cross importing
keys is going to confuse or break something. Even if you're trying to
be fairly generic the testing overhead for all possible strategies and
structures is large. Expecting compatibility here would be like
expecting two large commercial accounting packages to support the same
internal file formats. Compatibility is only straight forward when the
feature set is as limited as possible.

The space for weird behavior to harm users is pretty large... e.g. you
could load a key into two wallets, such that one can see all the funds
by the other, but not vice versa and and up losing funds by
incorrectly assuming you had no coins; or inadvertently rip of your
business partners by accounting for things incorrectly.

Even ignoring compatibility, most demanded use cases here are ones
that create concurrent read/write use of single wallet without some
coordinating service is inherently somewhat broken because you can
double spend yourself, and end up with stalled and stuck transactions
and causing people to think you tried ripping them off.

I certainly recognize the desirable aspects of just being able to load
a common wallet, and that inexperienced users expect it to just work.
But I don't think that expectation is currently very realistic except
within limited domains. It may be more realistic in the future when
the role of wallets is better established. I don't see any _harm_ in
trying to standardize what can be, I just don't expect to see a lot of
success.

Ultimately, the most fundamental compatibility is guaranteed:  you can
always send your funds to another wallet. This always works and
guarantees that you are never locked in to a single wallet. It is well
tested and cannot drive any software in to weird or confused states.

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

>
> I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig.


Sure. But in practice people will want to have a pool of spending money
that they can spend when they are out and about, and also with one click
from their web browser on their primary computer, and maybe also on their
games console, etc etc.

I don't think we can realistically tell people to *always* use clever
multi-device wallets - there will always be a desire to have a convenient
hot wallet that's synchronised between different devices.

[-- Attachment #2: Type: text/html, Size: 823 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[devrandom]

I'd like to offer that the best practice for the shared wallet use case
should be multi-device multi-sig.  The mobile has a key, the desktop has
a key and a third-party security oracle has a third key.  The oracle
would have different security thresholds for countersigning the mobile.

This way you can have the same overall wallet on all devices, but
different security profiles on different keys.

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.

On 2015-03-11 04:22 PM, Mike Hearn wrote:
> Users will want to have wallets shared between devices, it's as simple
> as that, especially for mobile/desktop wallets. Trying to stop them from
> doing that by making things gratuitously incompatible isn't the right
> approach:  they'll just find workarounds or wallet apps will learn how
> to import seeds from other apps. Better to just explain the risks and
> help people mitigate them.
> 
> On Wed, Mar 11, 2015 at 3:57 PM, Aaron Voisine <voisine@gmail.com
> <mailto:voisine@gmail.com>> wrote:
> 
>     I'm not convinced that wallet seed interoperability is such a great
>     thing. There is a wide variability in the quality and security level
>     of wallet implementations and platforms. Each new device and wallet
>     software a user types their seed into increases their attack surface
>     and exposure to flaws. Their security level is reduced to the lowest
>     common denominator. I see the need for a "fire exit", certainly, but
>     we must also remember that fire exits are potential entrances for
>     intruders.
> 
>     Aaron Voisine
>     co-founder and CEO
>     breadwallet.com <http://breadwallet.com>
> 
>     On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell
>     <gmaxwell@gmail.com <mailto:gmaxwell@gmail.com>> wrote:
> 
>         On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
>         <ricardojdfilipe@gmail.com <mailto:ricardojdfilipe@gmail.com>>
>         wrote:
>         > i guess you look at the glass half full :)
>         > even though what you say is true, we should aim for wallets not to
>         > require those instructions, by standardizing these things in BIPs.
>         > let's hope bitcoin doesn't fail in standards as our industries have in
>         > the past...
> 
>         There are genuine principled disagreements on how some things should
>         be done. There are genuine differences in functionality.
> 
>         We cannot expect and should not expect complete compatibility.
>         If you
>         must have complete compatibility: use the same software (or
>         maybe not
>         even then, considering how poor the forward compatibility of some
>         things has been..).
> 
>         What we can hope to do, and I think the best we can hope to do,
>         is to
>         minimize the amount of gratuitous incompatibility and reduce the
>         amount of outright flawed constructions (so if there are choices
>         which
>         must be made, they're at least choices among relatively good
>         options).
> 
>         ------------------------------------------------------------------------------
>         Dive into the World of Parallel Programming The Go Parallel
>         Website, sponsored
>         by Intel and developed in partnership with Slashdot Media, is
>         your hub for all
>         things parallel software development, from weekly thought
>         leadership blogs to
>         news, videos, case studies, tutorials and more. Take a look and
>         join the
>         conversation now. http://goparallel.sourceforge.net/
>         _______________________________________________
>         Bitcoin-development mailing list
>         Bitcoin-development@lists.sourceforge.net
>         <mailto:Bitcoin-development@lists.sourceforge.net>
>         https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
>     ------------------------------------------------------------------------------
>     Dive into the World of Parallel Programming The Go Parallel Website,
>     sponsored
>     by Intel and developed in partnership with Slashdot Media, is your
>     hub for all
>     things parallel software development, from weekly thought leadership
>     blogs to
>     news, videos, case studies, tutorials and more. Take a look and join the
>     conversation now. http://goparallel.sourceforge.net/
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

-- 
devrandom / Miron

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3488 bytes --]

Users will want to have wallets shared between devices, it's as simple as
that, especially for mobile/desktop wallets. Trying to stop them from doing
that by making things gratuitously incompatible isn't the right approach:
 they'll just find workarounds or wallet apps will learn how to import
seeds from other apps. Better to just explain the risks and help people
mitigate them.

On Wed, Mar 11, 2015 at 3:57 PM, Aaron Voisine <voisine@gmail.com> wrote:

> I'm not convinced that wallet seed interoperability is such a great thing.
> There is a wide variability in the quality and security level of wallet
> implementations and platforms. Each new device and wallet software a user
> types their seed into increases their attack surface and exposure to flaws.
> Their security level is reduced to the lowest common denominator. I see the
> need for a "fire exit", certainly, but we must also remember that fire
> exits are potential entrances for intruders.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell <gmaxwell@gmail.com>
> wrote:
>
>> On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
>> <ricardojdfilipe@gmail.com> wrote:
>> > i guess you look at the glass half full :)
>> > even though what you say is true, we should aim for wallets not to
>> > require those instructions, by standardizing these things in BIPs.
>> > let's hope bitcoin doesn't fail in standards as our industries have in
>> > the past...
>>
>> There are genuine principled disagreements on how some things should
>> be done. There are genuine differences in functionality.
>>
>> We cannot expect and should not expect complete compatibility. If you
>> must have complete compatibility: use the same software (or maybe not
>> even then, considering how poor the forward compatibility of some
>> things has been..).
>>
>> What we can hope to do, and I think the best we can hope to do, is to
>> minimize the amount of gratuitous incompatibility and reduce the
>> amount of outright flawed constructions (so if there are choices which
>> must be made, they're at least choices among relatively good options).
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4983 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Aaron Voisine]

[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

I'm not convinced that wallet seed interoperability is such a great thing.
There is a wide variability in the quality and security level of wallet
implementations and platforms. Each new device and wallet software a user
types their seed into increases their attack surface and exposure to flaws.
Their security level is reduced to the lowest common denominator. I see the
need for a "fire exit", certainly, but we must also remember that fire
exits are potential entrances for intruders.

Aaron Voisine
co-founder and CEO
breadwallet.com

On Wed, Mar 11, 2015 at 12:46 PM, Gregory Maxwell <gmaxwell@gmail.com>
wrote:

> On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
> <ricardojdfilipe@gmail.com> wrote:
> > i guess you look at the glass half full :)
> > even though what you say is true, we should aim for wallets not to
> > require those instructions, by standardizing these things in BIPs.
> > let's hope bitcoin doesn't fail in standards as our industries have in
> > the past...
>
> There are genuine principled disagreements on how some things should
> be done. There are genuine differences in functionality.
>
> We cannot expect and should not expect complete compatibility. If you
> must have complete compatibility: use the same software (or maybe not
> even then, considering how poor the forward compatibility of some
> things has been..).
>
> What we can hope to do, and I think the best we can hope to do, is to
> minimize the amount of gratuitous incompatibility and reduce the
> amount of outright flawed constructions (so if there are choices which
> must be made, they're at least choices among relatively good options).
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3249 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Gregory Maxwell]

On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
<ricardojdfilipe@gmail.com> wrote:
> i guess you look at the glass half full :)
> even though what you say is true, we should aim for wallets not to
> require those instructions, by standardizing these things in BIPs.
> let's hope bitcoin doesn't fail in standards as our industries have in
> the past...

There are genuine principled disagreements on how some things should
be done. There are genuine differences in functionality.

We cannot expect and should not expect complete compatibility. If you
must have complete compatibility: use the same software (or maybe not
even then, considering how poor the forward compatibility of some
things has been..).

What we can hope to do, and I think the best we can hope to do, is to
minimize the amount of gratuitous incompatibility and reduce the
amount of outright flawed constructions (so if there are choices which
must be made, they're at least choices among relatively good options).

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Ricardo Filipe]

i guess you look at the glass half full :)
even though what you say is true, we should aim for wallets not to
require those instructions, by standardizing these things in BIPs.
let's hope bitcoin doesn't fail in standards as our industries have in
the past...

2015-03-11 19:04 GMT+00:00 Jim <jim618@fastmail.co.uk>:
> The wallet words system isn't perfect for sure but it does help the user in two main ways:
> 1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening.
> 2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this.
>
> I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are.
>
> It can be a simple help page saying:
> "If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this.
> If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this."
>
> That way users have clear instructions on how to recover their bitcoins.
> Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins.
>
> --
> http://bitcoin-solutions.co.uk
>
> On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote:
>> 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.
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Jim]

The wallet words system isn't perfect for sure but it does help the user in two main ways:
1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening.
2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this.

I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are.

It can be a simple help page saying:
"If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this.
If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this."

That way users have clear instructions on how to recover their bitcoins.
Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins.

-- 
http://bitcoin-solutions.co.uk

On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote:
> 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.
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2085 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

Thanks Thomas, for sharing your experience!

I'd like know why you think it's a problem that BIP43 is tied to BIP32?
I understand we all agreed at least on the BIP32-derivation spec
(excluding the BIP32-hierarchy spec)?

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Thomas Voegtlin]

Thanks Mike, and sorry to answer a bit late; it has been a busy couple
of weeks.

You are correct, a BIP39 seed phrase will not work in Electrum, and vice
versa. It is indeed unfortunate. However, I believe BIP39 should not be
followed, because it reproduces two mistakes I did when I designed the
older Electrum seed system. Let me explain.

The first problem I have with BIP39 is that the seed phrase does not
include a version number.

Wallet development is still in an exploratory phase, and we should
expect even more innovation in this domain. In this context, it is
unwise to make decisions that prevent future innovation.

However, when we give a seed phrase to users, we have a moral obligation
to keep supporting this seed phrase in future versions. We cannot simply
announce to Electrum users that their old seed phrase is not supported
anymore, because we created a new version of the software that uses a
different derivation. This could lead to financial losses for users who
are unaware of these technicalities. Well, at least, that is how I feel
about it.

BIP39 and Electrum v2 have a very different ways of handling future
innovation. Electrum v2 seed phrases include an explicit version number,
that indicates how the wallet addresses should be derived. In contrast,
BIP39 seed phrases do not include a version number at all. BIP39 is
meant to be combined with BIP43, which stipulates that the wallet
structure should depend on the BIP32 derivation path used for the wallet
(although BIP43 is not followed by all BIP39 compatible wallets). Thus,
innovation in BIP43 is allowed only within the framework of BIP32. In
addition, 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.

The second problem I see with BIP39 is that it requires a fixed
wordlist. Of course, this forbids innovation in the wordlist itself, but
that's not the main problem. When you write a new standard, it is
important to keep this standard minimal, given the goal you want to
achieve. I believe BIP39 could (and should) have been written without
including the wordlist in the standard.

There are two ways to derive a master key from a mnemonic phrase:
 1. A bidirectional mapping between words and numbers, 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.

Electrum v1 uses (1). Electrum v2 uses (2).

Early versions of BIP39 used (1), and later they switched to (2).
However, BIP39 uses (2) only in order to derive the wallet keys, not for
its checksum. The BIP39 checksum uses (1), and it does requires a fixed
wordlist. This is just plainly inconsistent. As a result, you have
neither wordlist flexibility, nor Shamir secret sharing.

Having a fixed wordlist is very unfortunate. First, it means that BIP39
will probably never leave the 'draft' stage, until all languages of the
world have been added. Second, once you add a wordlist for a new
language, you cannot change it anymore, because it will break existing
seed phrases; therefore you have to be extremely careful in the way you
design these wordlists. Third, languages often have words in common.
When you add a new language to the list, you should not use words
already used by existing wordlists, in order to ensure that the language
can be detected. It leads to a first come first served situation, that
might not be sustainable in the future.

In order to support the old Electrum v1 seeds, all future versions of
Electrum will have to include the old wordlist. In addition, when
generating new seed phrases, Electrum now has to avoid collisions with
old seed phrases, because the old ones did not have a version number.
This is painful enough, I will not repeat the same errors twice.

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, 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, and no
wordlist is required.


Thomas


Le 02/03/2015 16:37, Mike Hearn a écrit :
> Congrats Thomas! Glad to see Electrum 2 finally launch.
> 
> 
>> * New seed derivation method (not compatible with BIP39).
> 
> 
> Does this mean a "12 words" wallet created by Electrum won't work if
> imported into some other wallet that supports BIP39? Vice versa? This seems
> unfortunate. I guess if seeds are being represented with 12 words
> consistently, people will expect them to work everywhere.
> 

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Jim]

Great to see Electrum 2.0 tagged !

It's been a long road I know.
Congratulations to ThomasV and all the other Electrum contributors.

:-)

Jim

-- 
http://bitcoin-solutions.co.uk

On Mon, Mar 2, 2015, at 03:37 PM, Mike Hearn wrote:
> Congrats Thomas! Glad to see Electrum 2 finally launch.
> 
> 
> > * New seed derivation method (not compatible with BIP39).
> 
> 
> Does this mean a "12 words" wallet created by Electrum won't work if
> imported into some other wallet that supports BIP39? Vice versa? This seems
> unfortunate. I guess if seeds are being represented with 12 words
> consistently, people will expect them to work everywhere.
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

Congrats Thomas! Glad to see Electrum 2 finally launch.


> * New seed derivation method (not compatible with BIP39).


Does this mean a "12 words" wallet created by Electrum won't work if
imported into some other wallet that supports BIP39? Vice versa? This seems
unfortunate. I guess if seeds are being represented with 12 words
consistently, people will expect them to work everywhere.

[-- Attachment #2: Type: text/html, Size: 665 bytes --]

Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Andreas Schildbach]

Congrats on the release! Electrum is a very nice wallet.


On 03/01/2015 04:23 PM, Thomas Voegtlin wrote:
> Dear Bitcoin devs,
> 
> I just tagged version 2.0 of Electrum: 
> https://github.com/spesmilo/electrum/tree/2.0
> 
> The electrum.org website will be updated later today. The release 
> notes are a bit dense, due to the large amount of changes and new 
> features in this release. In the coming weeks we will be adding
> more detailed documentation to the wiki and to the website.
> 
> There has been a very long hiatus in Electrum releases, because it 
> took me a lot of time to decide about the new seed derivation
> method and wallet structure. Now that this part is done, I hope
> that we will resume to a faster release pace.
> 
> I would like to thank all the people who contributed to this
> release, developers, beta testers, but also people from this list
> who provided useful feedback.
> 
> Cheers,
> 
> Thomas
> 
> _____________________________
> 
> RELEASE-NOTES
> 
> # Release 2.0
> 
> * Before you upgrade, make sure you have saved your wallet seed on 
> paper.
> 
> * Documentation is now hosted on a wiki: http://electrum.orain.org
> 
> * New seed derivation method (not compatible with BIP39). The seed 
> phrase includes a version number, that refers to the wallet 
> structure. The version number also serves as a checksum, and it 
> will prevent the import of seeds from incompatible wallets. Old 
> Electrum seeds are still supported.
> 
> * New address derivation (BIP32). Standard wallets are single
> account and use a gap limit of 20.
> 
> * Support for Multisig wallets using parallel BIP32 derivations
> and P2SH addresses ("2 of 2", "2 of 3").
> 
> * Compact serialization format for unsigned or partially signed 
> transactions, that includes the BIP32 master public key and 
> derivation needed to sign inputs. Serialized transactions can be 
> sent to cosigners or to cold storage using QR codes (using Andreas 
> Schildbach's base 43 idea).
> 
> * Support for BIP70 payment requests: - Verification of the chain
> of signatures uses tlslite. - In the GUI, payment requests are
> shown in the 'Invoices' tab.
> 
> * Support for hardware wallets: Trezor (Satoshilabs) and Btchip
> (Ledger).
> 
> * Two-factor authentication service by TrustedCoin. This service
> uses "2 of 3" multisig wallets and Google Authenticator. Note that 
> wallets protected by this service can be deterministically
> restored from seed, without Trustedcoin's server.
> 
> * Cosigner Pool plugin: encrypted communication channel for
> multisig wallets, to send and receive partially signed
> transactions.
> 
> * Audio Modem plugin: send and receive transactions by sound.
> 
> * OpenAlias plugin: send bitcoins to aliases verified using
> DNSSEC.
> 
> * New 'Receive' tab in the GUI: - create and manage payment
> requests, with QR Codes - the former 'Receive' tab was renamed to
> 'Addresses' - the former Point of Sale plugin is replaced by a
> resizeable window that pops up if you click on the QR code
> 
> * The 'Send' tab in the Qt GUI supports transactions with multiple 
> outputs, and raw hexadecimal scripts.
> 
> * The GUI can connect to the Electrum daemon: "electrum -d" will 
> start the daemon if it is not already running, and the GUI will 
> connect to it. The daemon can serve several clients. It times out 
> if no client uses if for more than 5 minutes.
> 
> * The install wizard can be used to import addresses or private 
> keys. A watching-only wallet is created by entering a list of 
> addresses in the wizard dialog.
> 
> * New file format: Wallets files are saved as JSON. Note that new 
> wallet files cannot be read by older versions of Electrum. Old 
> wallet files will be converted to the new format; this operation 
> may take some time, because public keys will be derived for each 
> address of your wallet.
> 
> * The client accepts servers with a CA-signed SSL certificate.
> 
> * ECIES encrypt/decrypt methods, availabe in the GUI and using the
> command line: encrypt <pubkey> <message> decrypt <pubkey>
> <message>
> 
> * The Android GUI has received various updates and it is much more 
> stable. Another script was added to Android, called Authenticator, 
> that works completely offline: it reads an unsigned transaction 
> shown as QR code, signs it and shows the result as a QR code.
> 
> ------------------------------------------------------------------------------
>
> 
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly
> thought leadership blogs to news, videos, case studies, tutorials
> and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net/
> 

[Bitcoin-development] Electrum 2.0 has been tagged

[Thomas Voegtlin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Bitcoin devs,

I just tagged version 2.0 of Electrum:
https://github.com/spesmilo/electrum/tree/2.0

The electrum.org website will be updated later today. The release
notes are a bit dense, due to the large amount of changes and new
features in this release. In the coming weeks we will be adding more
detailed documentation to the wiki and to the website.

There has been a very long hiatus in Electrum releases, because it
took me a lot of time to decide about the new seed derivation method
and wallet structure. Now that this part is done, I hope that we will
resume to a faster release pace.

I would like to thank all the people who contributed to this release,
developers, beta testers, but also people from this list who provided
useful feedback.

Cheers,

Thomas

_____________________________

RELEASE-NOTES

# Release 2.0

* Before you upgrade, make sure you have saved your wallet seed on
paper.

* Documentation is now hosted on a wiki: http://electrum.orain.org

* New seed derivation method (not compatible with BIP39). The seed
phrase includes a version number, that refers to the wallet
structure. The version number also serves as a checksum, and it
will prevent the import of seeds from incompatible wallets. Old
Electrum seeds are still supported.

* New address derivation (BIP32). Standard wallets are single account
and use a gap limit of 20.

* Support for Multisig wallets using parallel BIP32 derivations and
P2SH addresses ("2 of 2", "2 of 3").

* Compact serialization format for unsigned or partially signed
transactions, that includes the BIP32 master public key and
derivation needed to sign inputs. Serialized transactions can be
sent to cosigners or to cold storage using QR codes (using Andreas
Schildbach's base 43 idea).

* Support for BIP70 payment requests:
- - Verification of the chain of signatures uses tlslite.
- - In the GUI, payment requests are shown in the 'Invoices' tab.

* Support for hardware wallets: Trezor (Satoshilabs) and Btchip (Ledger).

* Two-factor authentication service by TrustedCoin. This service uses
"2 of 3" multisig wallets and Google Authenticator. Note that
wallets protected by this service can be deterministically restored
from seed, without Trustedcoin's server.

* Cosigner Pool plugin: encrypted communication channel for multisig
wallets, to send and receive partially signed transactions.

* Audio Modem plugin: send and receive transactions by sound.

* OpenAlias plugin: send bitcoins to aliases verified using DNSSEC.

* New 'Receive' tab in the GUI:
- - create and manage payment requests, with QR Codes
- - the former 'Receive' tab was renamed to 'Addresses'
- - the former Point of Sale plugin is replaced by a resizeable
window that pops up if you click on the QR code

* The 'Send' tab in the Qt GUI supports transactions with multiple
outputs, and raw hexadecimal scripts.

* The GUI can connect to the Electrum daemon: "electrum -d" will
start the daemon if it is not already running, and the GUI will
connect to it. The daemon can serve several clients. It times out
if no client uses if for more than 5 minutes.

* The install wizard can be used to import addresses or private
keys. A watching-only wallet is created by entering a list of
addresses in the wizard dialog.

* New file format: Wallets files are saved as JSON. Note that new
wallet files cannot be read by older versions of Electrum. Old
wallet files will be converted to the new format; this operation
may take some time, because public keys will be derived for each
address of your wallet.

* The client accepts servers with a CA-signed SSL certificate.

* ECIES encrypt/decrypt methods, availabe in the GUI and using
the command line:
encrypt <pubkey> <message>
decrypt <pubkey> <message>

* The Android GUI has received various updates and it is much more
stable. Another script was added to Android, called Authenticator,
that works completely offline: it reads an unsigned transaction
shown as QR code, signs it and shows the result as a QR code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU8y7fAAoJECvVgkt/lHDm78oP/2uIqCyOwLsAJGkAI3CPFxtw
WssFJlnCnFiA4tPv5pd7HdOgxQkTaPbUHftexfdd/lpfmFvxZVoHcA/32IIKFH63
BU2bnEyYOaW1A4XfNDQH6VG7eT2er1HOlHCtIgzRl0KJNmVggU6DnXnHkUs1PVvg
pyEIR7Xv3GiK7rcS4qCS/9COroqQGFOXJAiLnOaQP5KszT1bMUdoL7mBPTfavnla
LM+2MgKJOWv+JpHQCDp3XwAXX62LLsS2BjdK1Jt6OpGA6IuVQGBSaTIn5K81S+Yh
M6RDKbP3kObYQ+bzLvtWrzgUD3sdht/V8L5ZPS3+Jibvmhae2zRrm/YpJZ77Yjd4
7QliCFGH0+Gwle72yOempFGWULwq7p6yo4dVZXpj1G3XmbZXuvFg4jYeC/usCx+T
kQgMBPWME2m80fCzhJew1pRChSs/lzVreB0Lh6Tm/5Pibmy721J4oUr6oLkaR9Uy
NMrYqnSy0+tCEOXHrpCYhqogyzzdjOlv0gWKqB2uSkO5TkEHv2eyHeiZttAn11qO
sb85q/k0kYQBZZEvKJ9022eyKHjejDhQjKsCVIHhb81BJ1QYnZFIxBiKkVMxf0u5
sT2TTi18eOrYCUGD2WJ+ALyI1zN1sHO0/sn5+XzlC0jg+1KUXoo0j8NYnzmHb0Yx
5lbdlcaw0Uo7iWkFdMYT
=IGGP
-----END PGP SIGNATURE-----