Return-Path: <achow101-lists@achow101.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6E204C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Jun 2021 01:17:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 5D92B401F1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Jun 2021 01:17:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 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, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=achow101.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bdcUGGzEebDO
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Jun 2021 01:17:18 +0000 (UTC)
X-Greylist: delayed 03:54:33 by SQLgrey-1.8.0
Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com
 [51.77.79.158])
 by smtp2.osuosl.org (Postfix) with ESMTPS id DD7A64002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 23 Jun 2021 01:17:17 +0000 (UTC)
Date: Wed, 23 Jun 2021 01:17:01 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
 s=protonmail3; t=1624411029;
 bh=M3s+N6QL+rU+7No3SbeqHJ+OAwK2ydmsAs1YnJ4/DQQ=;
 h=Date:To:From:Reply-To:Subject:From;
 b=nOsjqg/z8DO2NuOXCZHi9VU5+Cuv2ScXlYGauWlxm3Knzq5j5HL1FJ0BfwhXOYHAF
 yAzMWNwlXq2Sg5n10WM5gSUVNJXoty1XPxMUUdFy8ykuw3pW9xXLLUtllKgLXQb+Dd
 5gFX7UgZrXp/sw6qAnjLWoeoQlwYOPvuFzIVXwrrFi7lD+yjHRDWV9lWTGPBbpXk03
 YpYG0FjV/ivDP/3TFavHN4lOq70ppz04hVruUl98D9bUhDvrG6cFHowsFkeicwehU1
 XX02DyP79VgnYv/5h3JEHN9KGQDZWCPKIxtld+poYBKJzDwEkRio0s36KUsaSNfEoF
 oT4CI76WfG8uw==
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Andrew Chow <achow101-lists@achow101.com>
Reply-To: Andrew Chow <achow101-lists@achow101.com>
Message-ID: <6bb9110e-b726-0470-96f0-2d68eadf23a3@achow101.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [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 01:17:20 -0000

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

Andrew Chow

---

<pre>
 =C2=A0 BIP: bip-taproot-bip44
 =C2=A0 Layer: Applications
 =C2=A0 Title: Derivation scheme for P2TR based accounts
 =C2=A0 Author: Andrew Chow <andrew@achow101.com>
 =C2=A0 Comments-Summary: No comments yet.
 =C2=A0 Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-taproot-bip44
 =C2=A0 Status: Draft
 =C2=A0 Type: Informational
 =C2=A0 Created: 2021-06-22
 =C2=A0 License: BSD-2-Clause
</pre>

=3D=3DAbstract=3D=3D

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.

=3D=3D=3DCopyright=3D=3D=3D

This BIP is licensed under the 2-clause BSD license.

=3D=3DMotivation=3D=3D

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.

=3D=3DSpecifications=3D=3D

This BIP defines the two needed steps to derive multiple deterministic
addresses based on a
[[bip-0032.mediawiki|BIP 32]] master private key.

=3D=3D=3DPublic key derivation=3D=3D=3D

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.

=3D=3D=3DAddress derivation=3D=3D=3D

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:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <signature>
scriptSig:=C2=A0=C2=A0=C2=A0 (empty)
scriptPubKey: 1 <32_byte_output_key>
 =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})
</pre>

=3D=3DBackwards Compatibility=3D=3D

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.

=3D=3DTest vectors=3D=3D

TBD

=3D=3DReference=3D=3D

* [[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]]