path: root/cb/b871334f83c28847a87779832089292a5b3bdb

Return-Path: <ethankosakovsky@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 41EB6C07FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Mar 2020 15:10:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 2E9E886216
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Mar 2020 15:10:57 +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 2boEyEt1MryM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Mar 2020 15:10:55 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
 [185.70.40.130])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id C834B86199
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 21 Mar 2020 15:10:54 +0000 (UTC)
Date: Sat, 21 Mar 2020 15:10:48 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=default; t=1584803451;
 bh=vRz1zcYvjRBJfqexSvzrKeVsUaklWXI3PjPLuaewjX0=;
 h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
 b=Y+keH2Qh73MNHSghSvjEryoemYSEKWoaTJqEFrDPxjMjX+LBnhiHFeydTyHo+aPcD
 Yo3TfOmfVzJ8WTaTGPBm/1W89piqyKQmsCsbimV3r58VTw+y+P1ZlQ6FigxfNWjZDZ
 uzPlvZc5itehyWyVo6kJgvzVCctG29C5Rw+62UI0=
To: Christopher Allen <ChristopherA@lifewithalacrity.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Ethan Kosakovsky <ethankosakovsky@protonmail.com>
Reply-To: Ethan Kosakovsky <ethankosakovsky@protonmail.com>
Message-ID: <g5SKiolnI0CG11Iq7Pj4IGhMkqmtpB5qXP5hpbEafVpfDbM3sdCvQuvgzlkFLOI3di6KIvwJZjeO7tB6PFpWlvZmhRxTXO3aqyuYD8Qge0s=@protonmail.com>
In-Reply-To: <CACrqygBm+mprR3Efo2pdMhprHJ3xQCBeKuZBF15QmDpcg93-5Q@mail.gmail.com>
References: <_CC9MLKCy5rmooAmR91_34tQxgDiXDJCdY4W6_X6xqDJUiAEuaWBVi8iBaFipx2KGt5_mf5XqFKMfoNgemTPCMgraWt5CVRifUM5iMolxto=@protonmail.com>
 <20200320200253.GC13916@coinkite.com>
 <CACrqygBm+mprR3Efo2pdMhprHJ3xQCBeKuZBF15QmDpcg93-5Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 21 Mar 2020 16:46:37 +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 15:10:57 -0000

Chris,

Thank you for taking the time to share your thoughts. I agree there are wid=
e considerations surrounding key handling and storage. I dont think my prop=
osal interferes with that perspective any more than BIP32 itself would. How=
 keys are handled is a separate matter than the cryptography of key derivat=
ion and trying to get back to the one single backup that is future proof.

My proposal is not concerned with how the initial master key/seed is genera=
ted, just that we have one. My proposal is concerned with how to avoid havi=
ng to generate more master keys because of the wide adoption of standards t=
hat impose restrictions (like BIP39); or the fragmented methods of initiali=
zation various wallets; as well as the instances where sharing the BIP39 se=
ed with multiple wallets is undesirable due to security concerns (for examp=
le hot and offline wallet); or just plain incompatible standards.

If we were to start everything from scratch, we would obviously do things d=
ifferently. However, there are already millions of wallets created using ex=
isting standards. It's just not possible to reset sadly.

> 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 o=
r
> other devices that don't understand xprv and will only allow import of ne=
w
> seeds words. This gets even more complicated if the seed words are not th=
e
> standard BIP-39 set (which BTW, are not an ideal set of words, the
> selection of the SLIP-39 words is much better).

I am proposing two separate things.

  - that we use fully hardened paths to derive keys in order to derive entr=
opy.
  - that a BIP44 like derivation path can be used to describe what the entr=
opy is intended for

    For example we use the prefix 83696968 (ASCII seed in decimal) `m/83696=
968'/type'/index'`
      - `type` defines how the entropy will be used
        `0` means use 128 bits of the entropy as input to BIP39, producing =
a 12 word BIP39 mnemonic
        `4` means use 256 bits of the entropy as the secret exponent to cre=
ate a compressed WIF (for use as hdseed in Bitcoin Core)

    In this way, we can neatly define the specific use-cases of the entropy=
 maintaining some order.

      - `index` is the key index so we can generate multiple instances of t=
his type of entropy

To answer your question about whether to one-way-transform the resulting k.=
 In practice, k is already safe because it was derived from a fully hardene=
d path which protects the parent tree. However, the purpose here semantical=
ly is to be entropy. But k is not entropy, it's a private key on that deriv=
ation path. Neither are we exporting and xprv. We want entropy to seed the =
derivation of something else specified by the `type`. For that reason I con=
sider it important to transform k by way of a hash or hmac. Using HMAC over=
 hash is a decision based on an abundance of caution to ensure ward off unw=
anted side effects should k be used for a dual purpose, including as a nonc=
e hash(k), where undesirable and unforeseen interactions could occur.

> Though possibly pragmatic, this approach would be a hack =E2=80=93 starti=
ng with some raw entropy, convert this to an entropy seed, then to words, t=
hen 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 am not proposing the nesting, although nothing would prohibit it, I'm jus=
t proposing one master root key from which all child keychains can be deriv=
ed and overcome the incompatibilities and impracticalities detailed.

> Let me know if you'd like to participate in the discussions (currently ei=
ther Github issues or a Signal group for the group)

Sure! What's the URL of the Github?

Ethan


=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Saturday, March 21, 2020 2:46 AM, Christopher Allen via bitcoin-dev <bit=
coin-dev@lists.linuxfoundation.org> wrote:

> 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 ins=
ignificant. Blockchain Commons has published procedures that we consider th=
e current best practices for cold storage in a free book at=C2=A0http://bit=
.ly/SmartCustodyBookV101 and in github at=C2=A0https://github.com/Blockchai=
nCommons/smartcustodybook. It currently requires a couple of hours and $200=
 or more of materials (home safe, 2 ledgers, titanium blanks, etc.) to safe=
ly product (significantly less time and money than Glacier Protocol).=C2=
=A0
>
> Presumably, people are not going to go to this level of protection for to=
o 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=C2=A0 on an offline device with no-WiFi or Bluetooth, an air-ga=
pped mobile phone in airplane mode, or another dedicated device (for instan=
ce the SafeKey device if open source was an option). You would use this dev=
ice to create and restore seeds, convert seeds from BIP-39 to SLIP-39, deri=
ve 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 co=
uld 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 wall=
et 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 o=
peration (still not convinced this was a good decision).=C2=A0
>
> 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 selectio=
n of the SLIP-39 words is much better).=C2=A0
>
> Though possibly pragmatic, this approach would be a hack =E2=80=93 starti=
ng with some raw entropy, convert this to an entropy seed, then to words, t=
hen 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 ent=
ropy seed (not specifically the bip39 words derived from that but also as d=
erived 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 Bitco=
in wallet including root seed:
>
> {
> =C2=A0 "birthdate": 1584725088,
> =C2=A0 "label": "Testnet Single Signature",
> =C2=A0 "entropy": "b3b17e8f425bf7b96d68b67867cdc816",
> =C2=A0 "walletName": "DEFAULT_EBaiuGgZQS_StandUp",
> =C2=A0 "descriptor": "wpkh([6955c2cb/84'/1'/0']tprv8giCxdrRRrKfQkXTJ4q2PN=
ZBsPL7HiTXXteajiG8wqAGpLVsHJfN1EwwKM8F8x1Cuk8p6vh1KrKBCuZtZdDtL6Sc2CB1ou8sY=
iGSf6hcujv/0/*)",
> =C2=A0 "blockheight": 1
> }
>
> Alternatively, FullyNoded 2 can also restore a wallets without the full s=
eed, so for instance, if this QR restore was missing the entropy field, onl=
y derived child xprv from the descriptor could be used, so no other account=
s could be created but new addresses as children of the xprv could be creat=
ed.
>
> 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 SLI=
P-39 shards, or Lightning words, and back. We are also looking at using thi=
s 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 o=
r hierarchies of keys for their unique needs.
>
> Blockchain Common's doesn't have a full architecture for this yet as we a=
re 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 eit=
her Github issues or a Signal group for the group)
>
> =E2=80=94 Christopher Allen