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] BIP32 Index Randomisation
This seems overly complicated to me, unless I'm missing something. Instead, I think you should just give the server the master pubkey P only without the chaincode. Then when you transact you generate the address in whatever manner you like and tell the server the scalar value iL which the user computes as iL = HMAC-SHA512(Key = cpar, Data = serP(Kpar) || ser32(i))[first 32 byes], (per BIP 32). and the server computes P + iL*G and checks agreement with the address. It would be inaccurate to call this private, as the server still learns this particular relation. (and really users should _not_ be using the same chaincode with different parties... as it exacerbates the private key leak risk), but its certainly more private than giving people the chain code. The approach I suggest is also not gratuitously incompatible with hardened derivation, which is what parties should be doing when they don't actually need a third party to generate future addresses for them without their cooperation (as appears to be the case here). On Fri, Mar 13, 2015 at 3:48 AM, Matias Alejo Garcia mat...@bitpay.com wrote: Hello everyone, We are working on bitcore-wallet-server (BWS), a HD multisig wallet 'facilitator'. We have a couple of questions regarding BIP32 path usage, and we would love to have feedback from you before moving forward. Currently the BWS instances hold the set of extended public keys of the wallet's peers to be able to derive addresses. Since this is a problem from the privacy point of view, we thought using pseudo-random BIP32 paths, with a seed only known be the peers, so the server will be able to verify that addresses submitted by peers belong to the wallet, but will not be able to derive future wallet addresses. The workflow would be something like: ``` PeergetCurrentIndex Server [index] Peer: pathSeed = PRNG(seed, index); Peer createAddress(index, pathSeed); Server: derives the address and add it to the wallet. Server new address Peer: Verifies the address and inform it the user. ``` This way, accessing server data won't reveal future wallet addresses. The seed (only known by the peers) could be derived from hashes of their xprivs, so wallet funds can still be recover with: 1) The complete set of xprivs 2) The quorum of xprivs + the complete set of xpubs + the address seed. Thanks a lot in advance for any comment on this schema. matías -- BitPay.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 -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP32 Index Randomisation
Hello everyone, We are working on bitcore-wallet-server (BWS), a HD multisig wallet 'facilitator'. We have a couple of questions regarding BIP32 path usage, and we would love to have feedback from you before moving forward. Currently the BWS instances hold the set of extended public keys of the wallet's peers to be able to derive addresses. Since this is a problem from the privacy point of view, we thought using pseudo-random BIP32 paths, with a seed only known be the peers, so the server will be able to verify that addresses submitted by peers belong to the wallet, but will not be able to derive future wallet addresses. The workflow would be something like: ``` PeergetCurrentIndex Server [index] Peer: pathSeed = PRNG(seed, index); Peer createAddress(index, pathSeed); Server: derives the address and add it to the wallet. Server new address Peer: Verifies the address and inform it the user. ``` This way, accessing server data won't reveal future wallet addresses. The seed (only known by the peers) could be derived from hashes of their xprivs, so wallet funds can still be recover with: 1) The complete set of xprivs 2) The quorum of xprivs + the complete set of xpubs + the address seed. Thanks a lot in advance for any comment on this schema. matías -- BitPay.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
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 that
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
[Bitcoin-development] Broken Threading
Yes apologies for the broken threading, it was the result of me auto forwarding between mail providers etc. To fix this issue I have created this new dedicated outlook account (thyshiz...@outlook.com) that I shall use for all my subscriptions here and I am unsubscribing the yahoo address. This should solve this issue going forward :) -- 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] Testnet3
Strangely enough, it has started to work properly and I didn't even touch my code just had it sitting there in the loop/ping circuit it was performing and capturing with wireshark.that is quite odd! Hi, so I have my .NET node communicating on the P2P network just fine, so I figured as I'll now start looking at making and validating transactions etc I should probably migrate to test net. Now I see that we are up to the third generation testnet testnet3, and I am sending my messages now using packet magic 0x0b110907 and I'm using Wireshark and I can confirm that my messages are going out with that packet magic. Now what is interesting is that when I try connect to a test node obtained from DNS seed testnet-seed.bitcoin.petertodd.org, I send it a version message with the testnet3 packet magic, yet I get no verack or version in response In fact, the only thing I get back is a ping and then the connection is severed by the remote node. What is going on? Also, it works fine with the mainnet packet magic value of 0x0f9beb4d9 and I am debuging my code and ensuring it is looking for the testnet3 packet magic, but I am not getting a response from the node?-- 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
