BitcoinSpinner

[Jan]

your issue is the same with any wallet software of course. bitcoin-qt multibit, bitcoiJ based wallet for android, and even more blockchain.info.

it would make sense to have an independent service out there that downloads the apk from play store and verifies they correnspond to the source. unfortunately i don't know any such service.
...

They are called volunteers 

Seriously, this could be part of the release process. New versions are released to the beta channel, once a trusted third party has downloaded and verified the build it is released to the general public.

[1713253790]

1713253790

[1713253790]

1713253790

[1713253790]

1713253790

[1713253790]

1713253790

[1713253790]

1713253790

[1713253790]

1713253790

[molecular]

you can literally check out the source from github (git clone, gradlew build) and build it yourself. or you can download the signed apk from mycelium.com. of course you need to keep up to date when we release new builds. there will be several changes to the server API while we are in beta.

The problem is that yes, I can do that but even though I call myself an Android Developer (see my sig first item and the pull request for Spinner) I run your binary of Mycelium now just because I'm lazy. You could literally go and take the $400 I currently store there. The only precaution I take is that I don't put my apps on auto-update so I update stuff only for a reason but with some time stamp triggered stealer you wold get me, too.

Is there a way for someone to assert that a certain apk corresponds to a certain version of the source code? Trying to build the apk and hoping it will result in the exact same binary for some reason seems error-prone. Or should this work?

[molecular]

your issue is the same with any wallet software of course. bitcoin-qt multibit, bitcoiJ based wallet for android, and even more blockchain.info.

it would make sense to have an independent service out there that downloads the apk from play store and verifies they correnspond to the source. unfortunately i don't know any such service.
...

They are called volunteers 

Seriously, this could be part of the release process. New versions are released to the beta channel, once a trusted third party has downloaded and verified the build it is released to the general public.

Quite frankly, that's kind of how it works now: people just hope in case of malicious code being introduced into some app someone will notice and they will somehow get word of it.

That's not a good solution and I've been thinking about offering such service. It's a lot of work, however and I doubt people would donate/pay enough to make it a business option.

"once a trusted third party has downloaded and verified the build it is released to the general public" <- making this part of your release process doesn't keep you from changing the release process and sneaking in malicious code anyhow, does it?

[apetersson]

"once a trusted third party has downloaded and verified the build it is released to the general public" <- making this part of your release process doesn't keep you from changing the release process and sneaking in malicious code anyhow, does it?

if that was the release policy any attempt to circumvent this could be detected, since you can not release a different APK on google play with the same android:versionCode. A release that was checked in the beta channel can not be released in a modified way in the regular channel with the same android:versionCode. the play store policy forbids that.

[elebit]

Seriously, this could be part of the release process. New versions are released to the beta channel, once a trusted third party has downloaded and verified the build it is released to the general public.

You could also utilize a trusted service such as F-Droid to do this. If the build in Play store and F-Droid differs, that would be cause for an alarm.

It's not perfect but at least an indication that nothing fishy happened during build time.

[Jan]

"once a trusted third party has downloaded and verified the build it is released to the general public" <- making this part of your release process doesn't keep you from changing the release process and sneaking in malicious code anyhow, does it?

if that was the release policy any attempt to circumvent this could be detected, since you can not release a different APK on google play with the same android:versionCode. A release that was checked in the beta channel can not be released in a modified way in the regular channel with the same android:versionCode. the play store policy forbids that.

There are two basic privileges required to make an update on Google Play:

1) The app needs to be signed with the same key as the currently signed app. Both Google Play and your phone will not allow an update otherwise.
2) The bits being uploaded are authenticated by a user name / password.

We can on the Mycelium side make sure that no-one has the ability to do both steps (I have never had access to the signing key) so that two distinct groups can do one but not the other. Both groups need at least two members to make sure that we can always make an update (people go on vacation, get hit by a bus etc).

Then there is the third step
3) The APK is released on the beta channel. One or more trusted members of the community (volunteers) build the same APK from source code, and compare its thumbprint to the version on the beta channel, and posts the results in a forum thread and on the beta channel.

Since Mycelium cannot upload a different build with the same version to Google Play the bits cannot be altered unless a new version is made.

For some people this may not be secure enough. They have the option to build versions from sources for themselves.

How does that sound?

[niko]

On my Samsung Note, Mycelium qr code scanner cannot focus when I bring the code close (in case of smaller images I have to). It appears that it is not autofocusing at all. Spinner with barcode scanner did not have this problem (likely because I had the autofocus turned on in the scanner's settings menu).
As a consequence,  Mycelium takes a long time, or sometimes fail, to scan the code that Spinner was getting in  a second.

[apetersson]

niko, this is an interesting observation, thanks.

Mycelium Wallet uses almost the same codebase as Barcode Scanner, but as an internal code - for security reasons.

We do hide all scanner preferences, i will take a closer look what it assumes about the autofocus. my first test on my device indicates that autofocus is fully enabled. if it helps, i could bring autofocus to our settings.

[apetersson]

currently in the beta channel but will be available soon:

v0.6.3
Cold Wallet spending wizard
Consolidated key view
support for BGN currency
optional autopay threshold
change now goes to one of the originating addresses
improved exception reporting
don't act as a barcode reader
eligius-style mining transactions
one-step removal of private keys

[niko]

niko, this is an interesting observation, thanks.

Mycelium Wallet uses almost the same codebase as Barcode Scanner, but as an internal code - for security reasons.

We do hide all scanner preferences, i will take a closer look what it assumes about the autofocus. my first test on my device indicates that autofocus is fully enabled. if it helps, i could bring autofocus to our settings.

This appears to be device-specific. I just tried Mycelium on an ASUS tablet, and autofocus works properly. On my Note, it doesn't. Again, Note autofocuses fine using the Barcode Scanner app.

[niko]

Are exchange rates pulled from MtGox or Bitcoincharts? Ideally, I would like to be able to specify an exchange at bitcoincharts. VirtexCAD is more relevant to us here than thenlow-volume MtGoxCAD.

[Jan]

Are exchange rates pulled from MtGox or Bitcoincharts? Ideally, I would like to be able to specify an exchange at bitcoincharts. VirtexCAD is more relevant to us here than thenlow-volume MtGoxCAD.

For USD/BTC the rate is the weighted average between MtGox and BitStamp. For other currencies it is based on MtGox.
I'll add your suggestion to the wish-list.

[Jan]

currently in the beta channel but will be available soon:
...

In case you didn't notice. Version 0.6.4 is generally available through Google Play and for direct download here.

Major changes:

• Aggregated/Segregated key view: In settings you can configure whether you want to view the combined balance/transaction-history of all your keys (Aggregated view) or the per key balance/transaction-history (Segregated View). Until now segregated view was the only choice. Now aggregated is the default.
• Cold storage spending: Scan a private key and spend from it. Awesome demo here.
• Optional autopay threshold: AKA, scan to pay, allows you to set a payment threshold value. If you scan a payment request (Bitcoin address + amount to pay), with a value below the specified threshold the transaction is sent with no further user interaction (If a PIN is configured you still have to enter it).
• Support for BGN currency
• Trimmed transaction history: Transaction history will only list the outputs for your keys. Other outputs are omitted (but available in transaction details). This is very useful if you are mining at Eligius, which does payouts with hundreds of outputs.
• Individual key balance: In Keys & Addresses you can now see the last known balance of the individual keys.

Enjoy & give feedback.
If you haven't rated the app on Google Play please do so now. 5 stars appreciated 

[Newar]

Are exchange rates pulled from MtGox or Bitcoincharts? Ideally, I would like to be able to specify an exchange at bitcoincharts. VirtexCAD is more relevant to us here than thenlow-volume MtGoxCAD.

For USD/BTC the rate is the weighted average between MtGox and BitStamp. For other currencies it is based on MtGox.
I'll add your suggestion to the wish-list.

How about bitcoinaverage.com ( http://api.bitcoinaverage.com/ ) ?

[Jan]

Are exchange rates pulled from MtGox or Bitcoincharts? Ideally, I would like to be able to specify an exchange at bitcoincharts. VirtexCAD is more relevant to us here than thenlow-volume MtGoxCAD.

For USD/BTC the rate is the weighted average between MtGox and BitStamp. For other currencies it is based on MtGox.
I'll add your suggestion to the wish-list.

How about bitcoinaverage.com ( http://api.bitcoinaverage.com/ ) ?

We prefer to get the exchange rates directly from the exchanges to avoid third party interpretation, and will expand the list of supported exchanges as we go. Eventually we may let the user specify which exchanges to base the weighted average on.

[westkybitcoins]

currently in the beta channel but will be available soon:
...

In case you didn't notice. Version 0.6.4 is generally available through Google Play and for direct download here.

Major changes:

• Aggregated/Segregated key view: In settings you can configure whether you want to view the combined balance/transaction-history of all your keys (Aggregated view) or the per key balance/transaction-history (Segregated View). Until now segregated view was the only choice. Now aggregated is the default.
• Cold storage spending: Scan a private key and spend from it. Awesome demo here.
• Optional autopay threshold: AKA, scan to pay, allows you to set a payment threshold value. If you scan a payment request (Bitcoin address + amount to pay), with a value below the specified threshold the transaction is sent with no further user interaction (If a PIN is configured you still have to enter it).
• Support for BGN currency
• Trimmed transaction history: Transaction history will only list the outputs for your keys. Other outputs are omitted (but available in transaction details). This is very useful if you are mining at Eligius, which does payouts with hundreds of outputs.
• Individual key balance: In Keys & Addresses you can now see the last known balance of the individual keys.

Enjoy & give feedback.
If you haven't rated the app on Google Play please do so now. 5 stars appreciated 

Jan, so far the new app is amazing! I love that you've managed to keep most of the user-friendliness of it, while adding all of these new features (having the ability to print out private keys straight from the phone via the SD card really is impressive.) I also think the emphasis on cold storage was much needed, and really puts Mycelium just a step away from being usable as a hack-proof makeshift hardware wallet.

With that in mind, a couple of questions:

1) How suitable is the code is to having something similar to Armory's noteworthy offline-transactions feature implemented? I will be downloading the Mycelium code this week and seeing if I can contribute to such a feature directly.

2) Is there a donation address visible anywhere in the app? (Or, if you're not going to be soliciting donations, is there any other way you plan on monetizing the app that we could contribute to?)

[Jan]

Jan, so far the new app is amazing! I love that you've managed to keep most of the user-friendliness of it, while adding all of these new features (having the ability to print out private keys straight from the phone via the SD card really is impressive.) I also think the emphasis on cold storage was much needed, and really puts Mycelium just a step away from being usable as a hack-proof makeshift hardware wallet.

With that in mind, a couple of questions:

Thanks!

1) How suitable is the code is to having something similar to Armory's noteworthy offline-transactions feature implemented? I will be downloading the Mycelium code this week and seeing if I can contribute to such a feature directly.

So I guess that you want the wallet split into two parts. One (online) that builds an unsigned transaction and one (offline) that does the signing. Communication by SD card. This is doable, but also cumbersome to use.

If you use the solution as it is now with a dedicated device using cyanogenmod, no SIM, and only Mycelium installed, locked into a safe along with your paper private key, then I believe you are in pretty good shape. Which additional attack vectors are there as opposed to a split implementation?

2) Is there a donation address visible anywhere in the app? (Or, if you're not going to be soliciting donations, is there any other way you plan on monetizing the app that we could contribute to?)

Going forward we are planning to add revenue generating features. At the San Jose conference we demonstrated the Mycelium Payment System (in development), which allows physical shops to:
 - Sell products/services for BTC
 - Sell BTC back to customers
 - Buy BTC from customers
All in all things that let your local Bitcoin economy flourish.
We develop the wallet because we believe that better mobile wallets are needed, and we are going to integrate the wallet with our payment system (locate shops, view invoices in transaction history, etc), this is where we believe we are going to make a profit.

[hgmichna]

If you use the solution as it is now with a dedicated device using cyanogenmod, no SIM, and only Mycelium installed, locked into a safe along with your paper private key, then I believe you are in pretty good shape. […]

Let's add, no Google account, no Google apps, particularly not any app market.

But anyway, the cold-storage idea does not create security. The weak part is the WiFi connection, because you cannot make sure it is entirely safe. An attacker could find an exploit and insert malware.

To make it safe, you would have to use a narrower communications channel. It should be a channel that is either obviously too slow to do more than one transaction or, better, one that the user can supervise, such as the camera taking an image that the user can see and read.

This would mean a two-device solution, with one secure device holding the private key and doing the signing.

I agree though that this is not needed for small amounts.

[Jan]

If you use the solution as it is now with a dedicated device using cyanogenmod, no SIM, and only Mycelium installed, locked into a safe along with your paper private key, then I believe you are in pretty good shape. […]

...
But anyway, the cold-storage idea does not create security. The weak part is the WiFi connection, because you cannot make sure it is entirely safe. An attacker could find an exploit and insert malware.
...

Insert malware where which does what?
 
The connection is HTPS encrypted and the certificate pinned by the app, but regardless, even if the communication was publicly broadcasted and the attacker could change the communication any way he likes, he will worst case be able to:
1. Present you with invalid (or already spent) unspent outputs
2. Mess around with the signed transaction before broadcasting
3. Not broadcast the transaction

In any event those attacks will not make you loose funds, you will just not get anything sent.
The same attacks can be done to a split implementation.

[hgmichna]

Could a Trojan on the phone not steal the private key and send it somewhere?