From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <achow101-lists@achow101.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A3A8CC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 21:28:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 8129D60618
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 21:28:37 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 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_HELO_PASS=-0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=achow101.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Ws0edw_nybBZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 21:28:35 +0000 (UTC)
X-Greylist: delayed 00:05:46 by SQLgrey-1.8.0
Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch
 [185.70.41.103])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 0B8706060A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 21:28:34 +0000 (UTC)
Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com
 [51.77.79.158])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits))
 (No client certificate requested)
 by mail-41103.protonmail.ch (Postfix) with ESMTPS id 4G8fWC22yyz4wyqh
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Jun 2021 21:22:47 +0000 (UTC)
Authentication-Results: mail-41103.protonmail.ch;
 dkim=pass (2048-bit key) header.d=achow101.com header.i=@achow101.com
 header.b="UmVMzQog"
Date: Tue, 22 Jun 2021 21:22:28 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=achow101.com;
 s=protonmail3; t=1624396956;
 bh=1hpNI/i3WEWKIFc6zBhd9yZBkIC7DtUZQN8aQwqEFaE=;
 h=Date:To:From:Reply-To:Subject:From;
 b=UmVMzQogDUroBkWvjroHlNjU6TWPfJbQQe8heYbvisqrOfuP+VHtr828xVLedtxY7
 nvnYhKc5/QPkAR3cmYxuRgaik9NUoktIreznervGYmajwp/GtwiPCFmKUJ//B4qtlz
 tyzICsALvXUzOJdAT9BwR0G2TK6jurwG3n4XFH6D641yK6+1DX3vbBN0ZhbOv75nc6
 sURZLiDasZuh/T7pT7REznLTX+00ECZ7t5P8MdxSWNYrlnHHZHT9KRx3bAb02Fl9Vo
 wixcauHLxMY9f5PN2quz6PDmspMWuM/utn8sDuv+eSishXOfwhljNjueFub5PoIBSl
 cq7q8cfbDSroA==
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: <795f917b-3883-1827-f39b-35123b500f36@achow101.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Taproot Fields for PSBT
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: Tue, 22 Jun 2021 21:28:37 -0000

Hi All,

I would like to propose a BIP which defines new fields for Taproot
support in PSBT.

The full text is below, and the rendered file can be found at
https://github.com/achow101/bips/blob/taproot-psbt/bip-taproot-psbt.mediawi=
ki.

Andrew Chow

---

<pre>
 =C2=A0 BIP: taproot-psbt
 =C2=A0 Layer: Applications
 =C2=A0 Title: Taproot Fields for PSBT
 =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-psbt
 =C2=A0 Status: draft
 =C2=A0 Type: Standards Track
 =C2=A0 Created: 2021-06-21
 =C2=A0 License: BSD-2-Clause
</pre>

=3D=3DIntroduction=3D=3D

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

This document proposes additional fields for BIP 174 PSBTv0 and BIP 370
PSBTv2 that allow for
BIP 340/341/342 Taproot data to be included in a PSBT of any version.
These will be fields for
signatures and scripts that are relevant to the creation of Taproot inputs.

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

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

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

BIPs 340, 341, and 342 specify Taproot which provides a wholly new way
to create and spend Bitcoin outputs.
The existing PSBT fields are unable to support Taproot due to the new
signature algorithm and the method
by which scripts are embedded inside of a Taproot output. Therefore new
fields must be defined to allow
PSBTs to carry the information necessary for signing Taproot inputs.

=3D=3DSpecification=3D=3D

The new per-input types are defined as follows:

{|
! Name
! <tt><keytype></tt>
! <tt><keydata></tt>
! <tt><keydata></tt> Description
! <tt><valuedata></tt>
! <tt><valuedata></tt> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| Taproot Key Spend Signature
| <tt>PSBT_IN_TAP_KEY_SIG =3D 0x13</tt>
| None
| No key data <ref>'''Why is there no key data for
<tt>PSBT_IN_TAP_KEY_SIG</tt>'''The signature in a key path spend
corresponds directly with the pubkey provided in the output script. Thus
it is not necessary to provide any metadata that attaches the key path
spend signature to a particular pubkey.</ref>
| <tt><signature></tt>
| The 64 or 65 byte Schnorr signature for key path spending a Taproot
output.
|
|
| 0, 2
|-
| Taproot Script Spend Signature
| <tt>PSBT_IN_TAP_SCRIPT_SIG =3D 0x14</tt>
| <tt><xonlypubkey> <leafhash></tt>
| The 32 byte X-only public key concatenated with the 32 byte hash of
the leaf it is part of.
| <tt><signature></tt>
| The 64 or 65 byte Schnorr signature for this pubkey and leaf combination.
|
|
| 0, 2
|-
| Taproot Leaf Script
| <tt>PSBT_IN_TAP_LEAF_SCRIPT =3D 0x15</tt>
| <tt><control block></tt>
| The control block for this leaf as specified in BIP 341. The control
block contains the merkle tree path to this leaf.
| <tt><script> <8-bit uint></tt>
| The script for this leaf as would be provided in the witness stack
followed by the single byte leaf version.
|
|
| 0, 2
|-
| Taproot Key BIP 32 Derivation Path
| <tt>PSBT_IN_TAP_BIP32_DERIVATION =3D 0x16</tt>
| <tt><xonlypubkey></tt>
| The 32 byte X-only public key
| <tt><hashes len> <leaf hash>* <32-bit uint> <32-bit uint>*</tt>
| A compact size unsigned integer representing the number of leaf
hashes, followed by a list of leaf hashes, followed by the master key
fingerprint concatenated with the derivation path of the public key. The
derivation path is represented as 32-bit little endian unsigned integer
indexes concatenated with each other. Public keys are those needed to
spend this output. The leaf hashes are of the leaves which involve this
public key.
|
|
| 0, 2
|-
| Taproot Internal Key
| <tt>PSBT_IN_TAP_INTERNAL_KEY =3D 0x17</tt>
| None
| No key data
| <tt><pubkey></tt>
| The X-only pubkey used as the internal key in this output.<ref>'''Why
is the internal key provided?'''The internal key is not necessarily the
same key as in the Taproot output script. BIP 341 recommends tweaking
the key with the hash of itself. It may be necessary for signers to know
what the internal key actually is so that they are able to determine
whether an input can be signed by it.</ref>
|
|
| 0, 2
|-
| Taproot Merkle Root
| <tt>PSBT_IN_TAP_MERKLE_ROOT =3D 0x18</tt>
| None
| No key data
| <tt><pubkey></tt>
| The 32 byte Merkle root hash
|
|
| 0, 2
|}

The new per-output types are defined as follows:

{|
! Name
! <tt><keytype></tt>
! <tt><keydata></tt>
! <tt><keydata></tt> Description
! <tt><valuedata></tt>
! <tt><valuedata></tt> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| Taproot Internal Key
| <tt>PSBT_OUT_TAP_INTERNAL_KEY =3D 0x05</tt>
| None
| No key data
| <tt><pubkey></tt>
| The X-only pubkey used as the internal key in this output.
|
|
| 0, 2
|-
| Taproot Tree
| <tt>PSBT_OUT_TAP_TREE =3D 0x06</tt>
| None
| No key data
| <tt>{<8-bit uint depth> <8-bit uint leaf version> <scriptlen>
<script>}*</tt>
| One or more tuples representing the depth, leaf version, and script
for a leaf in the Taproot tree, allowing the entire tree to be
reconstructed. The tuples must be in depth first search order so that
the tree is correctly reconstructed. Each tuple is an 8-bit unsigned
integer representing the depth in the Taproot tree for this script, an
8-bit unsigned integer representing the leaf version, the length of the
script as a compact size unsigned integer, and the script itself.
|
|
| 0, 2
|-
| Taproot Key BIP 32 Derivation Path
| <tt>PSBT_OUT_TAP_BIP32_DERIVATION =3D 0x07</tt>
| <tt><xonlypubkey></tt>
| The 32 byte X-only public key
| <tt><hashes len> <leaf hash>* <32-bit uint> <32-bit uint>*</tt>
| A compact size unsigned integer representing the number of leaf
hashes, followed by a list of leaf hashes, followed by the master key
fingerprint concatenated with the derivation path of the public key. The
derivation path is represented as 32-bit little endian unsigned integer
indexes concatenated with each other. Public keys are those needed to
spend this output. The leaf hashes are of the leaves which involve this
public key.
|
|
| 0, 2
|}

=3D=3D=3DUTXO Types=3D=3D=3D

BIP 174 recommends using <tt>PSBT_IN_NON_WITNESS_UTXO</tt> for all
inputs because of potential attacks involving
an updater lying about the amounts in an output. Because a Taproot
signature will commit to all of the amounts
and output scripts spent by the inputs of the transaction, such attacks
are prevented as any such lying would
result in an invalid signature. Thus Taproot inputs can use just
<tt>PSBT_IN_WITNESS_UTXO</tt>.

=3D=3DCompatibility=3D=3D

These are simply new fields added to the existing PSBT format. Because
PSBT is designed to be extensible, old
software will ignore the new fields.

=3D=3DTest Vectors=3D=3D

TBD

=3D=3DRationale=3D=3D

<references/>

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

The reference implementation of the PSBT format is available at TBD.

=3D=3DAcknowledgements=3D=3D

TBD