BitcoinSpinner

[niko]

This is certainly true if you encrypt a JPG image, as a cracking program can easily check whether a brute-force result yields a valid JPG file.
It may be much more difficult with just the text of the key, because that looks like gibberish anyway. Even with a relatively short password, many brute-force attempts may yield some similar gibberish, so the cracking program cannot discern the valid key from other wrong results with wrong passwords.

This is an important argument. It should be noted, however, that it is relevant if private key is in the raw, 32-byte form. If it is, the attacker has no idea whether he got the right passphrase until he performs ECDSA to create the public key, then ripemd160(sha256()) to create the address, and then search the blockchain for the address. That's a lot of work for each try, and only when you get lucky can you start hoping that there are unspent outputs.

In case of the usual WIF-encoded private keys, it seems easier because of the checksum. First of all, the brute-force attacker checks if candidate begins with a "5". Next, she converts it to hex, and checks if last four bytes are sha256(sha256()) of the remainder. If not, move on. If yes, only then search the blockchain. This eliminates most of slow steps related to blockchain search.

Does this make sense? How does computational burden compare between all the hashing and checking the blockchain in the above examples?

[1714897360]

1714897360

[1714897360]

1714897360

[hgmichna]

The average user would need it generated for him and put on paper.

You have convinced me. Sounds altogether like a good idea to me.

[ffe]

The thing is that many people think that their password is safe as they use something of similar size/complexity on web-sites. However, on a web-site the attacker cannot really brute force it until he has access to the encrypted password file or a hash of the password (maybe with some seed). Without this the hacker is left with a few attempts a second (through the web-page login), with the risk of locking the account he tries to gain access to. With brainwallets the attacker can start brute forcing  with trillions of attempts a second just by looking at the blockchain. (or in the case of a paper backup, once he has access to the encrypted private key).
I really want Mycelium users to use safe and verifiable mechanisms that do not lure them into using something that they think is safe while it is not.

So how about if we convert the attack on the blockchain into an attack on a website instead. We can do it by adding a protocol to the client to save the strong key, encrypted with the human password, on S3 Amazon cloud or Dropbox or something.

Only the strong key shows up on the blockchain and an attacker would have to dig up the user Dropbox account before conducting a dictionary attack.

The unencrypted strong key never leaves Mycelium.

[Jan]

This is certainly true if you encrypt a JPG image, as a cracking program can easily check whether a brute-force result yields a valid JPG file.
It may be much more difficult with just the text of the key, because that looks like gibberish anyway. Even with a relatively short password, many brute-force attempts may yield some similar gibberish, so the cracking program cannot discern the valid key from other wrong results with wrong passwords.

This is an important argument. It should be noted, however, that it is relevant if private key is in the raw, 32-byte form. If it is, the attacker has no idea whether he got the right passphrase until he performs ECDSA to create the public key, then ripemd160(sha256()) to create the address, and then search the blockchain for the address. That's a lot of work for each try, and only when you get lucky can you start hoping that there are unspent outputs.

In case of the usual WIF-encoded private keys, it seems easier because of the checksum. First of all, the brute-force attacker checks if candidate begins with a "5". Next, she converts it to hex, and checks if last four bytes are sha256(sha256()) of the remainder. If not, move on. If yes, only then search the blockchain. This eliminates most of slow steps related to blockchain search.

Does this make sense? How does computational burden compare between all the hashing and checking the blockchain in the above examples?

Yes, this makes sense. However, this also means that if the user (by accident) enters the wrong passphrase (this would happen a lot as it is pretty long), then he will get a different private key and address. Also, if the bitcoin address is on the same paper, which is VERY convenient, then you can brute force on the private key until you get the right address.
I would really prefer to make the passphrase strong enough to withstand that. It may not have to be as strong as the private itself, as you still need access to the encrypted private key, but it should be in the same ballpark.

[Jan]

The thing is that many people think that their password is safe as they use something of similar size/complexity on web-sites. However, on a web-site the attacker cannot really brute force it until he has access to the encrypted password file or a hash of the password (maybe with some seed). Without this the hacker is left with a few attempts a second (through the web-page login), with the risk of locking the account he tries to gain access to. With brainwallets the attacker can start brute forcing  with trillions of attempts a second just by looking at the blockchain. (or in the case of a paper backup, once he has access to the encrypted private key).
I really want Mycelium users to use safe and verifiable mechanisms that do not lure them into using something that they think is safe while it is not.

So how about if we convert the attack on the blockchain into an attack on a website instead. We can do it by adding a protocol to the client to save the strong key, encrypted with the human password, on S3 Amazon cloud or Dropbox or something.

Only the strong key shows up on the blockchain and an attacker would have to dig up the user Dropbox account before conducting a dictionary attack.

The unencrypted strong key never leaves Mycelium.

If I get you right you suggest that the private key is encrypted with a human generated (potentially weak) password. The encrypted private key is stored on dropbox. Access to dropbox is with a different human generated (potentially weak, or the same) password.
This would make you vulnerable to an insider attack at dropbox, or one of their historical hacks.

[ffe]

The thing is that many people think that their password is safe as they use something of similar size/complexity on web-sites. However, on a web-site the attacker cannot really brute force it until he has access to the encrypted password file or a hash of the password (maybe with some seed). Without this the hacker is left with a few attempts a second (through the web-page login), with the risk of locking the account he tries to gain access to. With brainwallets the attacker can start brute forcing  with trillions of attempts a second just by looking at the blockchain. (or in the case of a paper backup, once he has access to the encrypted private key).
I really want Mycelium users to use safe and verifiable mechanisms that do not lure them into using something that they think is safe while it is not.

So how about if we convert the attack on the blockchain into an attack on a website instead. We can do it by adding a protocol to the client to save the strong key, encrypted with the human password, on S3 Amazon cloud or Dropbox or something.

Only the strong key shows up on the blockchain and an attacker would have to dig up the user Dropbox account before conducting a dictionary attack.

The unencrypted strong key never leaves Mycelium.

If I get you right you suggest that the private key is encrypted with a human generated (potentially weak) password. The encrypted private key is stored on dropbox. Access to dropbox is with a different human generated (potentially weak, or the same) password.
This would make you vulnerable to an insider attack at dropbox, or one of their historical hacks.

Yes, you got me right. Of course it's a ton better than putting a human password on the blockchain subject to mass dictionary attack sweeps. I thought that was the point of the snippet of yours that I quoted.

I know you feel security should be only hard keys on paper never seeing the network. However, there are many people who just want the same level of security one gets with bank accounts with a few hundred dollars allowing online payments.

It's just too hard today to get my friends to use clients with locked in keys that can only be extracted unsafely or with elaborate precautions.

[Michael_S]

short feedback and improvement request:

spending directly from cold storage (paper wallet) to an arbitrary address is cool. I just used it to spend/"unload" some bitcoin vouchers.

But it makes no sense that mycelium asks for the PIN in this case, because I spend from an unencrypted private key anyway, so there is nothing to be protected (unlike the scenario of spending from app's priv key).

Hence the suggestion/request that mycelium shall NEVER ask for a PIN when spending from cold storage.

[Jan]

The thing is that many people think that their password is safe as they use something of similar size/complexity on web-sites. However, on a web-site the attacker cannot really brute force it until he has access to the encrypted password file or a hash of the password (maybe with some seed). Without this the hacker is left with a few attempts a second (through the web-page login), with the risk of locking the account he tries to gain access to. With brainwallets the attacker can start brute forcing  with trillions of attempts a second just by looking at the blockchain. (or in the case of a paper backup, once he has access to the encrypted private key).
I really want Mycelium users to use safe and verifiable mechanisms that do not lure them into using something that they think is safe while it is not.

So how about if we convert the attack on the blockchain into an attack on a website instead. We can do it by adding a protocol to the client to save the strong key, encrypted with the human password, on S3 Amazon cloud or Dropbox or something.

Only the strong key shows up on the blockchain and an attacker would have to dig up the user Dropbox account before conducting a dictionary attack.

The unencrypted strong key never leaves Mycelium.

If I get you right you suggest that the private key is encrypted with a human generated (potentially weak) password. The encrypted private key is stored on dropbox. Access to dropbox is with a different human generated (potentially weak, or the same) password.
This would make you vulnerable to an insider attack at dropbox, or one of their historical hacks.

Yes, you got me right. Of course it's a ton better than putting a human password on the blockchain subject to mass dictionary attack sweeps. I thought that was the point of the snippet of yours that I quoted.

I know you feel security should be only hard keys on paper never seeing the network. However, there are many people who just want the same level of security one gets with bank accounts with a few hundred dollars allowing online payments.

It's just too hard today to get my friends to use clients with locked in keys that can only be extracted unsafely or with elaborate precautions.

We are trying to make export as safe as possible, but you are right: Who would jump through a lot of hoops to secure a small sum for spending?
There are currently several backup strategies:
1. No backup - It is like a pair of pants, if you wash them the money is gone
2. Export as QR-code - The QR code is displayed, you take a picture with a secondary camera. This is very easy and as safe as your camera.
3. Export private key to clipboard - From there you can put it anywhere you like. You have to trust any other apps on your phone not to grab it, or use a dedicated device.
4. Export to SD card - This allows you to print it out directly from a SD card enabled printer with no computer in between. You have to trust any other apps on your phone not to grab it, or use a dedicated device.

I would use 1 if I had just a few dollars, and 2 if I only used it for small sums, and didn't want to bother with a dedicated device. Option 3 and 4 I would use for large sums and with a dedicated device.
Maybe option 2 would be suitable for your friends.
Personally I use option 4.

[Jan]

short feedback and improvement request:

spending directly from cold storage (paper wallet) to an arbitrary address is cool. I just used it to spend/"unload" some bitcoin vouchers.

But it makes no sense that mycelium asks for the PIN in this case, because I spend from an unencrypted private key anyway, so there is nothing to be protected (unlike the scenario of spending from app's priv key).

Hence the suggestion/request that mycelium shall NEVER ask for a PIN when spending from cold storage.

That makes a lot of sense. You got it.

[Michael_S]

a bug in mycelium 073:
I have 3 keys:
a - the old one (generated before the random generator fix),
b - an imported address (w/o priv key) and
c - a new self generated one.

only b has a balance, while a and c were never used! (maybe this is important)

I can shift each of the 3 keys back and forth between archived and active.

now I do this:
- I make "a" archived, and I make c an b active, now mycelium shows the balance of b, which seems correct.
- now I move also b to archive, only c remains active.

now strange (bug!): mycelium main page still shows b as my key, and also my balance is still indicated as the balace of b, i.e. mycelium behaves as if b is still active, not archived, and ignores the fact that "c" is active!
the situation persists even after restart of mycelium.

I can "fix" the situation by shifting c to "archive" and then back to "active". Now situation is as expected.

(sorry for brevity - typing this from my smartphone)

[apetersson]

Yes, this was observed by me as well. there is a slight bug where the old view is not discarded. A fix is underway where initialization is moved to onResume. The next beta will contain a fix for that.

a bug in mycelium 073:

[apetersson]

exchange rates from mtgox are fixed for now, especiall EUR quotes should be more accurate (but still Mtgox)

https://bitcointalk.org/index.php?topic=286422.0

In the future, you will see much less reliance on Mtgox and very flexible display of exchange rates, stay tuned.

We have the best Bitcoin Economist in the world working on how to handle exchange rates in Mycelium Bitcoin Wallet

[niko]

I may have missed this: are you preparing a PoS version for merchants? Even now Mycelium might be a good option, with some specific tweaks it would become a powerful, secure PoS terminal.

[apetersson]

Yes. we already presented a merchant application at Bitcoin2013. There are some infos out there how this worked, our NEFT ladies used it to sell stuff for bitcoin.

But i will not spoil all the fun you are going to have once we release it, we are working on a number of changes. It is going to be a seperate app from the Mycelium Wallet.

[Jan]

Version 0.7.5 has been released.
The over all theme for this release has been anonymity and improvements that make it easier to do p2p exchange.

Changes from version 0.7.3:

• Improved send wizard: You can now enter receiver and amount in any order, and you can review the receiver right after scanning. Also, if your clipboard contains a valid formatted amount of decimal dotted BTC amount (e.g. 1.23456789) you can paste it when specifying the amount
• Support for SOCKS proxy: This allows you to connect through Tor using Orbot or any other gateway, for those who wish improved anonymity. (I think Andreas will make a video that shows how)
• Fading QR code for improved readability in low-light scenarios. Yes, it really helps a lot especially on tablets and devices with poor camera
• Manual address entry for desperate people
• Support for freshly mined coins: Previously Mycelium let you create transactions with freshly mined coins, making transactions take up to about 16 hours to confirm. Now it does not include freshly mined coins in your spendable coins. This only affects you if you mine directly to a Mycelium managed address
• Bugfix to update the balance: If you went into settings and changed between Aggregated/Segregated view the balance was sometimes not updated when you went back to the balance view
• Cold storage spending wizard does no longer require PIN if you have it configured

With these changes it should now be easier to make p2p exchanges as you can:

• Enter the amount to send (the interesting part) before the address, which is just a means to an end.
• Pasting the amount that you have just calculated on an external calculator while bargaining.
• Manual address entry for those occasions where the buyer just has a paper slip.

Version 0.7.4 was only released in the beta channel. Version 0.7.5 contains minor fixes on top of 0.7.4.

As always it may take a few hours before you can get it from Google Play. It is also available for direct download.

Theme for the next release will most likely be sexing up the UI for the 1.0 release. On top of that we are working on letting you choose which exchange to get your rates from.

Enjoy

[niko]

I haven't thought this through, but would it make sense to include fiat amounts in the transaction history? I mean the actual historical worth, not the based-on-today's-exchange-rates worth. If you are already storing transaction data locally, adding this field would be trivial. If you are pulling the list from the server based on address(es), it might be too much work.

[giszmo]

I haven't thought this through, but would it make sense to include fiat amounts in the transaction history? I mean the actual historical worth, not the based-on-today's-exchange-rates worth. If you are already storing transaction data locally, adding this field would be trivial. If you are pulling the list from the server based on address(es), it might be too much work.

This. And more currencies please. $$ are of no use where I and 90% of humanity live.

[Rassah]

I haven't thought this through, but would it make sense to include fiat amounts in the transaction history? I mean the actual historical worth, not the based-on-today's-exchange-rates worth. If you are already storing transaction data locally, adding this field would be trivial. If you are pulling the list from the server based on address(es), it might be too much work.

This. And more currencies please. $$ are of no use where I and 90% of humanity live.

What, our drug money is suddenly not good enough for you??? 

[Technomage]

We have the best Bitcoin Economist in the world working on how to handle exchange rates in Mycelium Bitcoin Wallet

The best way to handle it is to give users options. However the default should be Bitstamp spot price, it's closer to the real Bitcoin exchange rate. Right now the exchange rate features are pretty much unusable since the Gox rate is almost useless (imo).

This should be #1 priority. Otherwise it's a brilliant wallet.

[giszmo]

Fading QR code for improved readability in low-light scenarios. Yes, it really helps a lot especially on tablets and devices with poor camera

Use the ambient light sensor please. It makes no sense to fade at noon in the Sahara.