Mycelium Bitcoin Wallet

[Jan]

Security question here: I store my backup online, but the 15 character password locally. If someone were to get ahold of my encrypted backup, how quickly could they bruteforce it? With 26 characters to choose from, there is 26^15 possibilities, but how long does it take to test each one?

About 1 million years if they use 1 million of today's desktop computers to brute force it.
More info here:
http://www.mycelium.com/wallet/FAQ.html#q020
http://www.mycelium.com/wallet/FAQ.html#q021

[1715034773]

1715034773

[apetersson]

Security question here: I store my backup online, but the 15 character password locally. If someone were to get ahold of my encrypted backup, how quickly could they bruteforce it? With 26 characters to choose from, there is 26^15 possibilities, but how long does it take to test each one?

I just measured it using this program:

Code:

@Test
   @Ignore
   public void testSpeed() throws InterruptedException {
      long start = System.currentTimeMillis();
      int tries = 1000;
      for (int i = 0; i < tries; i++) {
         KdfParameters params = new KdfParameters("123" + i, TEST_SALT_1, MrdExport.V1.DEFAULT_SCRYPT_N, MrdExport.V1.DEFAULT_SCRYPT_R, MrdExport.V1.DEFAULT_SCRYPT_P);
         EncryptionParameters.generate(params);
      }

      double duration = (System.currentTimeMillis() - start)/1000.0;
      System.out.println("duration:" + duration+" s");
      double speed = (double) tries / duration;
      double secondperTry = 1/speed;

      System.out.println("secondperTry "+ secondperTry+" / s ");
   }

output:

Code:

duration:104.771 s
secondperTry 0.10477099999999999 / s 

i ran it with -server VM in sun JDK

so it does about 10 tries/second under near-optimal conditions on a fast CPU. (i7 4770K) in single-thread mode, with JIT compiler.

this means a single core takes 390 times the age of the universe to crack a single backup. when you speed that up to graphics cards, asics if becomes shorter but still outside human lifespans.

[RGBKey]

That's good, I never considered how much security 15 Alphabetic characters could give. Thanks for testing that.

[Jan]

That's good, I never considered how much security 15 Alphabetic characters could give. Thanks for testing that.

Nore that  this is not a generic result that can be applied anywhere. It requires that the password is random (read not human generated) and scrypt (or something similar) is applied.

[RGBKey]

That's good, I never considered how much security 15 Alphabetic characters could give. Thanks for testing that.

Nore that  this is not a generic result that can be applied anywhere. It requires that the password is random (read not human generated) and scrypt (or something similar) is applied.

Of course, that's pretty obvious. Have some faith in me

[(A)social]

That's good, I never considered how much security 15 Alphabetic characters could give. Thanks for testing that.

Nore that  this is not a generic result that can be applied anywhere. It requires that the password is random (read not human generated) and scrypt (or something similar) is applied.

What about cat generated passwords? I'd trust my little fellow* more than any human


*no, it isn't that in the pic

[RGBKey]

That's good, I never considered how much security 15 Alphabetic characters could give. Thanks for testing that.

Nore that  this is not a generic result that can be applied anywhere. It requires that the password is random (read not human generated) and scrypt (or something similar) is applied.

What about cat generated passwords? I'd trust my little fellow* more than any human


*no, it isn't that in the pic

Imagine a die like a magic 8 ball, except the die is a cube, and on each side there is a seperate container for a magic 8 ball type liquid filled chamber with another die inside of it, making a 36 sided die.

[IamNotSure]

Would it be considered "unsafe" to test a cold wallet address (properly generated, live USB, BIP 38, dumb printer etc.) with the Mycelium cold storage spending function. All this on a dumb smartphone (factory reset, not connected to GSM network, just connected to wpa2 secure wifi to D/L mycelium to make the test spend)

Or should I be more paranoid and this address should be considered not "cold" anymore by having touched breifly the network? And using Armory is the only solution ?

[apetersson]

Would it be considered "unsafe" to test a cold wallet address (properly generated, live USB, BIP 38, dumb printer etc.) with the Mycelium cold storage spending function. All this on a dumb smartphone (factory reset, not connected to GSM network, just connected to wpa2 secure wifi to D/L mycelium to make the test spend)

Or should I be more paranoid and this address should be considered not "cold" anymore by having touched breifly the network? And using Armory is the only solution ?

that depends on your paranoia level. i'd say it is cold enough.
since i don't know anything about root exploits of that dumb smartphone, be sure to ONLY install mycelium.

[soullyG]

I see the latest version dropped the "Avg." pricing info. Would it be a big thing to bring it back?

I'd also like to see this feature brought back, and if possible, add the ability to customize which of the exchanges count towards this average. Also, are there any plans to add multi-send to the wallet?

Thanks for all your hard work, Mycelium makes it a pleasure to use Bitcoin - you guys are on the forefront of wallet software development - never stop innovating! 

[Jan]

I see the latest version dropped the "Avg." pricing info. Would it be a big thing to bring it back?

I'd also like to see this feature brought back, and if possible, add the ability to customize which of the exchanges count towards this average. Also, are there any plans to add multi-send to the wallet?

Thanks for all your hard work, Mycelium makes it a pleasure to use Bitcoin - you guys are on the forefront of wallet software development - never stop innovating! 

Thanks.

We have started adding rates from sources that are not actual exchanges such as Coinbase and BitPay.
Many users have requested this as it allows them to see what their coins are worth when buying at for instance Coinbase or spending at a BitPay enabled merchant. Since these sources do not have a volume associated we cannot really calculate a weighted average.

In the testnet version (released 2 days ago) we have added BitcoinAverage. They make a business out of monitoring and selecting relevant exchange sources, and we believe that they track the markets closer than the Mycelium developers.

The default choice is right now Bitstamp, and it is up to the user to select a source that he/she finds valuable and trustworthy.

[bitcoincodes]

It would be really nice if the user could set the tx fee to 0 or lower than 0.0001.
For most Transactions 0.00001 or 0.000001 BTC fee would be enough. So it would be nice to set the fee at the users own wishes.

BTW: I really like the App.. especially the function to spend btc directly from a cold / paper wallet.. good job guys.

[Rassah]

It would be really nice if the user could set the tx fee to 0 or lower than 0.0001.
For most Transactions 0.00001 or 0.000001 BTC fee would be enough. So it would be nice to set the fee at the users own wishes.

BTW: I really like the App.. especially the function to spend btc directly from a cold / paper wallet.. good job guys.

Right now the fee in default Bitcoin-QT nodes is hardcoded to 0.0001BTC, so setting it lower runs the risk of your transaction not being broadcast. We will lower the fee once 0.9 comes out, which will drop the fee further.

[ffe]

I've run into a situation where Mycelium was monitoring two public keys - one the compressed version of the other. It showed a positive balance for the the compressed public key and a zero balance for the normal public key.

I loaded the private key to see if it was required for Mycelium to recognize that the two public keys are for the same private key, but it simply attached it to the compressed public key. The uncompressed one remained observer only (no private key associated) and still with a zero balance.

Questions:
- Is it mathematically possible to calculate the compressed public key from the uncompressed one (and visa-versa) in the absence of the private key? (I assume if you have the private key they can theoretically be associated since you can calculate each from the private key.)

- Is it possible to make one of the two forms the canonical form internally so that loading either into Mycelium causes the correct private key's balance to be tracked?


Background: I ended up with a compressed version of the public key when I loaded a BIP38 protected key into the app on a dedicated device separate from my phone. I then transferred some coin to it.
I had been monitoring the full public key on my regular phone and it failed to show the new balance. I then loaded the compressed key to my phone and ended up with the situation described.

[witwit]

Right now the fee in default Bitcoin-QT nodes is hardcoded to 0.0001BTC, so setting it lower runs the risk of your transaction not being broadcast. We will lower the fee once 0.9 comes out, which will drop the fee further.

I would personally love the ability to set your own fee, since this can be done safely if you know what you are doing (txn priority and so forth). I would definitely hide it behind an "expert" mode, though.

[cetus]

I've run into a situation where Mycelium was monitoring two public keys - one the compressed version of the other. It showed a positive balance for the the compressed public key and a zero balance for the normal public key.

Compressed and uncompressed form of the same public key correspond to different Bitcoin addresses.  They have individual balances and behave like independent addresses.  They just happen to have the same private key which can be used to spend coins from each of them.

I loaded the private key to see if it was required for Mycelium to recognize that the two public keys are for the same private key, but it simply attached it to the compressed public key. The uncompressed one remained observer only (no private key associated) and still with a zero balance.

Private key representations usually include a flag to indicate whether the key is meant to be used with a compressed public key or uncompressed one.  I believe if you set that flag to 'uncompressed', Mycelium will attach it to the other address.

Questions:
- Is it mathematically possible to calculate the compressed public key from the uncompressed one (and visa-versa) in the absence of the private key? (I assume if you have the private key they can theoretically be associated since you can calculate each from the private key.)

Yes.

- Is it possible to make one of the two forms the canonical form internally so that loading either into Mycelium causes the correct private key's balance to be tracked?

I don't think there is such a thing as a "private key's balance".

If you want to use both compressed and uncompressed public keys, I think you can load your private key twice with different flags and Mycelium should do the right thing then.  Mathematically these private keys are identical, but logically they are different.

Background: I ended up with a compressed version of the public key when I loaded a BIP38 protected key into the app on a dedicated device separate from my phone. I then transferred some coin to it.
I had been monitoring the full public key on my regular phone and it failed to show the new balance. I then loaded the compressed key to my phone and ended up with the situation described.

I don't know BIP38, unfortunately.  The SIPA format for private keys includes the compression flag.  It was either the loss of information (flag) during private key transfer to the dedicated device, or a failure of the app on that device to interpret that flag correctly, that created such situation.

[ffe]

Thanks for the clarification. Much appreciated!

[Bees Brothers]

Thank you Rassah for taking the time at the Texas Conference to sit down with us and answer several questions about using Mycelium.

We will be doing some small workshops in our town for small businesses about using bitcoin and the time spent with you was very helpful.

 

[roslinpl]

Thank you Rassah for taking the time at the Texas Conference to sit down with us and answer several questions about using Mycelium.

We will be doing some small workshops in our town for small businesses about using bitcoin and the time spent with you was very helpful.

 

Did you record him on a camera?
It would be nice to see what he was telling to you.

regards!

[RGBKey]

Is Mycelium ready for the changes coming with 0.90? I expect we should have support for lower fees cery soon after official release and support for payment requests later on?