BIP Draft: Spending Silent Payment outputs with PSBTs #2089
Conversation
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
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.
| 2025-12-05: https://gist.github.com/nymius/b3dd0b8a08c6735d617e6216b73c4260 [gist] First draft | ||
| 2025-12-15: https://gnusha.org/pi/bitcoindev/R53cG3TeXgXDUUS4kH_q226GlaFCjI0DZVT6mdTQzSQdj3RnNqWA-bFT7uGgGQFJG6938kDGvDJVoFQj8ItEMsJ6NyOjCTvpVEarYiyW6-8=@proton.me/ [bitcoin-dev] [BIP Proposal] Add PSBT_IN_SP_TWEAK field | ||
| Version: 0.1.0 | ||
| Requires: 352, 375, 371 |
There was a problem hiding this comment.
| Requires: 352, 375, 371 | |
| Requires: 352, 370, 371, 375 |
There was a problem hiding this comment.
I'm not sure about BIP 375. It is related, but not needed by this specification.
BIP 3 states the following for the Requires field:
A list of existing BIPs the new proposal depends on.
Shall I remove it?
|
|
||
| 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.<ref name="why_not_adding_this_field_in_bip_375">''' Why not including this new field in BIP 375?''' Historically, Silent Payments have been categorized by the perspective of the user of the protocol: receiver or sender. BIP 375 has followed this convention, and its stated on its title: Sending Silent Payments with PSBTs. Given that spending belongs to the sphere of the receiver, and considering this convention, this specification should be a different BIP.</ref> | ||
|
|
||
| Therefore a new field must be defined to allow PSBTs to carry the information necessary for tweaking taproot keys without following the BIP 340 tagging scheme. |
There was a problem hiding this comment.
I’m not sure what “without following the BIP 340 tagging scheme” is referring to here.
There was a problem hiding this comment.
This is a typo, should be 341 instead of 340. I was referring to the "constructing and spending taproot outputs" section from BIP 341, particularly the Computing the output script and Spending using the key path subsections.
The main differences are related to the tag names and the committed data. For example, in taproot, the tweak is committed to the internal key, and is later added to that same key. On the contrary, in silent payments there can be two tweaks (first difference), let's call them A and B, where B is optional.
Tweak A is modifying public key T, but is not committing to public key T (second difference if we extrapolate public key T as our internal key).
The idea is later developed when I mention that we cannot disguise silent payment tweaks as a merkle root even if tag names weren't an issue.
| Discussion: 2024-05-17: https://delvingbitcoin.org/t/bip352-psbt-support/877/30 [delving bitcoin post] Original discussion | ||
| 2025-12-05: https://gist.github.com/nymius/b3dd0b8a08c6735d617e6216b73c4260 [gist] First draft | ||
| 2025-12-15: https://gnusha.org/pi/bitcoindev/R53cG3TeXgXDUUS4kH_q226GlaFCjI0DZVT6mdTQzSQdj3RnNqWA-bFT7uGgGQFJG6938kDGvDJVoFQj8ItEMsJ6NyOjCTvpVEarYiyW6-8=@proton.me/ [bitcoin-dev] [BIP Proposal] Add PSBT_IN_SP_TWEAK field | ||
| Version: 0.1.0 |
There was a problem hiding this comment.
Nit: Version corresponds to the latest line in the Changelog section, but there is no Changelog section here, yet.
…tion of 'Reference implementation'
|
I have pushed the changes in separated commits, to squash later. |
2 participants
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