Thanks for the feedback!
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.
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://bitcointalk.org/index.php?topic=140103.msg2592804#msg2592804(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.
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.
(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).
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.
(4)- Settings: Allow to specify the default tx fee (and also allow to set/modify the tx fee in the actual spend dialog)
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://bitcointalk.org/index.php?topic=166302.msg1817408#msg1817408(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.
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.
(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".
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.
(7)- Possibility to export (and of course also to import) the addressbooks to a txt file that is human-readable/editable.
Agree.
(
- 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.
Agree. You will see this starting in next version with the aggregated/segregated view.
(9) Support of protocol for Electrum Server
Electrum servers will not support some of the advanced (read revenue-generating) projects we have in mind.
Show Posts
