[bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options

* [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options
       [not found]                                                                                                                                       ` <CAJJsNHtZWH4Cy-kpCRrbLeA339uoC3mL0Be2MBNdbW8PqjboJg@mail.gmail.com>
@ 2017-08-09 18:49                                                                                                                                         ` Colin Lacina
  2017-08-09 19:35                                                                                                                                           ` Jonas Schnelli
  2017-08-09 20:14                                                                                                                                           ` Nick ODell
  0 siblings, 2 replies; 3+ messages in thread
From: Colin Lacina @ 2017-08-09 18:49 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]

I believe I have come up with a structure that allows for trustless use of
hybrid wallets that would allow for someone to use a hybrid wallet without
having to trust it while still allowing for emergency recovery of funds in
the case of a lost wallet. It would run off of this TX script:

IF
     1 <clientRecoveryPubKey> <serverRecoveryPubKey> 2 CHECKMULTISIGVERIFY
ELSE
     2 <userWalletPubKey> <serverWalletPubKey> 2 CHECKMULTISIG
ENDIF

A typical transaction using this would involve a user signing a TX with
their userWalletPrivKey, authenticating with the server, possibly with 2FA
using a phone or something like Authy or Google Authenticator. After
authentication, the server signs with their serverWalletPrivKey.

In case the server goes rogue and starts refusing to sign, the user can use
their userRecoveryPrivKey to send the funds anywhere they choose. Because
if this, the userRecoveryPrivKey is best suited to cold wallet storage.

In the more likely event that the user forgets their password and/or looses
access to their userWalletPrivKey as well as loses their recovery key, they
rely on the serverRecoveryPrivKey.

When the user first sets up their wallet, they answer some basic identity
information, set up a recovery password, and/or set up recovery questions
and answers. This information is explicitly NOT sent to serve with the
exception of recovery questions (although the answers remain with the user,
never seeing the server). What is sent to the server is it's 256 bit hash
used to identify the recovery wallet. The server then creates a 1025 bit
nonce, encrypts it, stores it, and transmits it to the user's client.

Meanwhile, the user's wallet client generates the serverRecoveryPrivKey.

Once the client has both the serverRecoveryPrivKey, and the nonce, it uses
SHA512 on the combination of the identity questions and answers, the
recovery password (if used), the recovery questions and answers, and the
nonce. It uses the resulting hash to encrypt the serverRecoveryPrivKey.

Finally, the already encrypted key is encrypted again for transmission to
the server. The server decrypts it, then rencrypts it for long term storage.

When the user needs to resort to using this option, they 256 bit hash their
information to build their recovery identifier. The server may, optionally,
request e-mail and or SMS confirmation that user is actually attempting the
recovery.

Next, the server decrypts the saved nonce, as well as the first layer of
encryption on the serverRecoveryPrivKey, then encrypts both for
transmission to the user's client. Then the client removes the transmission
encryption, calculates the 512 bit hash that was used to originally encrypt
the serverRecoveryPrivKey by using the provided information and the nonce.

After all of that the user can decrypt the airbitzServerRecoveryPrivKey and
use it to send a transaction anywhere they choose.

I was thinking this may make a good informational BIP but would like
feedback.

[-- Attachment #2: Type: text/html, Size: 4915 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread