Re: [Bitcoin-development] Electrum 2.0 has been tagged
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 -- 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
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
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 -- 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
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. -- 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, your message threading is broken. Can you make sure your mail program uses the correct message ID when replying? -- 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
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 vois...@gmail.com mailto:vois...@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 gmaxw...@gmail.com mailto:gmaxw...@gmail.com wrote: On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe ricardojdfil...@gmail.com mailto:ricardojdfil...@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
Re: [Bitcoin-development] Electrum 2.0 has been tagged
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. -- 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
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
Re: [Bitcoin-development] Electrum 2.0 has been tagged
Den 12 mar 2015 19:52 skrev Andreas Schildbach andr...@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). -- 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
Den 12 mar 2015 17:48 skrev Mike Hearn m...@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. -- 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
On 03/12/2015 07:27 PM, Natanael wrote: Den 12 mar 2015 17:48 skrev Mike Hearn m...@plan99.net mailto:m...@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. -- 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
On Wed, Mar 11, 2015 at 11:09 PM, Gregory Maxwell gmaxw...@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 -- 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
@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: nei...@thecodefactory.org To: thashizn...@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 +, 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 +, 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
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 +, 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 +, 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
Re: [Bitcoin-development] Electrum 2.0 has been tagged
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
Re: [Bitcoin-development] Electrum 2.0 has been tagged
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
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
On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe ricardojdfil...@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
Re: [Bitcoin-development] Electrum 2.0 has been tagged
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 jim...@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 -- 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
Re: [Bitcoin-development] Electrum 2.0 has been tagged
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 gmaxw...@gmail.com wrote: On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe ricardojdfil...@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
Re: [Bitcoin-development] Electrum 2.0 has been tagged
On Wed, Mar 11, 2015 at 11:50 PM, devrandom c1.sf-bitc...@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. -- 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
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. -- 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
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: H 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-- 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
On Thu, Mar 12, 2015 at 2:41 AM, devrandom c1.sf-bitc...@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. -- 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
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 vois...@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 gmaxw...@gmail.com wrote: On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe ricardojdfil...@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 -- 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
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
Re: [Bitcoin-development] Electrum 2.0 has been tagged
On 2015-03-11 05:11 PM, Gregory Maxwell wrote: On Wed, Mar 11, 2015 at 11:50 PM, devrandom c1.sf-bitc...@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 -- 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
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn m...@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 -- 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
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 m...@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-- 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
On Wed, Mar 11, 2015 at 10:12 PM, Thy Shizzle thashizn...@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 -- 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
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 +, 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
Re: [Bitcoin-development] Electrum 2.0 has been tagged
On Thu, Mar 12, 2015 at 02:16:38AM +, 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
Re: [Bitcoin-development] Electrum 2.0 has been tagged
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
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 -- 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
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/ -- 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
