BIP376: Spending Silent Payment outputs with PSBTs

[nymius]

Abstract

This document proposes an additional per input field for BIP 370 PSBTv2 that allows BIP 352 silent payment tweaks to be included in a PSBT of version 2. This field will be relevant to silent payment outputs spending.

Mailing list discussion: https://groups.google.com/g/bitcoindev/c/Kap7NMwzl2k
Delving bitcoin discussion: https://delvingbitcoin.org/t/bip352-psbt-support/877/32

[murchandamus]

This is a good start, most parts seem to already be here. Would be great to get some more eyes on this from other people working on Silent Payments.

[nymius]

I have pushed the changes in separated commits, to squash later.
Thanks for the feedback!

[murchandamus]

What’s the next step here? Will you be asking for people to provide some review, do you still have planned work, are there any open questions?

[nymius]

So far, I haven't received any negative feedback on the proposal, so I plan to do a second round of review on the rationale. I would like to steel-man the argument for this approach against the other alternatives.
Since the feedback occurred outside the designated channels, I will try to move the discussion there whenever possible.

[murchandamus]

Assigned BIP376. Please update the BIP and Assigned headers in the preamble, add a table entry in the README for your proposal, and update your documents filename.

[nymius]

While weighing the requirement of BIP 375, I detected there is no mention of how to source the base key to which the PSBT_IN_SP_TWEAK is added.

I have multiple ideas for this:

• The 33 byte spend public key is included in the keydata from the new field.
• The derivation information of the spend key is included in the corresponding BIP 32 fields.
• The spend public key is transformed into a 32 xonly public key and it is included in one of the BIP 371 fields and both parities are considered.
• This is left unspecified and the signer should implement a way to match the private key with the input and the tweak.

This would be a source of ambiguity. I will consider the options and update once I've a conclusion.

[murchandamus]

Okay, I’ll consider this in your court until you state otherwise in a comment here. :)

[craigraw]

Good catch. I don't think this should be left unspecified.

Further, I think this choice can be simplified by considering the requirements of hardware wallets. I checked the firmware for both the Coldcard and the BitBox02 - both derive private keys from derivation paths, not public keys.

While you could use PSBT_IN_BIP32_DERIVATION, there may be some confusion with PSBT_OUT_TAP_BIP32_DERIVATION since BIP352 spends Taproot outputs.

To avoid this I suggest creating a new field called PSBT_IN_SP_SPEND_BIP32_DERIVATION which contains the same keydata and valuedata definitions used for PSBT_IN_BIP32_DERIVATION.

[nymius]

I have revised the spec to address grammar and phrasing, and included the following updates regarding content:

• Following @craigraw suggestion (thanks!) I added a new PSBT_IN_SP_BIP32_DERIVATION field:
  • I considered other alternatives that do not adhere to the BIP 32 scheme, such as FROST. However, as the PSBT specification is primarily built around the BIP 32 derivation scheme, I decided not to deviate from that standard. When the time comes, these protocols will likely propose updates to align with the PSBT specification. I added a reference at the end explaining this.
  • I moved the PSBT_IN_SP_TWEAK below this new field.
  • I added a paragraph to the rationale justifying the creation of this new field rather than reusing one of the existing *_BIP32_DERIVATION fields.
• I removed a paragraph from the rationale regarding the complexity of making BIP 341 and BIP 352 compatible to reuse Taproot BIP 371 fields (03e925c): I realized that the discussion of whether BIP 352 could have been designed to comprise BIP 341 tag hashes pertains to BIP 352 itself, not this document. This BIP should address BIP 352 as currently defined; changes to the BIP 352 standard belong to a different proposal.