path: root/5a/35ca8d55cef0d9a9253050c2e3e89cd10e6a45

Return-Path: <craigraw@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5EDD6C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Jun 2021 08:23:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 41BB9403A3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Jun 2021 08:23:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id UJ3i42ht945P
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Jun 2021 08:23:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com
 [IPv6:2607:f8b0:4864:20::d32])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 8090540322
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Jun 2021 08:23:00 +0000 (UTC)
Received: by mail-io1-xd32.google.com with SMTP id s19so2303612ioc.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Jun 2021 01:23:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=iUmi/QJd5Otk4rXyHioF0HqB+W4bCjy5OpuJN9JyBG8=;
 b=c0C5pjCXj1t1mCtOGzZcspzoshjg9ZRCIdN2Z8nal53C/tglQYc+ncd+xt+uEteJkW
 rOrtM2v1bAIMD4KP3uHy/7gvuRJogBJh7s93fjT0HhQDsypa7h7790YDA1pX9IXis8c4
 rrbdkhSoRnhp30BErXBkXFXBmjF5YGJCNfA/ubfs6xnk2LSTnbFk8yHHtYeHUPZ+xaXp
 alp9bkQGFPxNiOQ+1Bzhhx2Pgk3Wgfb2wvzoOnmjGNcij1U+opcy6icLJ0B9BL/dXaJU
 cfAkSBE31Ustf48BFUx8GWQhh4ciJtIYldDm4D6ZKCz2ocntRRLOEiBN4JCQvzjFP82L
 r/2Q==
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;
 bh=iUmi/QJd5Otk4rXyHioF0HqB+W4bCjy5OpuJN9JyBG8=;
 b=gEc0SHf8+aFOgQoobkRjU5KULlGjfrJ8ll3j9aTsgN0fgb5/ONRzEJjzC4gYqrqLMG
 CEpf0Kp2GccDlkLjRp3ftTjqWWAMX10fW6Z4o+u4rmLAJ0/ria6VnYrajB9oNb9uTHy1
 DXM/U0ee3/FAroJ9PEQMid6PWFDLZBUnadtChZDZMzHfZKD139Y2qkBDdTtBhs98ibTC
 KloA72QiDUt7hKkNzyZiS1P5aeD7vYsgXO2EJ98Pqp20W1WNrzq8KP4d8eiIaa/FM5g4
 SqK2sngEBZZDazqMEmwQiKPCQU2fbPnjAjei9T4/R9tCcFpu/8ZM3F5BLOvbGrvaJnTB
 ID+Q==
X-Gm-Message-State: AOAM533SCwsXqDVKMj+HaEDUyJTXt+OHPWXe3JmaGRPKKzgtO3RDhs0e
 DEC2swY8EE7c3IzSJc0mY+O3YsP15IPYdeCF4dc=
X-Google-Smtp-Source: ABdhPJyWEdSFSm/OhWadkbHph/IsJIaPtuw/FUdFTtSNLV6Q3SbNOyswtKS3cW5GlT1f4O3VEOHwA3NVdt6YCeHd/kM=
X-Received: by 2002:a02:b786:: with SMTP id f6mr7536157jam.65.1624436579546;
 Wed, 23 Jun 2021 01:22:59 -0700 (PDT)
MIME-Version: 1.0
References: <6bb9110e-b726-0470-96f0-2d68eadf23a3@achow101.com>
In-Reply-To: <6bb9110e-b726-0470-96f0-2d68eadf23a3@achow101.com>
From: Craig Raw <craigraw@gmail.com>
Date: Wed, 23 Jun 2021 10:22:48 +0200
Message-ID: <CAPR5oBPtBq3UMQ84j42pFMzqz3fw2uoL52u+QcQCft1dvZk3Xg@mail.gmail.com>
To: Andrew Chow <achow101-lists@achow101.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000048bae005c56a9d7b"
X-Mailman-Approved-At: Wed, 23 Jun 2021 08:30:14 +0000
Subject: Re: [bitcoin-dev] Derivation Paths for Single Key Taproot Scripts
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: Wed, 23 Jun 2021 08:23:02 -0000

--00000000000048bae005c56a9d7b
Content-Type: text/plain; charset="UTF-8"

+1

While other derivation schemes have been proposed, the simple "purpose per
script type" based approach started with BIP44 is very widely used and has
done much to improve recoverability of wallets. The products and
understanding around this approach are now relatively mature, while backing
up an output descriptor (in addition to seed words) is still not well
understood or supported. Early standardisation around a known derivation
path will ease implementation for wallets implementing Taproot and help
prevent confusion (as we have had over the still draft BIP48). I also agree
we don't need (and should avoid) a new version for extended key
serialization.

Craig

On Wed, Jun 23, 2021 at 3:17 AM Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi All,
>
> I would like to propose a simple derivation path scheme for keys to be
> used in single key Taproot scripts. This is based on BIP 44 so it is
> basically identical to BIPs 49 and 84. Like with those BIPs, the actual
> value to be used in the purpose level will be set to the BIP number,
> once assigned.
>
> Note that the keys derived in this method should be for the Taproot
> internal key, which should then be tweaked with the hash of itself as
> recommended by BIP 341. The keys derived at this path should not be used
> directly as the Taproot output pubkey. Additionally, this BIP does not
> specify new version bytes for extended key serialization because, with
> the advent of descriptors, I think that is unnecessary. In fact, this
> BIP feels somewhat unnecessary to me, but it seems like it will be
> needed for now in order to drive adoption and implementation of Taproot
> into software and hardware wallets.
>
> The text can be viewed below, with the rendered text available at
>
> https://github.com/achow101/bips/blob/taproot-bip44/bip-taproot-bip44.mediawiki
>
> Andrew Chow
>
> ---
>
> <pre>
>    BIP: bip-taproot-bip44
>    Layer: Applications
>    Title: Derivation scheme for P2TR based accounts
>    Author: Andrew Chow <andrew@achow101.com>
>    Comments-Summary: No comments yet.
>    Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-taproot-bip44
>    Status: Draft
>    Type: Informational
>    Created: 2021-06-22
>    License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> This document suggests a derivation scheme for HD wallets whose keys are
> involved in single key
> P2TR ([[bip-0341.mediawiki|BIP 341]]) outputs as the Taproot internal key.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ==Motivation==
>
> With the usage of single key P2TR transactions, it is useful to have a
> common derivation scheme so
> that HD wallets that only have a backup of the HD seed can be likely to
> recover single key Taproot
> outputs. Although there are now solutions which obviate the need for
> fixed derivation paths for
> specific script types, many software wallets and hardware signers still
> use seed backups which
> lack derivation path and script information. Thus we largely use the
> same approach used in BIPs
> [[bip-0049.mediawiki|49]] and [[bip-0084.mediawiki|84]] for ease of
> implementation.
>
> ==Specifications==
>
> This BIP defines the two needed steps to derive multiple deterministic
> addresses based on a
> [[bip-0032.mediawiki|BIP 32]] master private key.
>
> ===Public key derivation===
>
> To derive a public key from the root account, this BIP uses the same
> account-structure as
> defined in BIPs [[bip-0044.mediawiki|44]], [[bip-0049.mediawiki|49]],
> and [[bip-0084.mediawiki|84]],
> but with a different purpose value for the script type.
>
> <pre>
> m / purpose' / coin_type' / account' / change / address_index
> </pre>
>
> For the <tt>purpose</tt>-path level it uses <tt><BIPNUMBER>'</tt>.
> The rest of the levels are used as defined in BIPs 44, 49, and 84.
>
> ===Address derivation===
>
> To derive the output key used in the P2TR script from the derived public
> key, we use the method
> recommended in
> [[bip-0341.mediawiki#constructing-and-spending-taproot-outputs|BIP 341]]:
>
> <pre>
> internal_key:       lift_x(derived_key)
> 32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G
> </pre>
>
> In a transaction, the scripts and witnesses are as defined in
> [[bip-0341.mediawiki#specification|BIP 341]]:
>
> <pre>
> witness:      <signature>
> scriptSig:    (empty)
> scriptPubKey: 1 <32_byte_output_key>
>                (0x5120{32_byte_output_key})
> </pre>
>
> ==Backwards Compatibility==
>
> This BIP is not backwards compatible by design.
> An incompatible wallet will not discover these accounts at all and the
> user will notice that
> something is wrong.
>
> However this BIP uses the same method used in BIPs 44, 49, and 84, so it
> should not be difficult
> to implement.
>
> ==Test vectors==
>
> TBD
>
> ==Reference==
>
> * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
> * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
> * [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic
> Wallets]]
> * [[bip-0049.mediawiki|BIP49 - Derivation scheme for
> P2WPKH-nested-in-P2SH based accounts]]
> * [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based
> accounts]]
> * [[bip-0341.mediawiki|BIP341 - Taproot: SegWit version 1 spending rules]]
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">+1<br><div><br></div><div>While other derivation schemes h=
ave been proposed, the simple &quot;purpose per script type&quot; based app=
roach started with BIP44 is very widely used and has done much to improve r=
ecoverability of wallets. The products and understanding around this approa=
ch are now relatively mature, while backing up an output descriptor (in add=
ition to seed words) is still not well understood=C2=A0or supported. Early =
standardisation around a known derivation path will ease implementation for=
 wallets implementing Taproot and help prevent confusion (as we have had ov=
er the still draft BIP48). I also agree we don&#39;t need (and should avoid=
) a new version for extended key serialization.</div><div><br></div><div>Cr=
aig=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Jun 23, 2021 at 3:17 AM Andrew Chow via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">Hi All,<br>
<br>
I would like to propose a simple derivation path scheme for keys to be<br>
used in single key Taproot scripts. This is based on BIP 44 so it is<br>
basically identical to BIPs 49 and 84. Like with those BIPs, the actual<br>
value to be used in the purpose level will be set to the BIP number,<br>
once assigned.<br>
<br>
Note that the keys derived in this method should be for the Taproot<br>
internal key, which should then be tweaked with the hash of itself as<br>
recommended by BIP 341. The keys derived at this path should not be used<br=
>
directly as the Taproot output pubkey. Additionally, this BIP does not<br>
specify new version bytes for extended key serialization because, with<br>
the advent of descriptors, I think that is unnecessary. In fact, this<br>
BIP feels somewhat unnecessary to me, but it seems like it will be<br>
needed for now in order to drive adoption and implementation of Taproot<br>
into software and hardware wallets.<br>
<br>
The text can be viewed below, with the rendered text available at<br>
<a href=3D"https://github.com/achow101/bips/blob/taproot-bip44/bip-taproot-=
bip44.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/ac=
how101/bips/blob/taproot-bip44/bip-taproot-bip44.mediawiki</a><br>
<br>
Andrew Chow<br>
<br>
---<br>
<br>
&lt;pre&gt;<br>
=C2=A0=C2=A0 BIP: bip-taproot-bip44<br>
=C2=A0=C2=A0 Layer: Applications<br>
=C2=A0=C2=A0 Title: Derivation scheme for P2TR based accounts<br>
=C2=A0=C2=A0 Author: Andrew Chow &lt;<a href=3D"mailto:andrew@achow101.com"=
 target=3D"_blank">andrew@achow101.com</a>&gt;<br>
=C2=A0=C2=A0 Comments-Summary: No comments yet.<br>
=C2=A0=C2=A0 Comments-URI:<br>
<a href=3D"https://github.com/bitcoin/bips/wiki/Comments:BIP-taproot-bip44"=
 rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/wiki/=
Comments:BIP-taproot-bip44</a><br>
=C2=A0=C2=A0 Status: Draft<br>
=C2=A0=C2=A0 Type: Informational<br>
=C2=A0=C2=A0 Created: 2021-06-22<br>
=C2=A0=C2=A0 License: BSD-2-Clause<br>
&lt;/pre&gt;<br>
<br>
=3D=3DAbstract=3D=3D<br>
<br>
This document suggests a derivation scheme for HD wallets whose keys are<br=
>
involved in single key<br>
P2TR ([[bip-0341.mediawiki|BIP 341]]) outputs as the Taproot internal key.<=
br>
<br>
=3D=3D=3DCopyright=3D=3D=3D<br>
<br>
This BIP is licensed under the 2-clause BSD license.<br>
<br>
=3D=3DMotivation=3D=3D<br>
<br>
With the usage of single key P2TR transactions, it is useful to have a<br>
common derivation scheme so<br>
that HD wallets that only have a backup of the HD seed can be likely to<br>
recover single key Taproot<br>
outputs. Although there are now solutions which obviate the need for<br>
fixed derivation paths for<br>
specific script types, many software wallets and hardware signers still<br>
use seed backups which<br>
lack derivation path and script information. Thus we largely use the<br>
same approach used in BIPs<br>
[[bip-0049.mediawiki|49]] and [[bip-0084.mediawiki|84]] for ease of<br>
implementation.<br>
<br>
=3D=3DSpecifications=3D=3D<br>
<br>
This BIP defines the two needed steps to derive multiple deterministic<br>
addresses based on a<br>
[[bip-0032.mediawiki|BIP 32]] master private key.<br>
<br>
=3D=3D=3DPublic key derivation=3D=3D=3D<br>
<br>
To derive a public key from the root account, this BIP uses the same<br>
account-structure as<br>
defined in BIPs [[bip-0044.mediawiki|44]], [[bip-0049.mediawiki|49]],<br>
and [[bip-0084.mediawiki|84]],<br>
but with a different purpose value for the script type.<br>
<br>
&lt;pre&gt;<br>
m / purpose&#39; / coin_type&#39; / account&#39; / change / address_index<b=
r>
&lt;/pre&gt;<br>
<br>
For the &lt;tt&gt;purpose&lt;/tt&gt;-path level it uses &lt;tt&gt;&lt;BIPNU=
MBER&gt;&#39;&lt;/tt&gt;.<br>
The rest of the levels are used as defined in BIPs 44, 49, and 84.<br>
<br>
=3D=3D=3DAddress derivation=3D=3D=3D<br>
<br>
To derive the output key used in the P2TR script from the derived public<br=
>
key, we use the method<br>
recommended in<br>
[[bip-0341.mediawiki#constructing-and-spending-taproot-outputs|BIP 341]]:<b=
r>
<br>
&lt;pre&gt;<br>
internal_key:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lift_x(derived_key)<br>
32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G<=
br>
&lt;/pre&gt;<br>
<br>
In a transaction, the scripts and witnesses are as defined in<br>
[[bip-0341.mediawiki#specification|BIP 341]]:<br>
<br>
&lt;pre&gt;<br>
witness:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &lt;signature&gt;<br>
scriptSig:=C2=A0=C2=A0=C2=A0 (empty)<br>
scriptPubKey: 1 &lt;32_byte_output_key&gt;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 (0x5120{32_byte_output_key})<br>
&lt;/pre&gt;<br>
<br>
=3D=3DBackwards Compatibility=3D=3D<br>
<br>
This BIP is not backwards compatible by design.<br>
An incompatible wallet will not discover these accounts at all and the<br>
user will notice that<br>
something is wrong.<br>
<br>
However this BIP uses the same method used in BIPs 44, 49, and 84, so it<br=
>
should not be difficult<br>
to implement.<br>
<br>
=3D=3DTest vectors=3D=3D<br>
<br>
TBD<br>
<br>
=3D=3DReference=3D=3D<br>
<br>
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]<br>
* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]<br=
>
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic<br=
>
Wallets]]<br>
* [[bip-0049.mediawiki|BIP49 - Derivation scheme for<br>
P2WPKH-nested-in-P2SH based accounts]]<br>
* [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]=
]<br>
* [[bip-0341.mediawiki|BIP341 - Taproot: SegWit version 1 spending rules]]<=
br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000048bae005c56a9d7b--