Topic: Fruitwallet (ios wallet) discussion (Read 4887 times)
Didn't get a chance to say it before, but this looks really good! Please keep going!
cool, thanks for help!
more and more of my friends are getting interested in the idea of bitcoin. However, they do not have an android phone, so can fruitwallet also add a "what's bitcoin " introduction? Sure, we think education is an important part of any Crypto currency business.
We are improving landing page and will include educational part into it!
cool, thanks for help!
more and more of my friends are getting interested in the idea of bitcoin. However, they do not have an android phone, so can fruitwallet also add a "what's bitcoin " introduction?
cool, thanks for help!
@jbrnt, @gweedo need you help guys.
As I told we are working on secure wallet.
We have some variants how to make secure EASY-to-use mobile wallet:
1. User generates key on the client side, Key saved in device LocalStorage encrypted with 4 digit PIN. User is offered to click backup to save the key encrypted with PIN on our server.
2. User do all stated above, but he is offered to encrypt backup key one more time with additional PASSPHRASE.
If key is backup-ed:
First variant means that we can theoretically steal money, but hackers can't.
Second means that even we will hardly decrypt the key. But he will probably LOSE his key (clearing the cache) and forget PASSPHRASE.
What do you think is the best variant to do it?
As I told we are working on secure wallet.
We have some variants how to make secure EASY-to-use mobile wallet:
1. User generates key on the client side, Key saved in device LocalStorage encrypted with 4 digit PIN. User is offered to click backup to save the key encrypted with PIN on our server.
2. User do all stated above, but he is offered to encrypt backup key one more time with additional PASSPHRASE.
If key is backup-ed:
First variant means that we can theoretically steal money, but hackers can't.
Second means that even we will hardly decrypt the key. But he will probably LOSE his key (clearing the cache) and forget PASSPHRASE.
What do you think is the best variant to do it?
Don't encrypt with just a 4 digit PIN unless you going to have a huge salt that goes with it that is very random.
I don't know what you are exactly asking? The user generated key should never leave the device, in an unencrypted form, and should be stored on the phone in an encrypted form. That requires the user to unlock.
You shouldn't need to access to the key, the javascript should be able to sign the transaction and you broadcast it for them. Unless you are doing multi-sig then you have them sign the transaction and then you sign the transaction with your own key.
We can technically do all the stuff.
I mean if we store only on device, what if user lose device? or clear cookies. He will not have any way to restore it from our server. right?
So we think probably we can store key encrypted on our server as a backup.
The questions are: Do we need a backup? Crypt one time? Or crypt 2 times?
I would do a secure backup making it impossible for you to read but just hold. I would also have a way so the user can back it up without your service. So like a random string that being hashed can be regenerate their keys. Like BIP 32 https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
That will be done in main web Wallet with storage, I'm telling about a wallet, which can be set up without a PC in just few seconds.
User can't copy long numbers from phone screen and so on. But we will do BIP 32 or HD wallet as a main wallet. Mobile wallet will be for spendable needs and must be a bit more easy to use.
Makes sense?
So I think your advice is encrypting on the phone local storage + having the way to encrypt it more, like one more encryption level, and backup on the server (when we don't know the pass-phrase to decrypt).
Correct?
@jbrnt, @gweedo need you help guys.
As I told we are working on secure wallet.
We have some variants how to make secure EASY-to-use mobile wallet:
1. User generates key on the client side, Key saved in device LocalStorage encrypted with 4 digit PIN. User is offered to click backup to save the key encrypted with PIN on our server.
2. User do all stated above, but he is offered to encrypt backup key one more time with additional PASSPHRASE.
If key is backup-ed:
First variant means that we can theoretically steal money, but hackers can't.
Second means that even we will hardly decrypt the key. But he will probably LOSE his key (clearing the cache) and forget PASSPHRASE.
What do you think is the best variant to do it?
As I told we are working on secure wallet.
We have some variants how to make secure EASY-to-use mobile wallet:
1. User generates key on the client side, Key saved in device LocalStorage encrypted with 4 digit PIN. User is offered to click backup to save the key encrypted with PIN on our server.
2. User do all stated above, but he is offered to encrypt backup key one more time with additional PASSPHRASE.
If key is backup-ed:
First variant means that we can theoretically steal money, but hackers can't.
Second means that even we will hardly decrypt the key. But he will probably LOSE his key (clearing the cache) and forget PASSPHRASE.
What do you think is the best variant to do it?
Don't encrypt with just a 4 digit PIN unless you going to have a huge salt that goes with it that is very random.
I don't know what you are exactly asking? The user generated key should never leave the device, in an unencrypted form, and should be stored on the phone in an encrypted form. That requires the user to unlock.
You shouldn't need to access to the key, the javascript should be able to sign the transaction and you broadcast it for them. Unless you are doing multi-sig then you have them sign the transaction and then you sign the transaction with your own key.
We can technically do all the stuff.
I mean if we store only on device, what if user lose device? or clear cookies. He will not have any way to restore it from our server. right?
So we think probably we can store key encrypted on our server as a backup.
The questions are: Do we need a backup? Crypt one time? Or crypt 2 times?
I would do a secure backup making it impossible for you to read but just hold. I would also have a way so the user can back it up without your service. So like a random string that being hashed can be regenerate their keys. Like BIP 32 https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
@jbrnt, @gweedo need you help guys.
As I told we are working on secure wallet.
We have some variants how to make secure EASY-to-use mobile wallet:
1. User generates key on the client side, Key saved in device LocalStorage encrypted with 4 digit PIN. User is offered to click backup to save the key encrypted with PIN on our server.
2. User do all stated above, but he is offered to encrypt backup key one more time with additional PASSPHRASE.
If key is backup-ed:
First variant means that we can theoretically steal money, but hackers can't.
Second means that even we will hardly decrypt the key. But he will probably LOSE his key (clearing the cache) and forget PASSPHRASE.
What do you think is the best variant to do it?
As I told we are working on secure wallet.
We have some variants how to make secure EASY-to-use mobile wallet:
1. User generates key on the client side, Key saved in device LocalStorage encrypted with 4 digit PIN. User is offered to click backup to save the key encrypted with PIN on our server.
2. User do all stated above, but he is offered to encrypt backup key one more time with additional PASSPHRASE.
If key is backup-ed:
First variant means that we can theoretically steal money, but hackers can't.
Second means that even we will hardly decrypt the key. But he will probably LOSE his key (clearing the cache) and forget PASSPHRASE.
What do you think is the best variant to do it?
Don't encrypt with just a 4 digit PIN unless you going to have a huge salt that goes with it that is very random.
I don't know what you are exactly asking? The user generated key should never leave the device, in an unencrypted form, and should be stored on the phone in an encrypted form. That requires the user to unlock.
You shouldn't need to access to the key, the javascript should be able to sign the transaction and you broadcast it for them. Unless you are doing multi-sig then you have them sign the transaction and then you sign the transaction with your own key.
We can technically do all the stuff.
I mean if we store only on device, what if user lose device? or clear cookies. He will not have any way to restore it from our server. right?
So we think probably we can store key encrypted on our server as a backup.
The questions are: Do we need a backup? Crypt one time? Or crypt 2 times?
@jbrnt, @gweedo need you help guys.
As I told we are working on secure wallet.
We have some variants how to make secure EASY-to-use mobile wallet:
1. User generates key on the client side, Key saved in device LocalStorage encrypted with 4 digit PIN. User is offered to click backup to save the key encrypted with PIN on our server.
2. User do all stated above, but he is offered to encrypt backup key one more time with additional PASSPHRASE.
If key is backup-ed:
First variant means that we can theoretically steal money, but hackers can't.
Second means that even we will hardly decrypt the key. But he will probably LOSE his key (clearing the cache) and forget PASSPHRASE.
What do you think is the best variant to do it?
As I told we are working on secure wallet.
We have some variants how to make secure EASY-to-use mobile wallet:
1. User generates key on the client side, Key saved in device LocalStorage encrypted with 4 digit PIN. User is offered to click backup to save the key encrypted with PIN on our server.
2. User do all stated above, but he is offered to encrypt backup key one more time with additional PASSPHRASE.
If key is backup-ed:
First variant means that we can theoretically steal money, but hackers can't.
Second means that even we will hardly decrypt the key. But he will probably LOSE his key (clearing the cache) and forget PASSPHRASE.
What do you think is the best variant to do it?
jonald_fyookball, agree. Thanks for compliment.
http://www.reddit.com/r/Bitcoin/comments/226dni/we_developed_ios_btc_wallet_which_works/
I think it is a good place to discuss business model.
http://www.reddit.com/r/Bitcoin/comments/226dni/we_developed_ios_btc_wallet_which_works/
I think it is a good place to discuss business model.
Quote
So the question is: 1. Easy, light and working ios wallet, but maybe a bit risky? 2. Not too easy wallet with holding the keys, which you should not lose? 3. Or just make 2 registration ways. "Easy-to-use" mode and "Paranoid" mode?
Don't say easy or not easy to use, because it is your job as a designer or developer to make it easy and it can be easy. There are other wallets that take on the same technique and do it quite easily. https://www.bitgo.com/
jonald_fyookball, agree. Thanks for compliment.
http://www.reddit.com/r/Bitcoin/comments/226dni/we_developed_ios_btc_wallet_which_works/
I think it is a good place to discuss business model.
http://www.reddit.com/r/Bitcoin/comments/226dni/we_developed_ios_btc_wallet_which_works/
I think it is a good place to discuss business model.
legendary
Activity: 1302
Merit: 1004
Core dev leaves me neg feedback #abuse #political
I have not been keeping up with the entire conversation but it sounds like the community has some good suggestions for you... Keep up the development and let us know when the next version is ready. By the way I like the name fruit
This isn't a feature, it is safe guard against you or hack against you. This should be mantory of all wallets.
I'm just saying from technical point of view. It has to be implemented, then - feature.
But I got you
Do you mean the one that user can "get back" will be stored on our server also? Or how can they "get back from our site"?
I believe your model involves fruitwallet moving user bitcoins out to addresses that only fruitwallet controls. Gweedo is suggesting you to use 2 of 3 multisig, so fruitwallet have NO control over users' bitcoins.
I think "get back" means you provide a page (preferably an offline tool), so users can easily send those bitcoins off to another address.
Get the bitcoins back incase I lose my phone or something like that which would have one of the multi-sig public keys on it
yep, thanks! got it. It might need some time to develop, if there are quite a big percent of people who wouldn't use us without this feature, BUT will use us with this feature, then we will implement that
This isn't a feature, it is safe guard against you or hack against you. This should be mantory of all wallets.
yep, thanks! got it. It might need some time to develop, if there are quite a big percent of people who wouldn't use us without this feature, BUT will use us with this feature, then we will implement that
Do you mean the one that user can "get back" will be stored on our server also? Or how can they "get back from our site"?
I believe your model involves fruitwallet moving user bitcoins out to addresses that only fruitwallet controls. Gweedo is suggesting you to use 2 of 3 multisig, so fruitwallet have NO control over users' bitcoins.
I think "get back" means you provide a page (preferably an offline tool), so users can easily send those bitcoins off to another address.
Do 2 of 3 you guys have one. Make user write one down and keep one in local storage if they lost their phone they can use your site to get them back.
Do you mean the one that user can "get back" will be stored on our server also? Or how can they "get back from our site"?Nothing will be stored on your server but your private key. So lets walk thru this together. User Alice loss her phone, she wrote down the private key for her back up public key which is used to create the multi-sig address but only requires you to use 2 of those keys. Alice goes to your site and says she lost her phone she A) can make a new account and send the bitcoins their or B) wants to send them to another address she has. Your site should sign either one of those transactions. One she gets that signed hex, she can either sign it on your site WITH Javascript so you don't have her public key and that is easy for the user or Alice being an advance user takes that hex and goes to another wallet to sign it and broadcast it. Then she has her bitcoins and not at once did you have a control over them.
Do 2 of 3 you guys have one. Make user write one down and keep one in local storage if they lost their phone they can use your site to get them back.
Do you mean the one that user can "get back" will be stored on our server also? Or how can they "get back from our site"?btw, we made a small demo video http://youtu.be/uhZ6GdEPhys. do you guys like it?
Multi-sig is very easy and not difficult to the end user, that is why there should be no answer but to include it. I also don't think you know much about bitcoin from a technical point either from what you are saying.
Agree.
But what will happen if user loses his phone or it got stolen?
Do 2 of 3 you guys have one. Make user write one down and keep one in local storage if they lost their phone they can use your site to get them back.
I like the design but have not tested out all functionalities. However a great business model is a must to succeed!
Doing our best. Design will probably be improved as well as UX overall.
BenAnh, gweedo,
Discussed multi-sig with our CTO. He is very optimistic about this. I mean “hierarchical deterministic multisignature” (HDM)
Thank you guys for feedback.
I think to create reddit discussion about business model. Will post a link, you guys are very welcomed.
Want to see which model is more preferable.
If people want multi-sig, we will make multi-sig.
fruitwallet - the most client oriented ios wallet in the world
I like the design but have not tested out all functionalities. However a great business model is a must to succeed! Discussed multi-sig with our CTO. He is very optimistic about this. I mean “hierarchical deterministic multisignature” (HDM)
Thank you guys for feedback.
I think to create reddit discussion about business model. Will post a link, you guys are very welcomed.
Want to see which model is more preferable.
If people want multi-sig, we will make multi-sig.
fruitwallet - the most client oriented ios wallet in the world
Jump to: