Topic: Mycelium 2.0 HD - Welcome to the future - page 2. (Read 16656 times)
If it's an HD account, the receiving address will change automatically once you receive coins to it.
I have Mycelium Wallet 2.1.0
I can't figure out how to not reuse the receiving address... The same one always shows up...
I can't figure out how to not reuse the receiving address... The same one always shows up...
The transactions tab used to show the to/from address(es) and, more importantly, any custom labels. What happened or where do I need to look now?
For example, I get dividends from a particular BTC address, so it was always handy to look at the list of transactions and see "xyz div" under the relevant payments.
Is there any easy way of scanning transactions (i.e. where you see the custom labels created for specific addresses)? For example, I get dividends from a particular BTC address, so it was always handy to look at the list of transactions and see "xyz div" under the relevant payments.
This was added so wallets could generate the seed even if they don't have or can't hold every word list, like trezor. I agree that it's less than ideal.
It would have worked about as well to encode the 128 bits of needed entropy in a string of 22 base64 or base58 characters. There's your backup. Easy to decode and get the entropy binary back, which can act as the seed for the wallet.
And there's nothing to stop any wallet designer, who so wishes, from encoding the binary in a word list per bip39. For interoperability among different wallets with different dictionaries, use the 22 character string... any wallet, even one as limited as trezor, is sure to have enough memory and processing power to decode its own word list!
Bip39 was kludged into the wallet architecture between the entropy and the master key -- where it isn't needed, and can only cause problems. Will we be stuck with this contraption in every wallet from now on?
Just in case I'm not getting through:
Whoever came up that whole mess described in the section of the mediawiki titled "From mnemonic to seed" was wasting everybody's time. The idea that you have to go to such lengths to avoid storing a library of bip39 dictionaries is an illusion. Merely store your own dictionary; when you need the binary, decode the wordlist. Simple as that!
HD wallet designers have followed bip39 without giving it a moment's thought or considering maybe the bip's badly designed. But it is the worst kind of bad design; it's a strategic error not a coding blunder, so people operating on autopilot don't see it. Then it gets coded into wallets, and you're stuck with it forever. And we'll have all kinds of headaches making HD wallets compatible.
I'm staying with legacy accounts, for now.
All this confusion about incompatible wallets calls for a look at bip 39. The process starts with finding 128 bits of entropy ("ENT") and builds from there. The bip sets out some fairly simple steps for generating a wordlist from ENT. So far so good.
Then instead of creating the wallet seed from ENT, the simplest and best course, it goes like this
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).
These steps are unnecessary, create extra work, and may lead to complications.
Encrypting your wordlist is all for the best, but please don't interpose that encryption between the originating entropy pool and the master seed/private key of the HD wallet. Basically you are encrypting entropy. It doesn't work like that. It works like this:
The entropy is the seed.
Use it: entropy --> seed
ENT --> sha256 hash --> master privkey
Then instead of creating the wallet seed from ENT, the simplest and best course, it goes like this
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).
These steps are unnecessary, create extra work, and may lead to complications.
Encrypting your wordlist is all for the best, but please don't interpose that encryption between the originating entropy pool and the master seed/private key of the HD wallet. Basically you are encrypting entropy. It doesn't work like that. It works like this:
The entropy is the seed.
Use it: entropy --> seed
ENT --> sha256 hash --> master privkey
This was added so wallets could generate the seed even if they don't have or can't hold every word list, like trezor. I agree that it's less than ideal.
All this confusion about incompatible wallets calls for a look at bip 39. The process starts with finding 128 bits of entropy ("ENT") and builds from there. The bip sets out some fairly simple steps for generating a wordlist from ENT. So far so good.
Then instead of creating the wallet seed from ENT, the simplest and best course, it goes like this
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).
These steps are unnecessary, create extra work, and may lead to complications.
Encrypting your wordlist is all for the best, but please don't interpose that encryption between the originating entropy pool and the master seed/private key of the HD wallet. Basically you are encrypting entropy. It doesn't work like that. It works like this:
The entropy is the seed.
Use it: entropy --> seed
ENT --> sha256 hash --> master privkey
Then instead of creating the wallet seed from ENT, the simplest and best course, it goes like this
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).
These steps are unnecessary, create extra work, and may lead to complications.
Encrypting your wordlist is all for the best, but please don't interpose that encryption between the originating entropy pool and the master seed/private key of the HD wallet. Basically you are encrypting entropy. It doesn't work like that. It works like this:
The entropy is the seed.
Use it: entropy --> seed
ENT --> sha256 hash --> master privkey
Does the HD wallet use compressed keys? As in, the private keys start with the letters L or K?
Breadwallet doesn't seem to expose the private keys, only the twelve word seed generator. My installation's current (public) address starts with 16E. This is the second address it generated. The first (which received some funds) started with 1PL.
The first address showing on Mycelium (using the same 12 word seed generator) starts with 1EJ.
breadwallet isn't using the same BIP32 tree structure as mycelium, so the backups are not compatible. I have heard that hive is using the same structure as breadwallet, though I don't recommend typing your backup phrase into multiple wallets and devices. Security of your wallet seed is absolutely critical. Every wallet and device you use it with increases the chances that one of them has a security hole or is infected with malware. breadwallet is built to a very high standard of security. Your seed is only stored in the iPhone secure enclave which is hardware encrypted and even hardened against EM side-channel attacks. Other wallets decrypt your keys in the browser with javascript, and other platforms are far more susceptible to malware.
Ah.. Thanks for the clarification.
As for your other comments, I agree, but I absolutely need to know I CAN go to another platform if I have to. Preferably many platforms. With paper cold store I can, but with 12 word seeds I still can't.
There is nothing wrong with trying to restore backups on another platform when the wallet has trivial amounts in it. That way I know I can do it if I have to some day. For example, what if Breadwallet is pulled from the AppStore?
Fair enough. As I mentioned I've been told hive is using the same structure, but I haven't tried it personally. Apple hasn't ever removed apps from individuals phones even if the app is pulled from the app store, but it's always good to be sure. If anything like that ever happened I would quickly release a tool to get your funds out, and it's open source as well and using the default BIP32 tree described in the BIP32 examples, so any developer could do this.
I also plan to build an android version of breadwallet using the trusted platform module to attain a similar level of security as the iOS version.
Does the HD wallet use compressed keys? As in, the private keys start with the letters L or K?
Breadwallet doesn't seem to expose the private keys, only the twelve word seed generator. My installation's current (public) address starts with 16E. This is the second address it generated. The first (which received some funds) started with 1PL.
The first address showing on Mycelium (using the same 12 word seed generator) starts with 1EJ.
breadwallet isn't using the same BIP32 tree structure as mycelium, so the backups are not compatible. I have heard that hive is using the same structure as breadwallet, though I don't recommend typing your backup phrase into multiple wallets and devices. Security of your wallet seed is absolutely critical. Every wallet and device you use it with increases the chances that one of them has a security hole or is infected with malware. breadwallet is built to a very high standard of security. Your seed is only stored in the iPhone secure enclave which is hardware encrypted and even hardened against EM side-channel attacks. Other wallets decrypt your keys in the browser with javascript, and other platforms are far more susceptible to malware.
Ah.. Thanks for the clarification.
As for your other comments, I agree, but I absolutely need to know I CAN go to another platform if I have to. Preferably many platforms. With paper cold store I can, but with 12 word seeds I still can't.
There is nothing wrong with trying to restore backups on another platform when the wallet has trivial amounts in it. That way I know I can do it if I have to some day. For example, what if Breadwallet is pulled from the AppStore?
Does the HD wallet use compressed keys? As in, the private keys start with the letters L or K?
Breadwallet doesn't seem to expose the private keys, only the twelve word seed generator. My installation's current (public) address starts with 16E. This is the second address it generated. The first (which received some funds) started with 1PL.
The first address showing on Mycelium (using the same 12 word seed generator) starts with 1EJ.
breadwallet isn't using the same BIP32 tree structure as mycelium, so the backups are not compatible. I have heard that hive is using the same structure as breadwallet, though I don't recommend typing your backup phrase into multiple wallets and devices. Security of your wallet seed is absolutely critical. Every wallet and device you use it with increases the chances that one of them has a security hole or is infected with malware. breadwallet is built to a very high standard of security. Your seed is only stored in the iPhone secure enclave which is hardware encrypted and even hardened against EM side-channel attacks. Other wallets decrypt your keys in the browser with javascript, and other platforms are far more susceptible to malware.
Does the HD wallet use compressed keys? As in, the private keys start with the letters L or K?
Breadwallet doesn't seem to expose the private keys, only the twelve word seed generator. My installation's current (public) address starts with 16E. This is the second address it generated. The first (which received some funds) started with 1PL.
The first address showing on Mycelium (using the same 12 word seed generator) starts with 1EJ.
The transactions tab used to show the to/from address(es) and, more importantly, any custom labels. What happened or where do I need to look now?
For example, I get dividends from a particular BTC address, so it was always handy to look at the list of transactions and see "xyz div" under the relevant payments.
For example, I get dividends from a particular BTC address, so it was always handy to look at the list of transactions and see "xyz div" under the relevant payments.
Does the HD wallet use compressed keys? As in, the private keys start with the letters L or K?
* Added support for BIP32/BIP44 compliant HD accounts based on a single master seed
* A much simpler backup that uses a word list to backup all your HD accounts (BIP39)
* A much simpler backup that uses a word list to backup all your HD accounts (BIP39)
Has anyone tried taking the 12 word backup between Breadwallet(for iPhone) and Mycelium?
I can't seem to get it to work. I have a BIP32/BIP44 wallet on Breadwallet and I have the 12 word BIP39 backup. I downloaded a fresh Mycelium and asked it to restore from those 12 words. It shows as a zero balance wallet with a different receive address than the first one that was shown by Breadwallet.
Any ideas? compressed vs uncompressed? Anything else?
Lovin Mycelium 2.0
[...]
LocalTrader, which is like LocalBitcoin, but built right into your wallet, and much more secure and anonymous.
LocalTrader, which is like LocalBitcoin, but built right into your wallet, and much more secure and anonymous.
Any thoughts on expanding LocalTrader, so it could offer functionality similar to i.e. bitpay? https://bitcointalksearch.org/topic/m.9177218
BIP38 encrypted private keys supported as well
QR scan only, no text import (nudge, nudge. You have no idea how this would make my life easier). 
Hmm looks great. I'm so used to android bitcoin wallet by andreas but this looks equally good as well. Nicely done
This has cold storage spending that let's you spend directly from a paper wallet (BIP38 encrypted private keys supported as well), and LocalTrader, which is like LocalBitcoin, but built right into your wallet, and much more secure and anonymous.
Hmm looks great. I'm so used to android bitcoin wallet by andreas but this looks equally good as well. Nicely done
Still Android only? (Fantastic job tbw.)
There will eventually be an iOS version.
Planning is in progress.
No details available yet
Still Android only? (Fantastic job tbw.)
Jump to: