Mycelium Bitcoin Wallet

[ffe]

Is it your plan to continue supporting importing bitcoin spinner backup keys into the foreseeable future? Or should we plan on moving away from spinner generated keys over some time frame?

[Jan]

Will Mycelium be implementing HD wallets, or the new payment protocol, any time soon?

We are not working on either of those features right now. Implementing proper support for HD wallets (where you can operate on practically an unlimited number of keys) on a phone is not trivial. I am pretty sure that the payment protocol comes before HD wallets, and whether we get to HD wallets... I don't know. Andreas has some interesting ideas, but it remains to be seen whether it is going to be efficient.
The last few weeks we have been working on giving the UI a more modern look and feel and encrypted backups. We expect to have the next release ready in about 3 weeks.

[Jan]

Is it your plan to continue supporting importing bitcoin spinner backup keys into the foreseeable future? Or should we plan on moving away from spinner generated keys over some time frame?

Yes.
Once Mycelium gets to version 1.0 (1.0 goal is within 2013) BitcoinSpinner will get retired. The import functionality in Mycelium however will remain.
Note that BitcoinSpinner allows you to backup in two ways.
1. Settings -> Backup (the one that you can also restore in BitcoinSpinner)
2. Settings -> Advanced -> Export (the one that gives you a standard SIPA formatted private key)
Option 2 is the one that is broadly supported across wallets, so that would be the most portable way of backing up your BitcoinSpinner key. Mycelium can import both.

[Rassah]

If HD wallets just use an incrementing integer added to the seed to generate keys, I figure it would be easy. Just always send all change to a new address, increment the counter, and disgard the old address. That way all you have to keep a record of is the seed and the current counter. The last option to add would be to scan all addresses, from first to the counter, to see if they have any coins, and sweep the coins to the most recent address, in case one of your old addressees get paid.

As for restoring backups, just have it scan addresses one by one until it finds one with a balance.

[Jan]

If HD wallets just use an incrementing integer added to the seed to generate keys, I figure it would be easy. Just always send all change to a new address, increment the counter, and disgard the old address. That way all you have to keep a record of is the seed and the current counter. The last option to add would be to scan all addresses, from first to the counter, to see if they have any coins, and sweep the coins to the most recent address, in case one of your old addressees get paid.

As for restoring backups, just have it scan addresses one by one until it finds one with a balance.

Implementing BIP 32 and creating keys is the easy part. Where it really starts getting tricky is when have to track track the unspent outputs and transaction history of an ever increasing key set. Some have suggested a moving window of keys to track, and that will work as long as no one sends funds to an address outside the window. Bitsofproof is working on such a solution, and it is going to be interesting to see how it works out. My guess is that a lot of confusion will arise when funds seemingly disappear when they are received outside the window...
You can amended this by doing a complete scan once in a while. This however is where it gets really expensive. If you have your own dedicated powerful host running Armory this is not a problem, but I don't think it scales to thousands of wallets.

[Rassah]

You can amended this by doing a complete scan once in a while. This however is where it gets really expensive. If you have your own dedicated powerful host running Armory this is not a problem, but I don't think it scales to thousands of wallets.

Anyone know how long it would take an SPV client to do a query on 1000 Bitcoin addresses? I don't expect it to take more than a minute, but I may be way off. Also, I guess it would require Mycelium to at least partially do SPV mode.

[Technomage]

I have a development suggestion. How about adding a CoinJoin mixing option to Mycelium wallet? That would be an excellent feature. Similar to what Blockchain.info is doing with their sharedcoin trustless mixing right now. What do you guys think about this idea? These sort of features are a must if we want to continue to protect the privacy of Bitcoin users.

[apetersson]

I have a development suggestion. How about adding a CoinJoin mixing option to Mycelium wallet? That would be an excellent feature. Similar to what Blockchain.info is doing with their sharedcoin trustless mixing right now. What do you guys think about this idea? These sort of features are a must if we want to continue to protect the privacy of Bitcoin users.

i think it is an excellent idea. and the idea works even better if it is the default mode of operation. the question where to get the resources for implementing this.

[Rassah]

I have a development suggestion. How about adding a CoinJoin mixing option to Mycelium wallet? That would be an excellent feature. Similar to what Blockchain.info is doing with their sharedcoin trustless mixing right now. What do you guys think about this idea? These sort of features are a must if we want to continue to protect the privacy of Bitcoin users.

i think it is an excellent idea. and the idea works even better if it is the default mode of operation. the question where to get the resources for implementing this.

Aren't you guys already running Mycelium servers?

Btw, I didn't look into CoinJoin too closely (hadn't had time to run it myself yet), but doesn't it need Tor to be really anonymous?

[westkybitcoins]

How much does Mycelium require in the way of phone resources?

I've just bought an older-model Huawei Glory smartphone (Android 4.0.4); I haven't loaded a lot on there, but apparently it typically hovers at about 150 MB of RAM free. Mycelium runs, I've sent a few bitcents to the address on the phone. The transaction has over 150 confirmations, but the app refuses to update the info, showing the app as "receiving" the coins and at 0 confirmations no matter how often I refresh.

I've run apps that I thought were more resource-hungry than Mycelium, and they work (if slowly). Will Mycelium just not work on such lightweight phones?

[Abdussamad]

How much does Mycelium require in the way of phone resources?

I've just bought an older-model Huawei Glory smartphone (Android 4.0.4); I haven't loaded a lot on there, but apparently it typically hovers at about 150 MB of RAM free. Mycelium runs, I've sent a few bitcents to the address on the phone. The transaction has over 150 confirmations, but the app refuses to update the info, showing the app as "receiving" the coins and at 0 confirmations no matter how often I refresh.

I've run apps that I thought were more resource-hungry than Mycelium, and they work (if slowly). Will Mycelium just not work on such lightweight phones?

I don't think its lack of resources that is tripping you up. One of the core devs has talked about using a used sony phone for mycelium. You can see it in action in the play store video.

[westkybitcoins]

Seems to be working fine now. Possibly a server glitch? No worries though; it's not like we don't have the private keys ourselves.

[Jan]

... No worries though; it's not like we don't have the private keys ourselves.

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

[apetersson]

Btw, I didn't look into CoinJoin too closely (hadn't had time to run it myself yet), but doesn't it need Tor to be really anonymous?

the question is what exactly do you want to hide.

if you want to hide the info what exactly you are joining, this is already provided by using SSL with hardcoded fingerprints.

if you want to obfuscate your IP when talking to the Mycelium server so we can no longer "connect the dots", yes then you need tor. we already have socks proxy support so you can install Orbot and run Mycelium over it. so this is mostly covered.

additionally the connection is SSL anyways, so not even an exit node can look into the data.
if you want to hide the fact that you are using Bitcoin/Mycelium - an exit node would have evidence that you are using Mycelium wallet. to make that more private, we would need to run a tor hidden service too, to provide the best possible privacy.

[(A)social]

Will the testnet version be dropped at some time (like it happened with Bitcoin spinner, IIRC), or will be mantained along the production one (like Bitcoin Wallet)? I think it would be good idea to keep it, not only for testing purpose, but It could be useful to show peoples how bitcoin works without messing up with the real thing.

[apetersson]

Will the testnet version be dropped at some time (like it happened with Bitcoin spinner, IIRC), or will be mantained along the production one (like Bitcoin Wallet)? I think it would be good idea to keep it, not only for testing purpose, but It could be useful to show peoples how bitcoin works without messing up with the real thing.

we just started it and we are using it a lot for development. you can expect that we will not turn it off deliberately until further notice.

the uptime will be significantly worse and maybe even cut off backwards compatibility, because we sometimes try out things that turn out to be a bad idea. so you need to keep your installation of testnet really up to date and don't be confused if it does not work sometimes..

[coqui33]

I have ten active (read-only) keys. Mycelium will not let me add an eleventh key. (The "+"button is dead.) Is there any setting where I can increase this limit?

[Jan]

I have ten active (read-only) keys. Mycelium will not let me add an eleventh key. (The "+"button is dead.) Is there any setting where I can increase this limit?

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.

[coqui33]

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.

Cool. That solves my problem. Thanks.

[Jan]

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