Taproot Fields for PSBT

Taproot Fields for PSBT
2021-06-28 10:03 ` Salvatore Ingala
  2021-11-24 12:44 ` Sjors Provoost
  
From: Andrew Chow @ 2021-06-22 21:22 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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.mediawiki.

Andrew Chow

---

<pre>
   BIP: taproot-psbt
   Layer: Applications
   Title: Taproot Fields for PSBT
   Author: Andrew Chow <andrew@achow101•com>
   Comments-Summary: No comments yet.
   Comments-URI:
https://github.com/bitcoin/bips/wiki/Comments:BIP-taproot-psbt
   Status: draft
   Type: Standards Track
   Created: 2021-06-21
   License: BSD-2-Clause
</pre>

==Introduction==

===Abstract===

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.

===Copyright===

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

===Motivation===

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.

==Specification==

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 = 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 = 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 = 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 = 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 = 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 = 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 = 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 = 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 = 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
|}

===UTXO Types===

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>.

==Compatibility==

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.

==Test Vectors==

TBD

==Rationale==

<references/>

==Reference implementation==

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

==Acknowledgements==

TBD




 permalink raw reply	[|nested]
2021-06-22 21:22 [bitcoin-dev] Taproot Fields for PSBT Andrew Chow

  2021-06-28 16:04   ` Andrew Chow
  2021-11-24 12:44 ` Sjors Provoost
  
From: Salvatore Ingala @ 2021-06-28 10:03 UTC (permalink / raw)
  To: Andrew Chow, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

Hi Andrew,

I just have a small suggestion on this proposal.

On Tue, 22 Jun 2021 at 23:29, Andrew Chow via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> | Taproot Leaf Script
> | <tt>PSBT_IN_TAP_LEAF_SCRIPT = 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.
>

So far, all the defined PSBT types had a relatively short keydata (not much
bigger than a couple of pubkeys).
I think that is a desirable property to keep, as it is often a reasonable
assumption that dictionary keys are not very large.
The control block as per BIP 341 can be up to 33 + 32*128 = 4129 bytes long.

Perhaps it would be better to split this into PSBT_IN_TAP_LEAF_SCRIPT
and PSBT_IN_TAP_LEAF_CONTROL_BLOCK (both with no keydata)?

Best,
Salvatore Ingala

[-- Attachment #2: Type: text/html, Size: 1549 bytes --]

 permalink raw reply	[|nested]
2021-06-28 10:03 ` Salvatore Ingala

  2021-06-28 19:56     ` Salvatore Ingala
  
From: Andrew Chow @ 2021-06-28 16:04 UTC (permalink / raw)
  To: Salvatore Ingala, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]

Hi Salvatore,

On 6/28/21 6:03 AM, Salvatore Ingala wrote:

> Hi Andrew,
>
> I just have a small suggestion on this proposal.
>
> On Tue, 22 Jun 2021 at 23:29, Andrew Chow via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> | Taproot Leaf Script
>> | <tt>PSBT_IN_TAP_LEAF_SCRIPT = 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.
>
> So far, all the defined PSBT types had a relatively short keydata (not much bigger than a couple of pubkeys).
> I think that is a desirable property to keep, as it is often a reasonable assumption that dictionary keys are not very large.
> The control block as per BIP 341 can be up to 33 + 32*128 = 4129 bytes long.
>
> Perhaps it would be better to split this into PSBT_IN_TAP_LEAF_SCRIPT and PSBT_IN_TAP_LEAF_CONTROL_BLOCK (both with no keydata)?

A taproot tree can have multiple leaf scripts, and since it is possible that the actual script to be used is not known at the time scripts and control blocks are added to the PSBT, it would not be sufficient to only have two fields with no keydata. It would not be possible to specify multiple leaf scripts.

Furthermore, it is possible to have the same leaf script appear multiple times in the tree. So it is not sufficient to use the leaf hash as the keydata as a script that appears multiple times would only have one control block possible, where in reality it would have more than one.

Thus the only way to allow multiple different leaf scripts, and the same leaf script to appear multiple times, is to use the control block as keydata.

Andrew Chow

> Best,
> Salvatore Ingala

[-- Attachment #2: Type: text/html, Size: 3780 bytes --]

 permalink raw reply	[|nested]
2021-06-28 16:04   ` Andrew Chow

  2021-07-08 20:06       ` Jeremy
  
From: Salvatore Ingala @ 2021-06-28 19:56 UTC (permalink / raw)
  To: Andrew Chow;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

Hi Andrew,

Thanks for the clarification, I was indeed reading it under the mistaken
assumption that only one leaf would be added to the PSBT.

En passant, for the less experienced readers, it might be helpful if the
key types that are possibly present multiple times (with different keydata)
were somehow labeled in the tables.

Best,
Salvatore Ingala

[-- Attachment #2: Type: text/html, Size: 461 bytes --]

 permalink raw reply	[|nested]
2021-06-28 19:56     ` Salvatore Ingala

  
From: Jeremy @ 2021-07-08 20:06 UTC (permalink / raw)
  To: Salvatore Ingala, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

Suggestion:

It should be allowed that different keys can specify different sighash
flags.

As an example, if chaperone signatures were desired with anyprevout, it
would be required to specify that the anyprevout key sign with APO and the
chaperone sign with ALL. As another example, Sapio emulator oracles sign
with SIGHASH_ALL whereas other signatories might be instructed to sign with
a different flag.

The current sighashtype key is per-input:
- If a sighash type is provided, the signer must check that the sighash is
acceptable. If unacceptable, they must fail.
- If a sighash type is not provided, the signer should sign using
SIGHASH_ALL, but may use any sighash type they wish.

So a new per-key mapping can be added safely.

I have no strong opinions on the format for said per-key sighash hints.

Why do this now? Well, I requested it when spec'ing V2 as well, but it
would be nice to get it spec'd and implemented.


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Mon, Jun 28, 2021 at 1:32 PM Salvatore Ingala via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Hi Andrew,
>
> Thanks for the clarification, I was indeed reading it under the mistaken
> assumption that only one leaf would be added to the PSBT.
>
> En passant, for the less experienced readers, it might be helpful if the
> key types that are possibly present multiple times (with different keydata)
> were somehow labeled in the tables.
>
> Best,
> Salvatore Ingala
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3502 bytes --]

 permalink raw reply	[|nested]
2021-06-22 21:22 [bitcoin-dev] Taproot Fields for PSBT Andrew Chow
  2021-06-28 10:03 ` Salvatore Ingala

  2021-11-24 16:00   ` Greg Sanders
  2021-11-24 16:08   ` Pieter Wuille
  
From: Sjors Provoost @ 2021-11-24 12:44 UTC (permalink / raw)
  To: Andrew Chow, Bitcoin Dev


[-- Attachment #1.1: Type: text/plain, Size: 1840 bytes --]

Hi Andrew,

I'm confused why PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION
contain not just the derivation path for the xonlypubkey, but also the tapleaf merkle path.

First I thought it was perhaps necessary in order for a signer to guess which
script leaves it can sign with its own keys. But you can't really know that without
actually seeing the script. When a signer looks at a script, it presumably already
knows the leaf path.

- Sjors

> Op 22 jun. 2021, om 23:22 heeft Andrew Chow via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> het volgende geschreven:
> 
> 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

Now at: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki <https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki>

> -
> | Taproot Key BIP 32 Derivation Path
> | <tt>PSBT_IN_TAP_BIP32_DERIVATION = 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.

> |-
> | Taproot Key BIP 32 Derivation Path
> | <tt>PSBT_OUT_TAP_BIP32_DERIVATION = 0x07</tt>
> | <tt><xonlypubkey></tt>
> | The 32 byte X-only public key
> | <tt><hashes len> <leaf hash>* <32-bit uint> <32-bit uint>*</tt>
> 


[-- Attachment #1.2: Type: text/html, Size: 3147 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2021-11-24 12:44 ` Sjors Provoost

  2021-11-24 16:08   ` Pieter Wuille
  
From: Greg Sanders @ 2021-11-24 16:00 UTC (permalink / raw)
  To: Sjors Provoost, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

I may be misunderstanding the question, but it seems essential data for the
finalizer role, which may not know such information on its own.

On Wed, Nov 24, 2021 at 11:15 PM Sjors Provoost via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Hi Andrew,
>
> I'm confused why PSBT_IN_TAP_BIP32_DERIVATION and
> PSBT_OUT_TAP_BIP32_DERIVATION
> contain not just the derivation path for the xonlypubkey, but also the
> tapleaf merkle path.
>
> First I thought it was perhaps necessary in order for a signer to guess
> which
> script leaves it can sign with its own keys. But you can't really know
> that without
> actually seeing the script. When a signer looks at a script, it presumably
> already
> knows the leaf path.
>
> - Sjors
>
> Op 22 jun. 2021, om 23:22 heeft Andrew Chow via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> het volgende geschreven:
>
> 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
>
>
> Now at: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
>
> -
> | Taproot Key BIP 32 Derivation Path
> | <tt>PSBT_IN_TAP_BIP32_DERIVATION = 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.
>
>
> |-
> | Taproot Key BIP 32 Derivation Path
> | <tt>PSBT_OUT_TAP_BIP32_DERIVATION = 0x07</tt>
> | <tt><xonlypubkey></tt>
> | The 32 byte X-only public key
> | <tt><hashes len> <leaf hash>* <32-bit uint> <32-bit uint>*</tt>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3405 bytes --]

 permalink raw reply	[|nested]
2021-11-24 12:44 ` Sjors Provoost
  2021-11-24 16:00   ` Greg Sanders

  
From: Pieter Wuille @ 2021-11-24 16:08 UTC ( / )
  To: Sjors Provoost, Bitcoin Protocol Discussion



On Wednesday, November 24th, 2021 at 7:44 AM, Sjors Provoost via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:

> Hi Andrew,
>
> I'm confused why PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION
> contain not just the derivation path for the xonlypubkey, but also the tapleaf merkle path.
>
> First I thought it was perhaps necessary in order for a signer to guess which
> script leaves it can sign with its own keys. But you can't really know that without
> actually seeing the script. When a signer looks at a script, it presumably already
> knows the leaf path.

No, that's exactly it. Signers aren't expected to know or understand scripts ahead of time. With a field telling them which keys are present in which leaves, and how those keys are derived, they can sign without fully understanding the script, or needing the ability to parse the relevant script at all. The actual script information is there too of course, for those that do want to analyze it, or factor that into the decision whether to sign or not.

Cheers,

--
Pieter