Hi all,
I'm working on the implementation of silent payments in BDK.

BDK's transaction creation process is structured around PSBTs. Because of this, 
a stable implementation of silent payments in the project depends of the 
specifications of BIP 352 for this format. BIP 375 and BIP 374 are core 
component for this.

However, there is a need for the inclusion of silent payments tweaks in PSBTs 
to spend silent payment outputs, which was considered before [1][2] but never 
specified.

I would like to propose the following as a base for a new BIP proposal 
addressing this gap:

### Abstract

This document proposes additional fields for BIP 370 PSBTv2 that allow for BIP 
352 silent payment tweaks to be included in a PSBT of version 2. These will be 
fields for scripts that are relevant to the spending of silent payment outputs, 
but may be also useful to other protocols using taproot tweaks not following 
BIP 340 spec.

### Motivation

BIPs 352 specify silent payments protocol, which provides a new way to create 
P2TR outputs and spend them. The existing PSBT fields are unable to support 
silent payments without changes, due to the new method by which outputs are 
created. BIP 375 and complementary BIP 374 specify how to create outputs locked 
with silent payment keys using PSBTs. But they don't specify how to unlock 
these outputs in a transaction. Therefore new fields must be defined to allow 
PSBTs to carry the information necessary for tweaking taproot keys without 
following the BIP 340 tagging scheme.

### Specification

The new per-input types are defined as follows:

| Name              | \<keytype\>               | \<keydata\> | 
<keydata\><br>Description | \<valuedata\>    | \<valuedata\><br>Description     
                                                                            | 
\<Versions Requiring Inlusion\> | \<Versions Requiring Exclusion\> | \<Versions 
Allowing Inclusion\> |
| ----------------- | ------------------------- | ----------- | 
------------------------- | ---------------- | 
------------------------------------------------------------------------------------------------------------
 | ------------------------------- | -------------------------------- | 
------------------------------- |
| Taproot Raw Tweak | `PSBT_IN_SP_TWEAK = 0x1f` | None        | No key data     
          | `<32-byte hash>` | A 32 byte raw tweak. Finalizers should remove 
this field after `PSBT_IN_FINAL_SCRIPTWITNESS` is constructed. |                
                 | 0                                | 2                         
      |

### Rationale

On PSBTs, when spending non silent payment outputs, one can rely on the 
`PSBT_IN_BIP32_DERIVATION` or any of the allowed `PSBT_IN_TAP_*` combinations 
available to get the right private keys to sign for each input.

To spend silent payment outputs you have to combine the private key with the 
tweak obtained from the transaction corpus.

On PSBT there is no field prescribed for this raw tweaks. The 
`PSBT_IN_BIP32_DERIVATION` field cannot be used because its different nature, 
neither the `PSBT_IN_TAP_MERKLE_ROOT` field because of the tagged hash used for 
tweaking.

A change of the hash tag used for silent payments to `TapTweak` or something 
compatible with taproot tweaking wouldn't make sense. Although the raw tweak 
can be disguised as the tap tree merkle root for spending, at the moment of 
verifying change outputs, you need the full tap tree, and there would be none 
backing this fake merkle root.

The use of proprietary fields is possible but brittle, as one may end up having 
to perform extra lookups for keys that are not unified across implementations.

Assuming different tweaking schemes available, `PSBT_IN_TAP_RAW_TWEAK` would be 
a more general solution. However is unclear how a hardware wallet will 
determine what the content of the field were in the first more general case. In 
addition, PSBT fields are usually specified as to the nature of the contents.

### Backward Compatibility

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

### Test Vectors

To be added

### Related Work

BIP 352, BIP 375, BIP 371

A version of this document is also available at 
https://gist.github.com/nymius/b3dd0b8a08c6735d617e6216b73c4260.

Any feedback is appreciated.

Thanks, nymius.


[1]: https://delvingbitcoin.org/t/bip352-psbt-support/877
[2]: https://groups.google.com/g/bitcoindev/c/5G5wzqUXyk4/m/1qEST5b7AQAJ

-- 
You received this message because you are subscribed to the Google Groups 
"Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/bitcoindev/R53cG3TeXgXDUUS4kH_q226GlaFCjI0DZVT6mdTQzSQdj3RnNqWA-bFT7uGgGQFJG6938kDGvDJVoFQj8ItEMsJ6NyOjCTvpVEarYiyW6-8%3D%40proton.me.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to