path: root/19/d969a3acb29a540e273de81890c2b8a6929db7

Return-Path: <notdatoneguy@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B916FBBC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Aug 2017 18:50:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B78746F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  9 Aug 2017 18:50:01 +0000 (UTC)
Received: by mail-wm0-f50.google.com with SMTP id f15so3838550wmg.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 09 Aug 2017 11:50:01 -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=ozkOys6yY6ZvZ5wJKzxEjZVauXLERNAvWYEA7DumPg8=;
	b=fOQIvg1JCLQvL1CWzKjEVlZ2os7nc998nheqBvkG6pG+eNeUWLQBuwizsjdgaiC6ju
	vezp2LszprMxHXprbzz6AHuhIchK7zzCag1gq4hoZqyrkdpsXjEtD78ptSdnaOyzzM3L
	U4kSw8FDIdwXvLlc3pAJulqrp8asAdx/qAOG1rmFkralhgRIi2ihRFh3abdfirB9U3jQ
	rGvB8ZlCfmpbMzhoP9RCIuRr6Grr8u/IWct1674W7W5G1Rr+Y6hJajlfivhm7A9MkPBv
	jUd3gQmWxRQb9k1kC+6Z/a+Ii6y7PUPJHkmtnrdPzCHCR7VRSFRWM+eXCTsZaM57sZM5
	FioQ==
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=ozkOys6yY6ZvZ5wJKzxEjZVauXLERNAvWYEA7DumPg8=;
	b=GHTK206V62HHKjigY3eTyCr6UbkXLs3XI0LHwpuueph4xVAijKtdDWDUv2UJ9EUrIT
	LOZxtHaQKABkegQRATvmtAdz/GvCXXYtpParSyPEPx70Z/NBeb5eH2QtXspJ1P1aCNaK
	K3CEyZspE/WfzFT5ZIuX7q9Jmxgahc8z1SGwGke499ogZJynruGtLFAmAKK+8Dcx5Ak+
	3EgBMugjUNuwhQVMLjX2osyOPozbOtBmJmZmJqqBmqrKcK0Aswe6njv40UwwO08OkB5B
	z+hiWt8MFQjvTLFUsTFb3ZlPnPy5mD5yjJc79kPvkSXKWWEgqcLpWRBchVU0B0UEU2C/
	SI9A==
X-Gm-Message-State: AHYfb5hAfWFs8tWJRHzbgcIT8syI0dddc2EZPAbphPmRO2KBgKAS6SEd
	QpVT5bdAqRHlFmrjC12K/ubap1Nh/A==
X-Received: by 10.28.173.6 with SMTP id w6mr5965628wme.12.1502304599732; Wed,
	09 Aug 2017 11:49:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.170.77 with HTTP; Wed, 9 Aug 2017 11:49:59 -0700 (PDT)
Received: by 10.223.170.77 with HTTP; Wed, 9 Aug 2017 11:49:59 -0700 (PDT)
In-Reply-To: <CAJJsNHtZWH4Cy-kpCRrbLeA339uoC3mL0Be2MBNdbW8PqjboJg@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>
From: Colin Lacina <notdatoneguy@gmail.com>
Date: Wed, 9 Aug 2017 13:49:59 -0500
Message-ID: <CAJJsNHvDbPpo+31bN0eYtgARnZe_ZeoVz7=bm9HuAjUM0ztKBA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="001a11440bd402f7030556568cfc"
X-Mailman-Approved-At: Wed, 09 Aug 2017 19:02:11 +0000
Subject: [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 18:50:01 -0000

--001a11440bd402f7030556568cfc
Content-Type: text/plain; charset="UTF-8"

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.

--001a11440bd402f7030556568cfc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">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 hybr=
id wallet without having to trust it while still allowing for emergency rec=
overy of funds in the case of a lost wallet. It would run off of this TX sc=
ript:<div dir=3D"auto"><br></div><div dir=3D"auto">IF</div><div dir=3D"auto=
">=C2=A0 =C2=A0 =C2=A01 &lt;clientRecoveryPubKey&gt;=C2=A0<span style=3D"fo=
nt-family:sans-serif">&lt;serverRecoveryPubKey&gt; 2 CHECKMULTISIGVERIFY</s=
pan></div><div dir=3D"auto"><span style=3D"font-family:sans-serif">ELSE</sp=
an></div><div dir=3D"auto"><span style=3D"font-family:sans-serif">=C2=A0 =
=C2=A0 =C2=A02 &lt;userWalletPubKey&gt; &lt;serverWalletPubKey&gt; 2 CHECKM=
ULTISIG</span></div><div dir=3D"auto"><span style=3D"font-family:sans-serif=
">ENDIF</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"=
>A typical transaction using this would involve a user signing a TX with th=
eir userWalletPrivKey, authenticating with the server, possibly with 2FA us=
ing a phone or something like Authy or Google Authenticator. After authenti=
cation, the server signs with their serverWalletPrivKey.</span></div><div d=
ir=3D"auto"><span style=3D"font-family:sans-serif"><br></span></div><div di=
r=3D"auto"><span style=3D"font-family:sans-serif">In case the server goes r=
ogue and starts refusing to sign, the user can use their userRecoveryPrivKe=
y to send the funds anywhere they choose. Because if this, the userRecovery=
PrivKey is best suited to cold wallet 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 u=
ser forgets their password=C2=A0</span><span style=3D"font-family:sans-seri=
f">and/or looses access to their userWalletPrivKey=C2=A0</span><span style=
=3D"font-family:sans-serif">as well as loses their recovery key, they rely =
on 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"f=
ont-family:sans-serif">When the user first sets up their wallet, they answe=
r some basic identity information, set up a recovery password, and/or set u=
p recovery questions and answers. This information is explicitly NOT sent t=
o serve with the exception of recovery questions (although the answers rema=
in with the user, never seeing the server). What is sent to the server is i=
t&#39;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 u=
ser&#39;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:s=
ans-serif">Meanwhile, the user&#39;s wallet client generates the serverReco=
veryPrivKey.</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-s=
erif">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 no=
nce. It uses the resulting hash to encrypt 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">Finally, the=
 already encrypted key is encrypted again for transmission to the server. T=
he server decrypts it, then rencrypts 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 need=
s to resort to using this option, they 256 bit hash their information to bu=
ild their recovery identifier. The server may, optionally, request e-mail a=
nd or SMS confirmation that user is actually attempting the recovery.</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">Next, the se=
rver decrypts the saved nonce, as well as the first layer of encryption on =
the serverRecoveryPrivKey, then encrypts both for transmission to the user&=
#39;s client. Then the client removes the transmission encryption, calculat=
es the 512 bit hash that was used to originally encrypt the serverRecoveryP=
rivKey by using the provided information and the nonce.</span></div><div di=
r=3D"auto"><span style=3D"font-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 airbitzServerRecoveryPrivKey and use it to send a transact=
ion anywhere they choose.</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">I was thinking this may make a good informational BIP bu=
t would like feedback.</span></div></div>

--001a11440bd402f7030556568cfc--