Thanks.
Interesting idea and definitely should be an optional setting. Let me think it through. It wont be for the coming release though.

I agree. However,
We don't necessarily know the strength of the private key. The user can import arbitrary private keys.
We don't know how secure the user's email/dropbox/printer-app is (or whatever app user chooses to share the encrypted backup with).
Therefore we want a mechanism where we can reason about the strength of the password and give reasonable protection against brute force attacks.

Correct. But there are two problems, which make BIP38 cumbersome to use for our purpose.
1. With BIP38 you have to do the scrypt stretching for every key, as the input depends of the checksum of the bitcoin address of the private key you wish to encrypt. So when  exporting 10 keys you have to do 10 VERY heavy scrypt operations
2. The scrypt parameters for BIP38 are hardcoded and unfeasible to use on an many android devices. The paper mentions that they are subject to consensus, but  the ones who have BIP38 support have just gone ahead and used them as they are. So once can argue that consensus is there. The problem however is that they were chosen so they take 1-2 seconds on standard computer (cannot remember the reference to that, but it is in one of the many threads on the forum). Which is a strange way of setting security parameters. On one of my android devices BIP38 takes 6 minutes and 28 seconds to execute. If you couple that with the above and want to export just 10 keys, it will take more than an hour.

Instead we use a mechanism that resembles BIP38, but which does not require you to run scrypt for each key, and where scrypt parameters are parametrized as part of the output. This way we can configure the scrypt strength according to the password strength.

Correct. Unlike brain wallets, you can only brute force the password once you have obtained the encrypted backup.

Partly covered above. The password is basically there to protect our users from using unsafe transport from the app to the printer. Whether you write the password on the printout or somewhere else is entirely up to you. The backup mechanism is meant for having a secure and verifiable backup of your private keys.
If you want to protect yourself against a pickpocket you could very well use a BIP38 backup with a weak password. We are likely to add support for cold storage spending using BIP38 fairly soon.

Because many people who consider themselves clever use weak passwords. If someone looses his coins because he uses "correct horse battery staple" as his password it is going to fall back on the Mycelium developers.

Thanks.

With 70 bits and our current scrypt parameters we have a very large safety margin. The author of scrypt argues in this presentation that brute forcing on a 65 bit password would cost $43B using custom made semiconductor hardware. My own calculations estimate that bot-net of 1.000.000 standard desktop computers with 4 cores each will spend more than a million years brute-forcing a 70 bit passphrase.

I agree that increasing the password to 20 characters will be more secure, so will 25 characters, but it will also get less convenient and more cumbersome. In the end it is a matter of finding the sweet spot where baking a backup is convenient AND secure against feasible attacks. Many more coins have been lost due to missing backups than to theft.
Have in mind that what we are doing in 1.0 is a two factor backup. You need both the encrypted backup before you can start brute forcing the password. So the private keys are not generated from the password.

Maybe you have a clever scheme for remembering a long password, but I cannot let my users depend on that. Humans are in general notoriously bad at producing random data, and even worse at remembering it. Encouraging ordinary people to use brain wallets is a very poor idea in my mind.
With the approach we have chosen we can reason about the strength of the passwords, and argue for a lower bound for the amount of work a brute force attack requires. No amount of jokes will convince me otherwise.

That said, we are considering to have support for importing BIP38 keys, and do cold storage spending from them.

Here are the problems:
 - If you can remember a password it is probably not strong enough.
 - If you forget your password you loose your coins.
 - Entering a password that is secure is a pain, especially on android devices.

Therefore we are adding something else in the upcoming 1.0:
Export a PDF document to dropbox, gmail or whatever your device has installed. The PDF document contains QR-codes, one for each private key, but where the data is encrypted with a device-generated 15-character password (70 bits). The password is stretched using scrypt to form a 256-bit AES encryptionkey. The length of the password forces you to write down so you don't forget it. The length of the password combined with key stretching makes it proof against brute-force attacks. Mycelium will keep on nagging you until you have both exported AND imported all your keys (this is really to help you not loose your coins)

You can already try it out in the testnet version, here is a sample of the output: https://www.dropbox.com/s/x13chg7tmuvqqzi/mycelium-backup-11-11-13-2.05-PM.pdf

Here is the testnet version: https://play.google.com/store/apps/details?id=com.mycelium.testnetwallet&hl=en

Feedback welcome.

Great!
The prodnet version will be available to beta testers within hopefully one or two days. You can join the Google+ group (Mycelium Beta Testers) if you would like to help out with testing.

Whatever you do make sure to VERIFY that you can import the private key again.

I might add that it still takes 44 seconds to stretch the key on my low-end android device with the parameters we have selected.

I implemented BIP38 support a few weeks back, including unit tests, but it is not in the wallet. I am not that fond of BIP38.

The scrypt parameters of BIP38 are not final. From the spec: "n=16384, r=8, p=8, length=64 (n, r, p are provisional and subject to consensus)"
As far as I remember (from the forum, the wiki or where ever) the parameters were chosen so that the key stretching can be done on a computer in one or two seconds. This is IMO not a good practice when choosing parameters. I would rather base it on password strength and real-life brute-force attempt measurements, which I happened to find in this presentation from the author of scrypt.

The important thing is that you have to take the strength of your password into consideration when choosing parameters. I would much rather see a standard where the parameters are not set in stone (part of the output), OR even better a standard where the password has a guaranteed amount of entropy: password generated by the computer rather than a human. <-- this is important, humans are notoriously bad at creating secure passwords.

Running BIP38 with the suggested parameters on my android phone takes 388 seconds, or 6 minutes and 28 seconds, which is impractical. Instead I would like an implementation to provide guaranteed password entropy, and then stretch it with parameters that are practical to run within reasonable time while still making it take astronomical time to brute force. This is what I did, and it is part of the upcoming release of the Mycelium wallet. Whenever you make a backup a PDF is generated which for each private key has a QR code that contains an encrypted private key, where the password is 15 characters and generated by /dev/urandom (70 bits).

Here is a sample generated for testnet: https://www.dropbox.com/s/lme32phibry6kx9/mycelium-backup-10-24-13-4.16-PM.pdf


From our FAQ (not published yet):

Do you know chinese + understand bitcoin?
Send me a PM if you would like to volunteer translating the Mycelium Bitcoin Wallet.

Buy a cheap secondhand android device, wipe it and install only: Cyanogenmod + Mycelium Bitcoin Wallet + ... nothing else
Use the Cold Storage Spending feature with paper wallets, and don't use it for anything else.

Cheap + Easy + Secure

Demo: http://youtu.be/1pDSzOiFgIk

I have heard many stories like this with Coinbase.
Maybe you should use a real bitcoin wallet, where you are in control of your private keys, instead of a bitcoin bank. If you are not the sole owner of your private keys you don't have any coins.

Fixed

There Mycelium currently does not get market rates from Bitstamp.
Bitstamp did some kind of upgrade yesterday. We are working on it.

Currently there is a limit of 10 simultaneously active keys. You can have as many archived keys as you want, and moving a key back and forth between active and archive is easily done in Key Management.
If you wish to see the balance or spend from an archived key you just select it and go into the balance view. This way you will only operate on this one key.
We have plans to change this going forward.

Exactly! If you are not the only one who controls your private keys then you don't have any bitcoins.

Now let me explain what caused the missing confirmations.

The short version:
One of our super nodes got stuck on block 265458 due to a bug in our software. It has been fixed and everything is working as expected.

The long version:
We have node that continuously runs against the Bitcoin TEST network, and some days ago we observed that it got stuck on a block (http://blockexplorer.com/testnet/b/119058) which encodes script chunks in a non-standard way that we did not anticipate. This is the first block on the test network that has this behavior, and at that time it had never occurred on the production network (>4 years long block chain). A fix was made and verified to work against the test network.

The fix was also applied to one of our nodes on the production network (wanted to verify that it worked as expected before applying it everywhere). Yesterday a block with a similar non-standard script chunk encoding appeared on the production network. Because of that the unpatched node got stuck while the patched node continued to hum away happily.
Because the Mycelium wallet chooses a random node whenever it is restarted some users observed that no blocks got confirmed while others saw everything work as expected.

There is a brief discussion about my observations here: https://bitcointalk.org/index.php?topic=315509.0

Now observed on the prodnet: http://blockexplorer.com/tx/ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767
I think it is quite interesting that this is the first time in 4 years that we see something like that, and that it was a first for testnet 9 days ago.

I was under the impression that there were some basic chunking encoding rules (except for maybe coinbase input scripts), especially since no scripts have ever broken them until recently.
So you are saying that those kind of output scripts also may occur on prodnet?

On testnet I have observed output scripts that do not follow (what I consider) the basic chunking rules.

First occurrence in the testnet block chain (October 14 2013):
 Block: 0000000001fd48a0089ed98737a9212c62e7708d8ddde3aea7a9f57a138f769d
 Transaction outpoint: 4fed625bfe36c2d17d839a6407be374663ad823c2cde7073319bb51b8025a221:0
 Script bytes: 0130323066643366303435313438356531306633383837363437356630643265396130393739343 3323535343137666531393164386239636232306534306438633330303264313734633365393063 6632343339323138376131303762363437333763393733313563393239326465343137373163656 5613062323563633534353732653302ae

According to chunk decoding rules it should have 5 chunks with lengths 1, 50, 1, 57, 49. At the last chunk it goes beyond the script length. 
Chunk 1 (length  1): 0x30
Chunk 2 (length 50): 3066643366303435313438356531306633383837363437356630643265396130393739343332353 534313766653139316438
Chunk 3 (length  1): 0x62 (OP_VER)
Chunk 4 (length 57): 6362323065343064386333303032643137346333653930636632343339323138376131303762363 43733376339373331356339323932646534
Chunk 5 (length 49): 373731636565613062323563633534353732653302ae (only 22 of 49 bytes available)

According to my code it has never happened before on testnet, and never on prodnet.

On testnet it happens 3 times in block 0000000001fd48a0089ed98737a9212c62e7708d8ddde3aea7a9f57a138f769d and once in block 0000000000b6f43e05f86dfe2007107fc88ace03457294d7f74d960b239dc8bf

I was under the impression that non-standard output scripts were accepted on testnet, but that they should follow basic chunking rules.
Since bitcoind accepts those output scripts on testnet I have adapted my code to be more lax when doing script validation.

Can anyone confirm whether this can also happen on prodnet?