From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B916FBBC for ; 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 ; Wed, 9 Aug 2017 18:50:01 +0000 (UTC) Received: by mail-wm0-f50.google.com with SMTP id f15so3838550wmg.1 for ; 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: References: From: Colin Lacina Date: Wed, 9 Aug 2017 13:49:59 -0500 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 2 CHECKMULTISIGVERIFY ELSE 2 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
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:

IF
=C2=A0 =C2=A0 =C2=A01 <clientRecoveryPubKey>=C2=A0<serverRecoveryPubKey> 2 CHECKMULTISIGVERIFY
ELSE
=C2=A0 = =C2=A0 =C2=A02 <userWalletPubKey> <serverWalletPubKey> 2 CHECKM= ULTISIG
ENDIF

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.

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.

In the more likely event that the u= ser forgets their password=C2=A0and/or looses access to their userWalletPrivKey=C2=A0as well as loses their recovery key, they rely = on the serverRecoveryPrivKey.

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'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's client.

Meanwhile, the user's wallet client generates the serverReco= veryPrivKey.

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.

=
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.

=
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.

=
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.

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

I was thinking this may make a good informational BIP bu= t would like feedback.
--001a11440bd402f7030556568cfc--