diff options
| author | Nick ODell <nickodell@gmail.com> | 2017-08-09 14:14:18 -0600 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-08-09 20:14:19 +0000 |
| commit | 39074d846e66f3d984626de0c1c08df63bc25aca (patch) | |
| tree | fc6b076fbaf898900b56e1f3718936d604aa2d14 /88/9bec8bf9805c1bc50a16e7ba27d6d434a1172d | |
| parent | a8addc48fac67830685c329aa165a9eb5f9caee0 (diff) | |
| download | pi-bitcoindev-39074d846e66f3d984626de0c1c08df63bc25aca.tar.gz pi-bitcoindev-39074d846e66f3d984626de0c1c08df63bc25aca.zip | |
Re: [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options
Diffstat (limited to '88/9bec8bf9805c1bc50a16e7ba27d6d434a1172d')
| -rw-r--r-- | 88/9bec8bf9805c1bc50a16e7ba27d6d434a1172d | 319 |
1 files changed, 319 insertions, 0 deletions
diff --git a/88/9bec8bf9805c1bc50a16e7ba27d6d434a1172d b/88/9bec8bf9805c1bc50a16e7ba27d6d434a1172d new file mode 100644 index 000000000..af04e55f2 --- /dev/null +++ b/88/9bec8bf9805c1bc50a16e7ba27d6d434a1172d @@ -0,0 +1,319 @@ +Return-Path: <nickodell@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id CB332C01 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 9 Aug 2017 20:14:19 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-pg0-f54.google.com (mail-pg0-f54.google.com [74.125.83.54]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB5014FC + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 9 Aug 2017 20:14:19 +0000 (UTC) +Received: by mail-pg0-f54.google.com with SMTP id v77so32192680pgb.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 09 Aug 2017 13:14:19 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to; + bh=g0fj4Mk8FEdTD/Li0xwDxME/aiIz+YXidNCsr4cWmWQ=; + b=X63CbLqzc8wBJ5wIrto5pBPMfE9W2cnDex8mJHiib/qwlxeyH8CoPWnvJ9+SdDuhra + nVIJr2m+he6RKn3J9Nn6GMo/AUGZmgGIFnFleTUabxgyrKwLPgp0FmlnTdIlmPnEOnu1 + DLIhn3KGR0uSaNgPTXb9Hn0t3lvVsfH/iqRd4dgPZedrpaMIkYGyO/XSbUHQJWBMTYVt + Wo9LqJdey3TdErUp3kpQlZAekLts9NCHR8CkcM2jprqSut1y3UxElvk76E1Gx2m0GCXD + GlCA+JKihPT3m/klXlUOSvZiHjnQFU6owul0uBflu6eszFMNY5OUilAcnPoH7ZQVPJzQ + /zNw== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to; + bh=g0fj4Mk8FEdTD/Li0xwDxME/aiIz+YXidNCsr4cWmWQ=; + b=K1VPh5jrb/WxNJhW2u+CH42XsbmUtbSKbj2MMRBaNwjmz1Mkht2yJUm6vGgb0XwZRR + +HYpyRXHkxAn6X9w/tHaIKnZ+33VeaOPbD4wVyYyVmElYqi+YHs35J9Q/oabeNmtaFHk + Wqo8F7PVjquMk0GdxJOOgnnuUEmEP9yJz4bBOanl9bQCJc0F4ZVawFu1HyN4FGsCgK4C + 7L36kSOUQ0MFaSMr0RHVDaRz5rRIiT0/MifErvJEMEWz+F4sioiVcyT8f+T8+WolmUEQ + KYF+tpdzDvdVBBmFLo0JLdyiY3PoSMGtwHIzFo0S3W1HEfDJE3MtKfQ0yf6UUF5slLDI + XVuA== +X-Gm-Message-State: AHYfb5iKLGBOBqrHph/WT5XWkvJgfJgnB61lkAjptPoIvZPqyYMJDNkj + 77GnLh0pNi1Y5vEs+7KxB7tDl3dQuA== +X-Received: by 10.98.70.86 with SMTP id t83mr9443270pfa.219.1502309659157; + Wed, 09 Aug 2017 13:14:19 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.100.166.168 with HTTP; Wed, 9 Aug 2017 13:14:18 -0700 (PDT) +In-Reply-To: <CAJJsNHvDbPpo+31bN0eYtgARnZe_ZeoVz7=bm9HuAjUM0ztKBA@mail.gmail.com> +References: <CAJJsNHsiAH3Wc_Fp-8f=5EBg8-jNH8rtEW5+u+PEC7JU+SdCGQ@mail.gmail.com> + <CAJJsNHv_iPNnGgqqogoxGEk+5ipoELfPAnMM0obWUpTjWRZJRQ@mail.gmail.com> + <CAJJsNHvKR+ieYaFYw_KeCmJjWTzBYH9mSSFwtOdoyYB-kA+fLQ@mail.gmail.com> + <CAJJsNHuz17GQkKWsKc0sOJfueEyyJkPM0ErbSNB_A=9Qq9tgTQ@mail.gmail.com> + <CAJJsNHsdcYc7WiLuBSYPfoOvjG-v10zFL1d7_ROxx1HYx-nzHA@mail.gmail.com> + <CAJJsNHuMa9WoWm0_MZ+dDVRM6UxhOA7eNWqNX=NAVw6V7Nb0jg@mail.gmail.com> + <CAJJsNHsn=x-EzAWvRH171uM_8hmX9=_zYrn6yyn_mMP3DQGbbw@mail.gmail.com> + <CAJJsNHvXpeMgxLZZ6JDFX859xnYC30Xvs24=G8-pmE+GUk9prw@mail.gmail.com> + <CAJJsNHu+Rg7-mHY7mBVL6trKAbTfyq_44KjiQjRkU99_DUyCiQ@mail.gmail.com> + <CAJJsNHueWeocmYN7tQZ111wi6GyAf81OBpR0gaqJaq6N0RokSQ@mail.gmail.com> + <CAJJsNHvaeOdhia9bd1b-FTobUvYPsdryRo1U7fPdf=J6Xng1Rw@mail.gmail.com> + <CAJJsNHuWf42Pzz39oH1F+NHxPoeMdoXqT8-5F8B5OLye1o8sFQ@mail.gmail.com> + <CAJJsNHum5CVA7HOL26__WjFAQV09mAxfvDJ3o1Yu3BYNydzdvw@mail.gmail.com> + <CAJJsNHs_aDmuqKpetceM+t_+jQLs8m0hFgtvhCJVvNLBrn3VjQ@mail.gmail.com> + <CAJJsNHsT0VBufwkr4Lk-yRndeKDhchrp5g-UDv-vhcyjpi3-LA@mail.gmail.com> + <CAJJsNHt46qBoihBBojt4Fu7S7Ryrqi-1HpXGiX4_nVMDQBq1oQ@mail.gmail.com> + <CAJJsNHtCDCaW3ZtnNutL9q-PY4b5+eS-zcyfgT1B23gKH+127A@mail.gmail.com> + <CAJJsNHuU3NXGjZ+afUQ_Ct_3y5V7JgZQzemc9SQUGmGjrm8wfQ@mail.gmail.com> + <CAJJsNHt08PbYvtcVbCPw383-93r-NuCV_UPjGZ+moHime4dzFw@mail.gmail.com> + <CAJJsNHvtJ3eUNgpe8apLDoC_UOmk+0ezLiTXkhdG2tndTx=WBA@mail.gmail.com> + <CAJJsNHu+8+42R0jMfLbNZ7K8c0kQR3Tex+xiPH6WE+w_f+ORPQ@mail.gmail.com> + <CAJJsNHubV--c5xJQrrF6F5K5gQ2gexy3x-7pL_Gn7Oe6TpiMbw@mail.gmail.com> + <CAJJsNHvEPWSdquKrOt5kGRFFmLJ3yq2YfxEuQUC9upmKYV4oeg@mail.gmail.com> + <CAJJsNHsMBz06oo-miAkqUC4VenYq1+o08pi=fgDsnaq9B_+KSA@mail.gmail.com> + <CAJJsNHun0bf-TKxOr-WVJ1Tj3zt40OZOZAtzxRhD_+ise_+7=g@mail.gmail.com> + <CAJJsNHvurUUkysWzjbxcXhdaUbL-CRPiBBABFd2HuFD14wZLkQ@mail.gmail.com> + <CAJJsNHsib5VRs4R1N6C6ZhynAGhJ+QxW3d2LbzojEFnwddyyhw@mail.gmail.com> + <CAJJsNHt01LuXqD+V=++6fp_VyW7TZ_1OzrsxZ7brBiqUKHcdng@mail.gmail.com> + <CAJJsNHuZ_iMdeV0jZ618jO7osvUk97uV9Wae9NA_dgRQT=E5uQ@mail.gmail.com> + <CAJJsNHtZ8bEZ-5zfpjzhoxfzaOM1RuZvRx6J+Pcr=r0=zZd=Kg@mail.gmail.com> + <CAJJsNHspUanL7Y1E9RB_4G54Fs3RUy1uqUw8aUq3XYY6os_5ww@mail.gmail.com> + <CAJJsNHtumDA8js_kaagwDHxLy9iF7UXwb5n9yX5cLvwNDDEMaw@mail.gmail.com> + <CAJJsNHss2bW0DqYkvf5W4CMG3gaWFcT4oqXyzT4y93FveR6k4A@mail.gmail.com> + <CAJJsNHuHA_rksFEip9r=hKuHoM9Bag2AmFYr=2miJKzOWJC5dQ@mail.gmail.com> + <CAJJsNHv1QtpDvw_CZKhqryCxD21jtL+MQbZgqG-0HxzBbsnvPw@mail.gmail.com> + <CAJJsNHtNMQGiJwarobHKBau7o_hEnSMKSznKkbfa8y4e4BUA8Q@mail.gmail.com> + <CAJJsNHsX9Za=+8LYTK8mnq8XtuMrL03U2LAXHy15qv+XEKupZA@mail.gmail.com> + <CAJJsNHuyty=i6Mxu_sreVBkqmgDKtp3050=Hh1qy8Hfs8yV2sw@mail.gmail.com> + <CAJJsNHvNRzd0ZCv3QX9cR=JV8eUHF0z2QWdx9CK1v42iz2fOyA@mail.gmail.com> + <CAJJsNHsYjFj-g1RBoRMoTrfjLStCQ8SQrE7ZcM569yW0mxb1qQ@mail.gmail.com> + <CAJJsNHvVEydafdqx7ZwG9XmdNLZzbewVpAMfnvS=ZXNzV1fQYQ@mail.gmail.com> + <CAJJsNHtEqzEg83k_s4Kg0YiJ3tWfCPOTPmnH0D-YiKZ6K5oGGg@mail.gmail.com> + <CAJJsNHt2WydZewhrH5XZ-mpUMGBYvfke1H6F2cORpORv=LxShQ@mail.gmail.com> + <CAJJsNHsCQXkp2uDTMTRJ=2ZVTcUXEPCPNusncACFtGoov5cOzw@mail.gmail.com> + <CAJJsNHusmafTVS3xTyT5hR3ZjLkQ99A9qQK33e05BRdTF7+xhQ@mail.gmail.com> + <CAJJsNHsp8oW=C-yzO5qiF9imZf-5EO+pYUJU6yHZz1wF=nevUA@mail.gmail.com> + <CAJJsNHvOMxE2sBa4TKaazMsRH4OJaN=eS0JDRO81=J1OzGLkcg@mail.gmail.com> + <CAJJsNHu3EZx9c2x99gwSEUNBCEa3SirteUx8+MqWcU_ShjLDRA@mail.gmail.com> + <CAJJsNHsBYgmTmGeqUnvjnomO10m_TXjgt5xS8rROcV2aF=PPsQ@mail.gmail.com> + <CAJJsNHsKSE9ftorgZ4J7YLwz5rMpYq-7WpEtk61JEtxJfneKVQ@mail.gmail.com> + <CAJJsNHuTY+ckfvujru2K4vsOkfHyp1kYMJQAF0rmSeHhv3HdaA@mail.gmail.com> + <CAJJsNHuYfMWGjkw1_RPA5-a6p_EVsv3b4gussi9y9Mb8+WsR_A@mail.gmail.com> + <CAJJsNHv=cEnxg=yTCiDjWRedpBLuXmAyk-mGgQbHMDxFqoiiBw@mail.gmail.com> + <CAJJsNHs90da2u+ufLcVoqyYQ_pkAr55=gL_ZY0mAGCoDmyqMbQ@mail.gmail.com> + <CAJJsNHtni20bBUjLd_KOLnVxnZ4_AdDumLCkWbiU4v-cgXfJcA@mail.gmail.com> + <CAJJsNHtVQ_hSQho2yd_4n8g+sQ5mCZjrG-SALcm1Vrbb3_1oVw@mail.gmail.com> + <CAJJsNHus+SGAfh6SR9uY_VjgSiSsqtsH0=V-ecM8pm=whwSp0g@mail.gmail.com> + <CAJJsNHvruYORGrd--nQayYW28k=F-A9PiP9O25w_1pvR2ABvcw@mail.gmail.com> + <CAJJsNHsTYta-e0S_VZNMHNrEYnfy57U1W_bbzvkS3gQ=qVt75g@mail.gmail.com> + <CAJJsNHv+TyGj=Mg3t2DS5YAW5WMdjckjFZA5KTO=JDtHB9iNCg@mail.gmail.com> + <CAJJsNHukqjvTv-2G0jM8D6c2Bmt0o_uW6cd=GXvJHOzmSRg+BA@mail.gmail.com> + <CAJJsNHv8mnT_GUcHmZy=6=_k1PxBSpfMSTtrz9UbERzhVwSbgw@mail.gmail.com> + <CAJJsNHtb8Zed+5jZKx3oBNP7EMV-OPbuJD9mPjryRuroM=2bnA@mail.gmail.com> + <CAJJsNHsWjUeCUp9jHwzEMMuN9jT2CNocpLyJRJKzDvY5Q_VAaQ@mail.gmail.com> + <CAJJsNHuLfeB_oP+98jteLyr_q=_pdWkJP1+h4fgUBoeG3shBXQ@mail.gmail.com> + <CAJJsNHuM-k1-MKHw-TcP5RFJz7bwg=YuLvjXKzunYcUK7wYhjg@mail.gmail.com> + <CAJJsNHvEttaWfk9FQXA34WskxqU5sTyzvK_a56voWVOb7vtbcQ@mail.gmail.com> + <CAJJsNHukHECFiMj2PFKOMSQmkT1f8Y=N20_9bx2p_3n0ahJKmQ@mail.gmail.com> + <CAJJsNHtZWH4Cy-kpCRrbLeA339uoC3mL0Be2MBNdbW8PqjboJg@mail.gmail.com> + <CAJJsNHvDbPpo+31bN0eYtgARnZe_ZeoVz7=bm9HuAjUM0ztKBA@mail.gmail.com> +From: Nick ODell <nickodell@gmail.com> +Date: Wed, 9 Aug 2017 14:14:18 -0600 +Message-ID: <CANN4kmfXy-Lkuai-VyPOG_EQ3ybV4t-3GTixHLzSanKJHe419Q@mail.gmail.com> +To: Colin Lacina <notdatoneguy@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="94eb2c0b82a493ac43055657b94e" +X-Mailman-Approved-At: Wed, 09 Aug 2017 20:15:31 +0000 +Subject: Re: [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets + Using P2SH for Recovery Options +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 09 Aug 2017 20:14:19 -0000 + +--94eb2c0b82a493ac43055657b94e +Content-Type: text/plain; charset="UTF-8" + +Colin, + +1) This is a good start for a BIP, but it's missing details. For example, +the nonce is encrypted by the server. What key is it encrypted with? +Clarifying ambiguities like this can sometimes reveal weaknesses that you +wouldn't otherwise think of. + +2) What kind of recovery questions are asked? If it's something like "What +was the name of your first pet?" then what prevents the server from +stealing the wallet by trying a dictionary of the most common pet names? Is +there a mitigation to this, besides picking cryptographically secure +identifiers for my pets? + +--Nick + +On Wed, Aug 9, 2017 at 12:49 PM, Colin Lacina via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> 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. +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> + +--94eb2c0b82a493ac43055657b94e +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Colin,</div><div><br></div><div>1) This is a good sta= +rt for a BIP, but it's missing details. For example, the nonce is encry= +pted by the server. What key is it encrypted with? Clarifying ambiguities l= +ike this can sometimes reveal weaknesses that you wouldn't otherwise th= +ink of.</div><div><br></div><div>2) What kind of recovery questions are ask= +ed? If it's something like "What was the name of your first pet?&q= +uot; then what prevents the server from stealing the wallet by trying a dic= +tionary of the most common pet names? Is there a mitigation to this, beside= +s picking cryptographically secure identifiers for my pets?</div><div><br><= +/div><div>--Nick</div></div><div class=3D"gmail_extra"><br><div class=3D"gm= +ail_quote">On Wed, Aug 9, 2017 at 12:49 PM, Colin Lacina via bitcoin-dev <s= +pan dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org= +" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wr= +ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= +-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">I believe I have c= +ome up with a structure that allows for trustless use of hybrid wallets tha= +t 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:<div dir=3D"auto"><br></div><di= +v dir=3D"auto">IF</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A01 <clientRe= +coveryPubKey>=C2=A0<span style=3D"font-family:sans-serif"><<wbr>serve= +rRecoveryPubKey> 2 CHECKMULTISIGVERIFY</span></div><div dir=3D"auto"><sp= +an style=3D"font-family:sans-serif">ELSE</span></div><div dir=3D"auto"><spa= +n style=3D"font-family:sans-serif">=C2=A0 =C2=A0 =C2=A02 <userWalletPubK= +ey> <serverWalletPubKey> 2 CHECKMULTISIG</span></div><div dir=3D"a= +uto"><span style=3D"font-family:sans-serif">ENDIF</span></div><div dir=3D"a= +uto"><span style=3D"font-family:sans-serif"><br></span></div><div dir=3D"au= +to"><span style=3D"font-family:sans-serif">A typical transaction using this= + would involve a user signing a TX with their userWalletPrivKey, authentica= +ting with the server, possibly with 2FA using a phone or something like Aut= +hy or Google Authenticator. After authentication, the server signs with the= +ir serverWalletPrivKey.</span></div><div dir=3D"auto"><span style=3D"font-f= +amily:sans-serif"><br></span></div><div dir=3D"auto"><span style=3D"font-fa= +mily:sans-serif">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 wa= +llet storage.</span></div><div dir=3D"auto"><span style=3D"font-family:sans= +-serif"><br></span></div><div dir=3D"auto"><span style=3D"font-family:sans-= +serif">In the more likely event that the user forgets their password=C2=A0<= +/span><span style=3D"font-family:sans-serif">and/or looses access to their = +userWalletPrivKey=C2=A0</span><span style=3D"font-family:sans-serif">as wel= +l as loses their recovery key, they rely on the serverRecoveryPrivKey.</spa= +n></div><div dir=3D"auto"><span style=3D"font-family:sans-serif"><br></span= +></div><div dir=3D"auto"><span style=3D"font-family:sans-serif">When the us= +er 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 reco= +very 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 ident= +ify the recovery wallet. The server then creates a 1025 bit nonce, encrypts= + it, stores it, and transmits it to the user's client.</span></div><div= + dir=3D"auto"><span style=3D"font-family:sans-serif"><br></span></div><div = +dir=3D"auto"><span style=3D"font-family:sans-serif">Meanwhile, the user'= +;s wallet client generates the serverRecoveryPrivKey.</span></div><div dir= +=3D"auto"><span style=3D"font-family:sans-serif"><br></span></div><div dir= +=3D"auto"><span style=3D"font-family:sans-serif">Once the client has both t= +he 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.</span></div><div dir=3D"auto"><span s= +tyle=3D"font-family:sans-serif"><br></span></div><div dir=3D"auto"><span st= +yle=3D"font-family:sans-serif">Finally, the already encrypted key is encryp= +ted again for transmission to the server. The server decrypts it, then renc= +rypts it for long term storage.</span></div><div dir=3D"auto"><span style= +=3D"font-family:sans-serif"><br></span></div><div dir=3D"auto"><span style= +=3D"font-family:sans-serif">When the user needs to resort to using this opt= +ion, they 256 bit hash their information to build their recovery identifier= +. The server may, optionally, request e-mail and or SMS confirmation that u= +ser is actually attempting the recovery.</span></div><div dir=3D"auto"><spa= +n style=3D"font-family:sans-serif"><br></span></div><div dir=3D"auto"><span= + style=3D"font-family:sans-serif">Next, the server decrypts the saved nonce= +, as well as the first layer of encryption on the serverRecoveryPrivKey, th= +en 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.</span></div><div dir=3D"auto"><span style=3D"fon= +t-family:sans-serif"><br></span></div><div dir=3D"auto"><span style=3D"font= +-family:sans-serif">After all of that the user can decrypt the airbitzServe= +rRecoveryPrivKey and use it to send a transaction anywhere they choose.</sp= +an></div><div dir=3D"auto"><span style=3D"font-family:sans-serif"><br></spa= +n></div><div dir=3D"auto"><span style=3D"font-family:sans-serif">I was thin= +king this may make a good informational BIP but would like feedback.</span>= +</div></div> +<br>______________________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +<br></blockquote></div><br></div> + +--94eb2c0b82a493ac43055657b94e-- + |