Try Cold Storage from the three-dot menu and choose Masterseed.  It won't import the new wallet, but it should let you check the balance and make a transfer.

This code is for an old style paper (PDF) backup.  If you have it, look for the encrypted key QR code in it, scan it with Mycelium, and it will ask you for this code.  This code is useless without the printout or PDF.

If you can’t find the printout, chances are you may still have the PDF somewhere, as it was generated at the same time as this code.  The file name pattern is mycelium-backup-*.pdf, where * stands for the date and time.  It may even be somewhere on an SD card or some data partition which is not cleaned by a factory reset.

That’s how transaction IDs appear in the Bitcoin protocol, where they are represented by byte-reversed transaction hashes.

I was curious and did some googling a while ago.  There have been discussions on this topic, but apparently, nobody knows why Satoshi chose it to be this way.

Here’s one possible explanation.  Internally, the SHA-256 algorithm works with 32-bit numbers rather than bytes.  Its specification says that when the hashing itself is done, the resulting numbers are converted to a byte sequence in big-endian byte order, and this byte sequence is the official SHA-256 hash.  Now, the Bitcoin protocol is little-endian.  So Satoshi may have decided to change this last step of SHA-256 to use little endian for consistency with the rest of the protocol.  (The order of words would have to change as well to preserve continuity.)  Also, because the most widely used processor architectures are little endian (x64, x86, ARM), Satoshi’s representation is simply a dump of the internal state of the hashing algorithm on these machines, without the additional byte swapping that would be required by the specification.

Of course; it is part of the Entropy’s github repository here: https://github.com/mycelium-com/entropy/tree/master/doc/checksalt.

The official site (mycelium.com) is undergoing a major reorganisation, and it may take a while before tools like this are accessible again.  Meanwhile, a service such as rawgit.com could be useful:
https://cdn.rawgit.com/mycelium-com/entropy/master/doc/checksalt/sss.html.

I couldn't resist the temptation, so here it is now:
https://mycelium.com/assets/entropy/checksalt/sss.html.

It's not very well tested yet, though.  Also, as far as I know, iOS does not fully support in-browser video/image capture.

Thanks birr for explaining the private key conversion, I wasn't familiar with online tools that could do that (just knew they existed).


Just want to clarify this bit.

In Mycelium Entropy, the 'secret' is the entire WIF-formatted sequence (without the checksum), not just the private key:

• <prefix: 2 hex digits> <key: 64 hex digits> for an uncompressed key, or
• <prefix: 2 hex digits> <key: 64 hex digits> '01' for a compressed key.

A "compressed" private key (actually, a private key which is to be used with a compressed public key) starts with K or L and is the most common type and the default.  An "uncompressed" private key starts with a 5.  Note the extra byte at the end when compressed keys are used.

The prefix is 80 for Bitcoin, EF for Bitcoin testnet, B0 for Litecoin etc.

The algorithm used by PassGuardian uses the first '1' bit for its own purposes and therefore removes it from the result, so the prefix becomes 00 for Bitcoin, 6F for testnet, 30 for Litecoin etc.

While the prefix can easily be discarded, it's important to watch out for the extra 01 byte at the end.  If it is present, and the total length is 68 hex characters, then it's the compressed key marker and should also be discarded; in that case, the key should be converted to WIF with the 'compressed' option set.

Like you say, there are multiple online tools which can do that last step of converting the raw key to a base-58 encoded WIF.  Some take the 64 hex digits of the key and ask you for additional information (coin type and compression).  There might be others, which take the whole sequence including the prefix and optionally the suffix, and convert it to Base58Check; then the coin type and compression do not need to be decoded manually.

---

It would be nice if a tool existed to reassemble keys from Entropy shares.  However, the algorithm is not something Mycelium-specific.  If something happens with the wallet app, the keys can always be recovered using a combination of general purpose tools.

This tool works, but requires share format conversion.  It's not very easy, but doable.

Let's take this 2-of-3 example from the spec:
Like most things Bitcoin, Entropy shares are encoded in base-58, so let's decode the first two to hexadecimal:
Any online base-58 decoding tool can be used, just remember to remove the SSS- prefix.

Divide the first share into constituent parts according to the spec:
The 8th digit (0) is x-1, so this share's number x = 1.
After discarding the first 8 digits (metadata) and last 8 digits (check sum), what's left is the encoded secret.  Prepend it with 80x according to secret.js's format (where x is the share's number):
and paste it into passguardian.com.

Do the same with the second share:

In 'Advanced', choose Hexadecimal secret type, then use Reconstruct.  The reconstructed secret will be
Note that secrets.js discards the most significant '1' bit, turning the leading 8 to 0.  Otherwise the secret is exactly what is expected.  After changing the first 0 back to 8 and converting the result with Base58Check, we get the private key in its usual form.

The spec also has a reference implementation in Python.

I don't see the point of encrypting a wallet.

How strong is your encryption key (pass phrase) going to be?

If it's short enough to be easy to enter every time you want to spend bitcoins (like a PIN), an attacker who's got your encrypted wallet data can brute force it in seconds on a home PC.  The strength of PIN-based protection is in the app, which restricts the frequency and number of PIN entry attempts in order to thwart brute force attacks.  As an encryption key, it is useless.

If your pass phrase is long enough to be secure, do you really want to type it in every time you need it?  You will have it written down on a piece of paper, because a long, random and rarely used secret is easy to forget.  Then someone will request a feature to scan the pass phrase from a QR code.  And then you will realise that something like that already exists in many wallets including Mycelium, and is called cold storage.

Cold storage is simpler and more secure than encryption.

Thanks, this is a known problem and work is underway to rectify it.  (I'm a Mycelium dev, but am not involved with the wallet myself.)

Exactly; it looks remarkably similar to BWallet: https://www.reddit.com/r/Bitcoin/comments/2tvj7y/receiving_a_bwallet_the_trezor_clone/, a Trezor clone based on the Trezor's open source software and schematics.  There was one new “feature” though: a tracking cookie.

Why do you want to test it with WhatsApp if the user claims it sends fine?  It just sounds like a coincidence.

Mycelium is an HD wallet so it can generate different addresses for the same HD account, the aim being to use each address only once for privacy reasons.  It may be hard to tell which addresses belong to which account.

If there are several accounts/wallets, they can be shown together or separately.  If the setting in the app is to show them separately (it's an advanced feature), and the selected account is not the one where the address was generated, the app will not show any incoming bitcoins on the Balance or Transactions tabs.  However, regardless of this setting, all accounts and their balances are listed on the Accounts tab.

Has your transaction been confirmed?

There may be various explanations why your party doesn't see your bitcoins, the least likely of which is a malfunction in the Mycelium wallet.  More information is needed to investigate this; at least, the address you sent the money to, to begin with.  If you don't feel comfortable sharing it here, perhaps consider writing to Mycelium support.

Even if you can import the recovery seed, it doesn't mean you need to.

It is commonly considered more secure to keep the keys in the TREZOR and use Electrum/Mycelium/etc. as an interface to the TREZOR.  This way Electrum acts as a replacement for the myTrezor web interface.
See http://doc.satoshilabs.com/trezor-apps/electrum.html .

Exactly.  The security model of mobile devices is usually much tighter than that of PCs and Macs.

For example, Android apps do not have access to one another's data by default.  That is, unless:

• the device's kernel is specifically compromised to allow that (extremely unlikely),
• the device is rooted (usually impossible without explicit action from the user), or
• an app explicitly permits another app to access its data.

On a computer running a regular Windows/Linux/Mac OS X, however, any application you download and run can access all your other applications' files, including your private keys.

Even though private keys are often encrypted, there is a trade-off between security and usability, and in practice usability often wins here.  I would much rather prefer to prevent a malicious entity from accessing my keys than rely on the strength of my password (and on the absence of keyloggers).

Yes, but there is a nuance.

The main hardware entropy source (SRAM) works only once when you power it up.  If you want to generate a continuous stream, you have to use the built-in TRNG (probably safe, as it's not from Intel) and ADC measurements of a floating input.  There is a new appendix in the user manual about it: https://mycelium.com/assets/entropy/me.html#_appendix_b_how_it_works .

You can power SRAM off in hibernate mode, but it takes about 30 seconds for each sampling of about 6 kbits of entropy.  SRAM discharge is slower in hibernate mode than when the device is unplugged.

Personally, I doubt there is any chance at all that Atmel's built-in hardware RNG is compromised.  And you can still use the one-off salt from SRAM to thwart any hardware attacks on the built-in TRNG module.

I heard the last batch had just arrived at Mycelium office in Vienna for flashing and final assembly.

I heard the first batch was incomplete, and 200 more units are expected from the factory.  Most orders are shipped in chronological order, so yours will most likely come out of that 200-unit batch.

Entropies have arrived at distribution locations and are being prepared for shipment to customers.
Full story here: http://www.reddit.com/r/Bitcoin/comments/2xp6ss/mycelium_entropy_update_for_monday_march_2nd/

I think Android version's xpub is better.

For a BIP-44 wallet, the xpub at m/44'/0'/0' makes a lot more sense than at m/44'/0'/0'/0.  The former can be used to find out the total amount of funds in Account 0, and therefore is usable as a “watch-only” key to monitor an HD account without risking the private keys.  And it can still generate “incoming” addresses in the external chain at 0/1, 0/2, 0/3 etc. relative to the xpub.

m/44'/0'/0'/0 does technically offer a bit more privacy by hiding the internal (change) chain.  Still, whoever has it can see all external incoming transactions into the account and track them on the blockchain.  That's really not that much more private than m/44'/0'/0'.  I suppose xpubs are not really meant to be made public; it's the addresses on the external chain that are.  And they are the same regardless of the xpub they are derived from (as long as correct derivation sub-paths are used).

The site you mentioned (which you call ‘sites’ in plural, even though they are identical) looks to me more like an engineering toolkit than a consumer product.  It calculates everything based on a derivation path.  You can enter one path and read just the xpub, then enter another path and read just the derived addresses.  I guess, the site assumes that the visitors are more likely to be interested in the addresses than in the xpub, so the default derivation path for Mycelium Wallet is the one for addresses.  An extra parameter for the sub-path could have made it easier to use, but as a toolkit, the site offers the functionality it's built for.

Oh, and your spelling of Mycelium is wrong in most instances.  ‘Celium’ is not a word.

Why, they are still there on the Indiegogo page: https://www.indiegogo.com/projects/mycelium-entropy.

There are standard internationalisation and localisation practices in software development.  The operating system and its libraries already know how things like number and date formatting are done in its current locale.  There is a very simple interface for software developers to adopt the local conventions without having to know all the gory details.

Properly written software normally uses the standard system facilities to format its numbers for presentation to users.

However, if the text is in English but numbers are in German (because the software is running in a German locale), that is confusing as well.  Perhaps the right way is to use locale settings for numbers if the strings are also translated; and use English numbers when falling back to English text due to lack of translation.