path: root/20/26f6bc4a522eac715eb8a826262f33ae1eb8e7

Return-Path: <christophera@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 196CAC07FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Mar 2020 01:46:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 120F3876C7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Mar 2020 01:46:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Ts_wduIgcZff
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Mar 2020 01:46:57 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ua1-f67.google.com (mail-ua1-f67.google.com
 [209.85.222.67])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id B3A23876C3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Mar 2020 01:46:57 +0000 (UTC)
Received: by mail-ua1-f67.google.com with SMTP id r47so2942082uad.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 20 Mar 2020 18:46:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=lifewithalacrity-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=XvJ9pwoqJb7Y1v2vMP4qHrRlBtlqbD1FRE+xHrHDwuA=;
 b=kL8Bb9JmVpLQ2+OwLMHnoIe9BVanZ2qtUCaha6JRwyndFthY4BzLca+KQJD2joHgs+
 PE3PgKFvQlWg/k0QY77jfrQCgN1aA62/lazW29J2MP5bHLtp06FdxpM++kTM1AlTVf+j
 wnosuaj3VYCCFyNiiRYMqJd2esqP3SUYbRTEAnnVdC4lv22Jq7+hMwXNAjPgENaDqlde
 i+Op2texMiMZ5LOPE96yyxYriBWldP9WIE206Ydx5ESAp3dOzCJun2RY2rTxiFXZkthT
 Tq64BYzbjFokGzTH4svnkIpjEiy1d18RQz+Ndd0Ga9koOKvrK6+iERJQlHxIYCnYitB3
 qBwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=XvJ9pwoqJb7Y1v2vMP4qHrRlBtlqbD1FRE+xHrHDwuA=;
 b=FauxkjFCovG9RkO+8rSq7Gp9ezsHUnSzYaQeHe6Xf0iFm30FDa8SwZPBRPKtFfkGr/
 0wGA9X0FPr4205aaiL8U53ldjuMudl6QGSCJJ6DECZ3C9L1a7AS06+zVkozG+3BE19D3
 Xi7abtgmhzZj7T8Lkk2Rmb8ittIEdrEIRwgoWdZMYxXBAvx2CsFN1BXw2SWZ9OTZS1Ad
 W8QHvqtAer9j+gg32chcSPUcrnX4SYFJ1rX7sqGt+oBIRIeciCtJs8J1ORHekAD+GzD0
 Pv08dHIuXD6RdqCQJVOMs6wdVLilW/zmi83qJgDDJVVQahqipzgJzydqqaAtC0qUeGkN
 Cu6g==
X-Gm-Message-State: ANhLgQ3P5YCrxjEhCnsYjdolZT7Apg/zD6e8gRVnq1Rxoi1I72wMYA1b
 TiUetN/Mim7aJAnbBlc9jR4RI0HcZz+D77Ye1kk0L+iJ6hE=
X-Google-Smtp-Source: ADFU+vuHZKByDkZ8xT9mu7GS3MHAtUujGVEXRLCtukzQ5KB4pwEHA5DqU36jN9DoO7aOsxzrWH/OC0XKrQOFfKTBHzs=
X-Received: by 2002:a9f:3b02:: with SMTP id i2mr7471760uah.33.1584755216214;
 Fri, 20 Mar 2020 18:46:56 -0700 (PDT)
MIME-Version: 1.0
References: <_CC9MLKCy5rmooAmR91_34tQxgDiXDJCdY4W6_X6xqDJUiAEuaWBVi8iBaFipx2KGt5_mf5XqFKMfoNgemTPCMgraWt5CVRifUM5iMolxto=@protonmail.com>
 <20200320200253.GC13916@coinkite.com>
In-Reply-To: <20200320200253.GC13916@coinkite.com>
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Fri, 20 Mar 2020 18:46:19 -0700
Message-ID: <CACrqygBm+mprR3Efo2pdMhprHJ3xQCBeKuZBF15QmDpcg93-5Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b7f08d05a1539317"
X-Mailman-Approved-At: Sat, 21 Mar 2020 01:53:13 +0000
Subject: Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sat, 21 Mar 2020 01:46:59 -0000

--000000000000b7f08d05a1539317
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree with the problem statement in this proposal, but not the proposed
solution.

The challenge of safely securing a seed for a single signature is not
insignificant. Blockchain Commons has published procedures that we consider
the current best practices for cold storage in a free book at
http://bit.ly/SmartCustodyBookV101 and in github at
https://github.com/BlockchainCommons/smartcustodybook. It currently
requires a couple of hours and $200 or more of materials (home safe, 2
ledgers, titanium blanks, etc.) to safely product (significantly less time
and money than Glacier Protocol).

Presumably, people are not going to go to this level of protection for too
many keys, thus there needs to be methods to leverage the root seeds that
are properly protected.

Currently Blockchain Commons is working on standards for airgap solutions
for storing and signing from offline keys. Scenarios include using Shamir
and SLIP-39  on an offline device with no-WiFi or Bluetooth, an air-gapped
mobile phone in airplane mode, or another dedicated device (for instance
the SafeKey device if open source was an option). You would use this device
to create and restore seeds, convert seeds from BIP-39 to SLIP-39, derive
HD keys, and then use QR code from the device to transfer the generated
child keys for use by different apps. In some cases, this offline device
could also read QR transactions and sign them. We have working prototypes
of this today.

This technique works fine for online Bitcoin apps that accept child keys in
the form of xprv (or equivalents) such as those our FullyNoded2 iOS wallet
supports, but the problem for other wallets is that you can't go from an
xprv back to a seed =E2=80=94 the xprv creation is a one-way hmac-sha512 op=
eration
(still not convinced this was a good decision).

What I think Ethan is proposing is the ability to turn any child derived
xprv key into a new set valid seed words that could be used by a wallet or
other devices that don't understand xprv and will only allow import of new
seeds words. This gets even more complicated if the seed words are not the
standard BIP-39 set (which BTW, are not an ideal set of words, the
selection of the SLIP-39 words is much better).

Though possibly pragmatic, this approach would be a hack =E2=80=93 starting=
 with
some raw entropy, convert this to an entropy seed, then to words, then hmac
to xprv, then derive child keys, then convert that child key to a new
entropy seed, then hmac to xprv, and then derive child keys again, etc.

I'd really prefer to start with finding standards ways to protect the
entropy seed (not specifically the bip39 words derived from that but also
as derived roots for WebAuthN/FIDO, GPG, Signal/Session, etc.) that can be
then be used to create other hierarchies of keys using airgap solutions.

For instance, here is what FullyNoded 2 currently uses to restore a Bitcoin
wallet including root seed:

{
  "birthdate": 1584725088,
  "label": "Testnet Single Signature",
  "entropy": "b3b17e8f425bf7b96d68b67867cdc816",
  "walletName": "DEFAULT_EBaiuGgZQS_StandUp",
  "descriptor":
"wpkh([6955c2cb/84'/1'/0']tprv8giCxdrRRrKfQkXTJ4q2PNZBsPL7HiTXXteajiG8wqAGp=
LVsHJfN1EwwKM8F8x1Cuk8p6vh1KrKBCuZtZdDtL6Sc2CB1ou8sYiGSf6hcujv/0/*)",
  "blockheight": 1
}

Alternatively, FullyNoded 2 can also restore a wallets without the full
seed, so for instance, if this QR restore was missing the entropy field,
only derived child xprv from the descriptor could be used, so no other
accounts could be created but new addresses as children of the xprv could
be created.

The advantage of of an entropy seed storage centered technique is that I
can convert that entropy seed into either BIP39 words, or any number of
SLIP-39 shards, or Lightning words, and back. We are also looking at using
this with the VSS that underlies Schnorr Musig. We can talk other secure
tool makers on how to use this raw entropy for other purposes to create
chains or hierarchies of keys for their unique needs.

Blockchain Common's doesn't have a full architecture for this yet as we are
working on our POC and are seeking suggestions from other wallet vendors
(in particular lightning and non-bitcoin secure services) on requirements.
Let me know if you'd like to participate in the discussions (currently
either Github issues or a Signal group for the group)

=E2=80=94 Christopher Allen

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

<div dir=3D"ltr">I agree with the problem statement in this proposal, but n=
ot the proposed solution.<div><br></div><div>The challenge of safely securi=
ng a seed for a single signature is not insignificant. Blockchain Commons h=
as published procedures that we consider the current best practices for col=
d storage in a free book at=C2=A0<a href=3D"http://bit.ly/SmartCustodyBookV=
101">http://bit.ly/SmartCustodyBookV101</a> and in github at=C2=A0<a href=
=3D"https://github.com/BlockchainCommons/smartcustodybook">https://github.c=
om/BlockchainCommons/smartcustodybook</a>. It currently requires a couple o=
f hours and $200 or more of materials (home safe, 2 ledgers, titanium blank=
s, etc.) to safely product (significantly less time and money than Glacier =
Protocol).=C2=A0</div><div><br></div><div>Presumably, people are not going =
to go to this level of protection for too many keys, thus there needs to be=
 methods to leverage the root seeds that are properly protected.</div><div>=
<br></div><div>Currently Blockchain Commons is working on standards for air=
gap solutions for storing and signing from offline keys. Scenarios include =
using Shamir and SLIP-39=C2=A0 on an offline device with no-WiFi or Bluetoo=
th, an air-gapped mobile phone in airplane mode, or another dedicated devic=
e (for instance the SafeKey device if open source was an option). You would=
 use this device to create and restore seeds, convert seeds from BIP-39 to =
SLIP-39, derive HD keys, and then use QR code from the device to transfer t=
he generated child keys for use by different apps. In some cases, this offl=
ine device could also read QR transactions and sign them. We have working p=
rototypes of this today.</div><div><br></div><div>This technique works fine=
 for online Bitcoin apps that accept child keys in the form of xprv (or equ=
ivalents) such as those our FullyNoded2 iOS wallet supports, but the proble=
m for other wallets is that you can&#39;t go from an xprv back to a seed =
=E2=80=94 the xprv creation is a one-way hmac-sha512 operation (still not c=
onvinced this was a good decision).=C2=A0</div><div><br></div><div>What I t=
hink Ethan is proposing is the ability to turn any child derived xprv key i=
nto a new set valid seed words that could be used by a wallet or other devi=
ces that don&#39;t understand xprv and will only allow import of new seeds =
words. This gets even more complicated if the seed words are not the standa=
rd BIP-39 set (which BTW, are not an ideal set of words, the selection of t=
he SLIP-39 words is much better).=C2=A0</div><div><br></div><div>Though pos=
sibly pragmatic, this approach would be a hack =E2=80=93 starting with some=
 raw entropy, convert this to an entropy seed, then to words, then hmac to =
xprv, then derive child keys, then convert that child key to a new entropy =
seed, then hmac to xprv, and then derive child keys again, etc.</div><div><=
br></div><div>I&#39;d really prefer to start with finding standards ways to=
 protect the entropy seed (not specifically the bip39 words derived from th=
at but also as derived roots for WebAuthN/FIDO, GPG, Signal/Session, etc.) =
that can be then be used to create other hierarchies of keys using airgap s=
olutions.</div><div><br></div><div>For instance, here is what FullyNoded 2 =
currently uses to restore a Bitcoin wallet including root seed:</div><div><=
br></div><div>{<br>=C2=A0 &quot;birthdate&quot;: 1584725088,<br>=C2=A0 &quo=
t;label&quot;: &quot;Testnet Single Signature&quot;,<br>=C2=A0 &quot;entrop=
y&quot;: &quot;b3b17e8f425bf7b96d68b67867cdc816&quot;,<br>=C2=A0 &quot;wall=
etName&quot;: &quot;DEFAULT_EBaiuGgZQS_StandUp&quot;,<br>=C2=A0 &quot;descr=
iptor&quot;: &quot;wpkh([6955c2cb/84&#39;/1&#39;/0&#39;]tprv8giCxdrRRrKfQkX=
TJ4q2PNZBsPL7HiTXXteajiG8wqAGpLVsHJfN1EwwKM8F8x1Cuk8p6vh1KrKBCuZtZdDtL6Sc2C=
B1ou8sYiGSf6hcujv/0/*)&quot;,<br>=C2=A0 &quot;blockheight&quot;: 1<br>}<br>=
</div><div><br></div><div>Alternatively, FullyNoded 2 can also restore a wa=
llets without the full seed, so for instance, if this QR restore was missin=
g the entropy field, only derived child xprv from the descriptor could be u=
sed, so no other accounts could be created but new addresses as children of=
 the xprv could be created.</div><div><br></div><div>The advantage of of an=
 entropy seed storage centered technique is that I can convert that entropy=
 seed into either BIP39 words, or any number of SLIP-39 shards, or Lightnin=
g words, and back. We are also looking at using this with the VSS that unde=
rlies Schnorr Musig. We can talk other secure tool makers on how to use thi=
s raw entropy for other purposes to create chains or hierarchies of keys fo=
r their unique needs.</div><div><br></div><div>Blockchain Common&#39;s does=
n&#39;t have a full architecture for this yet as we are working on our POC =
and are seeking suggestions from other wallet vendors (in particular lightn=
ing and non-bitcoin secure services) on requirements. Let me know if you&#3=
9;d like to participate in the discussions (currently either Github issues =
or a Signal group for the group)</div><div><br></div><div>=E2=80=94 Christo=
pher Allen</div><div><br></div><div><br></div><div><br></div></div>

--000000000000b7f08d05a1539317--