Topic: BitcoinSpinner - page 10. (Read 55489 times)

Yes, that works. It just feels like making a bad situation worse. I haven't had to use it this way (yet), it's just that I've been in that situation before...

Our plan is to allow address entry using shortners like btc.to and firstbits in addition to full length addresses. We are however not ready for this yet. If anyone knows an open-source firstbits implementation I'd be interested in a link. In the meantime, wouldn't the clipboard do the trick for you in those rare cases where you need manual entry?

Thanks :-)
Two full time developers, a dedicated tester, and great feedback makes a huge difference.

Any change goes back to the paper wallet.

When entering the amount to pay you now have a "Max" button, which will calculate the maximum amount you can send from the key while paying the minimum network propagation fee of 0.0001 btc pr 1000 bytes of transaction size (iterative algorithm that eventually reaches a fix-point or fails, quite tiresome to do in your head if you have many small outputs). Anyway, hitting the Max button means you clean out the key, aka swiping.

This is quite cool! It would it possible to use paper wallets for spending in practice, and not just use-once.

I would like to reiterate my request for some manual address entry possibility (for use when you absolutely have to and no QR code is available).

guys, your development speed is outpacing my hopes

one question about cold storage spend: where does the change go?

Upcoming release 0.6.0 will feature some pretty interesting features:
- Switch between aggregated/segregated view: Switch between managing the combined balance of all your keys (aggregated) and key control (segregated))
- Cold storage spending and swiping: Basically scan key & spend, your key never hits flash storage
- Autopay amount: Scan to pay. When scanning a bitcoin URI, any amount below the Autopay threshold is spent without any dialogs (if a PIN is configured you still need to enter a the PIN)
- Keys & Addresses view now displays the balance of your individual keys

0.6.0 is available for testing now. To get access you just need to join the g+ group at
https://plus.google.com/communities/102264813364583686576

You can then activate beta builds at
https://play.google.com/apps/testing/com.mycelium.wallet

You are right on some points. That is why there will be a hardware based solution from Mycelium with buttons and a trusted display in the future (cooperating with the wallet).

Pushing the Software as far as possible is still an interesting exercise. If the private keys never hit flash memory it will make the life of malware and forensics much harder. (i'd love to hear opinions from actual android forensics experts on this) if breaking into Mycelium wallet is harder than simply reading a file from internal storage, malware authors will look for easier targets. so it is not malware-proof but malware-deterrent.

Also, it is kind of impossible to really erase something from modern flash memory, because of wear leveling. even if you think you deleted something the information is physically still there. if we only keep it in main memory for a short time this helps a bit.

Yes, that is certainly true. A typical Windows computer cannot be called secure.

Android phone security remains a big issue. Users have to be told where the risks are. Security advice for dedicated and non-dedicated phones would be a start.

There are some very bad nightmare scenarios, like a Google administrator or programmer slipping a Trojan module into a Google app. (They are not open-source.) We should at least think about such possibilities.

You are right in many regards. Personally I use a dedicated phone for handling my stash.

However, Exporting your private key from your phone to a piece of paper securely is not trivial.
You can do it like this if you have a printer that reads SD cards, and if you trust the printer:
http://www.youtube.com/watch?v=milxhe-RoCI

But not everyone has one of those, and will be exporting it through a computer, or using a printer that has "interesting" features. Using a device chosen passphrase makes sense in this scenario. You only have to trust your phone and yourself.

I keep seeing ideas to increase security gradually, like by keeping secrets in memory only for a short time, displaying them on screen for the user to write down manually, etc.

I don't understand the purpose. All such measures do not ultimately create security. I would call them pseudo-security. If the phone is compromised, they are all exercises in futility, because for a Trojan that has taken over the phone and is attacking the wallet it does not matter much where and for how short a key is present—it will grab the key anyway.

My proposal is to forget about such measures and concentrate only on true, unbreakable security. The user has to be told clearly where the attack vectors are and what exactly he has to do to keep the wallet secure.

One possible way to create security may be to use a separate, sealed device for the cryptographic processes and provide only one communications channel to and from that separate device that is so narrow and observable that it cannot be compromised without that being noticed. By sealed, I mean either dedicated hardware or hardware devoid of any uncontrollable communications channels, like an Android phone without SIM card, without WiFi, without third-party apps, without installing apps, etc.

Make it clear to the user that they should use a full-function wallet on a single, normally used phone only for moderate amounts and tell them clearly that, if the phone is compromised, their bitcoins can get stolen, instead of heaping ineffective measures on the app that create a false sense of security in the unsuspecting user.

The model we use is not feasible for thousands of addresses. So unlike bitcoinqt we cannot generate additional addresses for every transaction sent. Bitcoinqt's model has proven not to be that anonymous after all, but I agree that if being anonymous is important then you should do something else.
What you propose is to sweep (and I guess delete) depleted keys. This is quite dangerous as someone may send you funds to those keys.

Thanks for the feedback!


I have been thinking about something along those lines also. My objections to the suggested approach:
The passphrase has to be quite long to have any real effect
Most people are notoriously bad at choosing secure passphrases
Typing passphrases on an android device is a real pain
I am not fond of keeping the passphrase on the phone.

Instead I would suggest this:
You can export in plain-text (as now) or in encrypted form. Whenever you do an encrypted export the device chooses a strong random passphrase, encrypts the key and, exports it to JPG. The passphrase is displayed on-screen. The user writes down the passphrase, optionally on the same printout, which has some boxes for this purpose.

Also discussed here: https://bitcointalksearch.org/topic/m.2592804


You can do this right now by importing/spending/deleting, but it is a bit cumbersome. I am working on what I call Cold Storage Spending, which gives you a nice workflow that allows you to do both partial and full spending of a scanned key which is only kept in memory for a short time. It may make it into the next release.


In the next release we will have a setting called Aggregated View. When enabled (enabled by default) your balance/spending/history will be on the combination of all your keys and addresses. When disabled (segregated view) you will work on one key at a time. Combined with Cold Storage Spending you will almost have everything you describe above, except for the key-cherry-picking feature, which IMO is a little over the top for a smartphone wallet.

Right now the tx base fee is 0.0001 pr 1000 bytes of transaction size. This is the minimum for nodes to relay your transaction. If you go below that you risk that your transaction gets rejected by the network (there are enough threads in this forum complaining about stuck transactions. However, it may make sense to manually configure a higher base fee.
I have some ideas for how to automatically calculate a fee based on the user's preference (confirmation speed: fast/normal/economic): https://bitcointalksearch.org/topic/m.1817408


Agree.
We haven't really started on translation yet. Andreas is right now maintaining the german translation. We will have to set up system for managing translations. I think MultiBit uses some kind of web-thing where you can see how far various translations are  and contribute.


Splitting into (a) and (b) can be done by having two tabs (Mine/Others). This could be combined with the option to view the balance or transaction history of the selected address. © Sounds too advanced for a smartphone wallet IMO.


Agree.


Agree. You will see this starting in next version with the aggregated/segregated view.

Electrum servers will not support some of the advanced (read revenue-generating) projects we have in mind.

Proposals for MYCELIUM feature improvements (in no particular order):

(feature (3) is particularly important I think to allow having full control of your keys when spending...was mentioned before in this thread)

(1)- Settings: Allow specifying a PASSPHRASE that will be used when exporting a priv key, which will then be AES256 encrypted, preferably using an algo that makes the exported encrypted key also decodable by a standard linux library function like ssss (and say in docu which one) or other open source tools.
Of course importing such passphrase protected keys shall be possible, too.
Note that the passphrase is for protecting the exported keys, not to be confused with the PIN used to protect the app (and the priv keys) on this phone.

(2)- Include a possibility to sweep in keys (e.g. from a btc voucher) and transfer the balance of the sweeped-in key to one of the own keys, then move the sweeped-in key to list of sweeped-in keys for your records. The default label for this sweeped-in key is the date&time.

(3)- Support three ways how to spend (send) bitcoins:
EITHER send normal (input keys and change addresses will be selected automatically by the app),
OR send by scanning priv key from paper wallet w/o saving that priv key to flash memory (change addr = that key itself),
OR send from user-specified key(s): open list of the keys with checkboxes on the left and radiobuttons on the right: So user has to check all keys to be used as input for the following transaction, at least one. At the top of screen show the nb of currently checked (=selected) keys and the cumulated balance of all so-checked addresses=max amount to be spent. On the right-hand side the user must select the change address by the radio buttons (exactly one address, hence radio-buttons instead of check boxes).

(4)- Settings: Allow to specify the default tx fee (and also allow to set/modify the tx fee in the actual spend dialog)

(5)- Settings: Allow to specify language, like in bitcoin spinner. Many users prefer english instead of a bad translation, sometimes also because translation strings are longer and lead to malformated screen output because less thoroughly tested (so happened with bitcoinSpinner for me), so always good to be able to select the language of the user interface.

(6)- Separate the addressbooks:
(a) own addresses (with or w/o priv keys, like in mycelium v.0.56)
(b) addresses where I am sending funds to, i.e. my normal "list of contacts/friends/business partners/..."
(c) watch addresses (like (b), but showing the addresses' balances from the blockchain. These addresses can be grouped hierarchically in "watch-only wallets" and can be input in bulks by importing txt files containing a list of addresses separated by comma or newline.
(d) The list of sweeped-in keys (see item (2) above) can be considered a 4th kind of "addressbook".

(7)- Possibility to export (and of course also to import) the addressbooks to a txt file that is human-readable/editable.

(8)- Settings: Standard mode or Expert mode. Standard mode hides many options like "multiple keys" or "watch-only keys" or "addressbook (c)/(d)" or sweep-in key feature (2) from user interface. Only the expert mode opens up the full features. Advantage: App is easy to use for beginners/"normal" users. But for users wishing to use all features and to be able to manage all keys and have full control, it is possile with expert mode. The default, after installing the app, is the standard mode.

(9) Support of protocol for Electrum Server

No I didn't
Can recovery help? What file is holding coins and where is it located at?

Hi Tuxavant. The functionality you saw at the conference is still there, but it could be made even slicker.
Current workflow:
1. Go into Keys & Addresses and click the + button
2. Scan private key QR code from paper
3. Click and open key, which takes you to the Balance view
4. Click Send and do your spending in the send workflow
5. Go to Keys & Addresses and click the key
6. Click Delete Key, confirm, confirm

The key is no longer on your device.

Better Workflow:
1. Select Cold Storage Spending from the options menu (maybe under Advanced)
2. Scan QR code
3. Do your spending in the send workflow

The key is no longer on your device.

When? I am right now working on a hefty refactoring which changes the app's data model (in app database holding unspent outputs). This paves the way for aggregated key view, offline transaction generation (if we want that), and bandwidth reduction. Cold Storage Spending is right after that
 
Sweeping would be a natural add-on to Cold Storage Spending.

Sweeping addresses has some slightly distinct use. Imagine you receive a bit-bill and want to make sure, nobody else receives it. You would scan it, but never actively use the address after receiving what was in it this moment. An advanced option would be, to also in the future sweep what is received with it, instantly, but that would surely not be a free service.

Can you elaborate on this? Right now you can add keys to addresses and spend form it. How would you envision the perfect user interaction for physical paper wallets?

Jan, at Bitcoin 2013, you talked about the ability to sweep in amounts you kept in a QR code in your physical wallet and change directly back to the physical wallet... when do you think this feature will be more automated in mycelium?

Andreas is pondering about the Mycelium Bitcoin Wallet functionality. In BitcoinSpinner you only manage one key.