search

bitpay / wallet

Bitpay Wallet (formerly Copay) is a secure Bitcoin and other crypto currencies wallet platform for both desktop and mobile devices.
http://bitpay.com/wallet
MIT License
3.82k stars 1.74k forks source link

Enhance Backups #2722

Closed matiu closed 9 years ago

matiu commented 9 years ago

Redo: https://github.com/bitpay/copay/issues/2721

See: https://github.com/bitpay/copay/issues/2698 and https://github.com/bitpay/copay/issues/2546

also: See: https://github.com/cryptocoinjs/bip38

dabura667 commented 9 years ago
  1. one 12 word BIP39 phrase to re-generate your master private key
  2. when creating the wallet, it gets a 32 bit identifier for the wallet. This can be shown in 3 word BIP39-esque encoding.
  3. User can use the same 12 word phrase for multiple wallets (not recommended tho), but if they include the extra option of "restore previous wallet" then include the 3 word fingerprint. (background: The fingerprint is sent to BWS, BWS sends challenge to sign, copay signs with their master private key or specific key derived below that master. BWS checks to make sure it's one of the xpubs in the wallet that matches the fingerprint and that the signature checks. If so, it sends the other xpubs to the client.)

I wrote all this out... but does BWS hold all xpubs of each wallet?... I forgot...

dabura667 commented 9 years ago

The problem with this type of method is it relies on the server holding everyone's xpubs and never going down... so it's not really decentralized and in actuality the backup relying on the server means it's not truly a backup in the sense that it would be all the info needed to recover.

Another point to consider is maybe having each member of a wallet have a flag showing whether or not they created a backup. (Whether that be phrase + fingerprint or an encrypted full-backup) so you can know whether or not the other members are responsibly backing up their wallets too. (vital for x of x wallets where one key lost means loss of all funds)

matiu commented 9 years ago

The problem with this type of method is it relies on the server holding

everyone's xpubs and never going down... so it's not really decentralized and in actuality the backup relying on the server means it's not truly a backup in the sense that it would be all the info needed to recover.

Agree. The backup should not relay on the server. IMO, having m backups (in a m-n wallet) should ALWAYS give you access to the funds.

Another point to consider is maybe having each member of a wallet have a flag showing whether or not they created a backup. (Whether that be phrase

  • fingerprint or an encrypted full-backup) so you can know whether or not the other members are responsibly backing up their wallets too. (vital for x of x wallets where one key lost means loss of all funds)

We had that on Copay ~v0.3 :) Exactly as you mentioned, but it added to much friction to wallet creation. Specially in n>=3 wallets. To be fair, in a 3-5 wallet, for example, you can restore the wallet with 3 backups, you dont need to wait until the 5 copayers have make a backup.

— Reply to this email directly or view it on GitHub https://github.com/bitpay/copay/issues/2722#issuecomment-102392394.

Matías Alejo Garcia @ematiu Roads? Where we're going, we don't need roads!

dabura667 commented 9 years ago

I think that these security type things should be sliding scales.

The wallet provider (whether open source or not) should ask themself: "Is my software doing everything in it's power to inform the user of their options and what they entail?"

I don't think putting a roadblock in the way until m of the n create a 100% backup.

However, that doesn't mean the software shouldn't try to ascertain whether or not the current wallet is at risk, and if it is, inform the user.

Especially considering that multiple humans are participatig with varying levels of what is acceptable risk / knowledge of what is a risk in the first place.

I think the wallet creator should be required to select a dropdown asking the required security of the wallet. Two taps just to get a jist of how the user will be using the wallet.

If the user selects "Fort Knox" or "High Security needs" then the wallet will give constant notifications to wallet members and periodically test members if they can produce their backups and if they can provide the password to restore that backup.

If the user selects medium security, Constantly show an indicator (maybe a red light until m backups confirmed, then green light) that will inform users without a backup that they must backup to upgrade the wallet to greenlight status.

Low security is current as is. No real annoying messages, maybe leave the receiving screen thing.

Also, while a server reliant backup is not optimal, There isn't really any offline tool for copay members to use to move funds when bws is down... So for non-technical users, current backups kind of are really server-dependant.

Perhaps adding the server dependant fingerprint method will increase the number of backups by decreasing friction... But then maybe it will encourage people who would have made decentralized backups to make the less secure backups instead (which is not good)

What are your thoughts?

dabura667 commented 9 years ago

The problem with this type of method is it relies on the server holding everyone's xpubs

Rethinking this aspect; I think it's ok to have a dependency on someone/something... as to begin with, you are relying on at least m-1 of n-1 other people to be able to move funds.

The ability granted to you by having the xpubs of everyone else is the ability to create transaction proposals... which relies on BWS anyways. (for non-dev normal users)

So unless you create some sort of offline tool for Copay users to manually copy-paste and send each other raw partially signed transactions, then dependency on BWS is not increased in any real capacity.

maybe you could even reduce the reliance on BWS by instead allowing "recoupling" to occur between users in a wallet.

ie. I could just grab the xpubs from BWS by signing a challenge, but in case BWS is down and we have to use the offline tool (assuming there is one someday) I could scan a QR code on a fellow participant's wallet which contained a challenge, then sign it and show them a QR code with the signed challenge. Once verified, the fellow participant displays a QR code with the encrypted xpubs of the wallet, encrypted by ECIES with the person trying to restore's xpub pubkey (or some arbitrarily chosen path below the main xpub.)

tl;dr being multi-sig means you are ALWAYS going to be relying on someone to "backup" (in the sense of "ability to move funds") whether it be BWS or your other members of the wallet.

dabura667 commented 9 years ago

I have come up with a method I think is good:

  1. When a new wallet is created/someone joins, a BIP39 phrase is generated, they are asked if they want to add additional password (for pbkdf2 salt) and it sends the xpub to bws.
  2. bws stores a table in it's DB with the hash(xpub) as the key field and 'walletid:copayid' as the second field.

When a user wants to restore the backup:

  1. The user inputs their BIP39 phrase and password (if they have one)
  2. The device checks the checksum, generates the xpub and sends a request to BWS for a restore.
  3. BWS responds to the request with a challenge and an amount of time. ie. {'challenge':'abcdefabcdefabcdef', 'timelimit':15000} for 15 seconds.
  4. The device then signs the challenge concatenated with the xpub and sends the signature and the xpub over.
  5. BWS checks the checksum of the xpub, then hashes it and checks to see if it's in the table.
    • If it is not in the table, respond with an error notifying that that their BIP39 phrase, or the password might be wrong.
    • If it is in the table with only 1 entry and the signature verifies, respond with the xpubs of the whole wallet and the copayer names / wallet id / everything needed. Encrypt using the user's xpub before doing this (just in case someone uses http instead of https.)
    • If it is in the table with multiple entries and the signature verifies, respond with a list of walletname:copayername pairs and let the user choose which wallet to restore. The user will then send back the choice with signature sign(challenge + walletname + copayername) Then bws will respond with the xpubs of the whole wallet and the copayer names / wallet id / everything needed. Encrypt using the user's xpub before doing this (just in case someone uses http instead of https.)

Also, if Copay servers are down and someone, for some reason, decides not to put up another bws ever (I know unlikely, as its open source... but still) This functionality could be done between devices in an advanced feature.

  1. Wallet X with copayers A B and C.
  2. C lost his phone. Reinstalls Copay, bws is down.
  3. B opens up advanced options on Wallet X
  4. B selects "repair copayer"
  5. B shows a QR code with a challenge in it.
  6. C selects "Import wallet from copayer" in wallet creation.
  7. C inputs the BIP39 phrase and optional password, scans the QR, the device creates sign(challenge + xpub) signature and then shows a QR on C's device with xpub and signature.
  8. B taps "Scan Reply" and scans the QR code on C's screen
  9. If B's device can verify that the xpub is indeed a member of the wallet and that the signature is valid, then B's device generates a QR code with all xpubs, and names of copayers, and name of wallet, and everything necessary. (This can be split into multiple QR codes for scanning, or be made into an encrypted json text that the user can send to C in a chat app or something and C can copy paste it in.

In addition with #2863, this will allow for simple backups (just writing down a BIP39 phrase) without relying on the server at all.

The "if all bwses just completely stopped and no one made another one" theory of "what-if" would be completely solved by this.

dabura667 commented 9 years ago

Oh, and 1of1 can just restore using BIP39 by themselves. No need for server or friend.

This would require restricting the number of "wallets" on a BWS that is 1of1 and uses the same xpub to only allow 1. (Could I generate hundreds of 1of1 wallets on BWS with the same xprv right now? ie. the only thing different would be their wallet names?)

isocolsky commented 9 years ago

done!