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
9+ License: BSD-2-Clause
10+ Discussion: 2024-05-17: https://delvingbitcoin.org/t/bip352-psbt-support/877/30 [delving bitcoin post] Original discussion
11+ 2025-12-05: https://gist.github.com/nymius/b3dd0b8a08c6735d617e6216b73c4260 [gist] First draft
12+ 2025-12-15: https://gnusha.org/pi/bitcoindev/R53cG3TeXgXDUUS4kH_q226GlaFCjI0DZVT6mdTQzSQdj3RnNqWA-bFT7uGgGQFJG6938kDGvDJVoFQj8ItEMsJ6NyOjCTvpVEarYiyW6-8=@proton.me/ [bitcoin-dev] [BIP Proposal] Add PSBT_IN_SP_TWEAK field
13+ Version: 0.1.0
14+ Requires: 352, 375, 371
0 Requires: 352, 370, 371, 375
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?
26+
27+The existing PSBT fields are unable to support silent payments without changes, due to the new method by which outputs are created.
28+
29+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>
30+
31+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.
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.
79+
80+Once a silent payment UTXO is scanned, is easier to store the output together with the tweak that generated it.
81+
82+To avoid the burden on the signer it would be better to pass this data into the PSBT together with the input spending the silent payment. Currently, there is no field prescribed for this.
83+
84+The <tt>PSBT_IN_BIP32_DERIVATION</tt> field cannot be used because its different nature, neither the <tt>PSBT_IN_TAP_MERKLE_ROOT</tt> field because of the tagged hash used for tweaking.
0The <tt>PSBT_IN_BIP32_DERIVATION</tt> field cannot be used because of its different nature, neither can the <tt>PSBT_IN_TAP_MERKLE_ROOT</tt> field because of the tagged hash used for tweaking.
81+
82+To avoid the burden on the signer it would be better to pass this data into the PSBT together with the input spending the silent payment. Currently, there is no field prescribed for this.
83+
84+The <tt>PSBT_IN_BIP32_DERIVATION</tt> field cannot be used because its different nature, neither the <tt>PSBT_IN_TAP_MERKLE_ROOT</tt> field because of the tagged hash used for tweaking.
85+
86+A change of the hash tag used for silent payments to <tt>TapTweak</tt> 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.
0A change of the hash tag used for silent payments to <tt>TapTweak</tt> or something compatible with taproot tweaking wouldn't make sense: although the raw tweak can be disguised as the script tree merkle root for spending, at the moment of verifying change outputs, you need the full script tree, and there would be none backing this fake merkle root.
8+ Assigned: ?
9+ License: BSD-2-Clause
10+ Discussion: 2024-05-17: https://delvingbitcoin.org/t/bip352-psbt-support/877/30 [delving bitcoin post] Original discussion
11+ 2025-12-05: https://gist.github.com/nymius/b3dd0b8a08c6735d617e6216b73c4260 [gist] First draft
12+ 2025-12-15: https://gnusha.org/pi/bitcoindev/R53cG3TeXgXDUUS4kH_q226GlaFCjI0DZVT6mdTQzSQdj3RnNqWA-bFT7uGgGQFJG6938kDGvDJVoFQj8ItEMsJ6NyOjCTvpVEarYiyW6-8=@proton.me/ [bitcoin-dev] [BIP Proposal] Add PSBT_IN_SP_TWEAK field
13+ Version: 0.1.0
98+'''''TODO'''''
99+
100+== Reference implementation ==
101+
102+'''''TODO'''''
103+
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:
This would be a source of ambiguity. I will consider the options and update once I’ve a conclusion.
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.
After considering how to explain the difficulty of making BIP 341 and
BIP 352 compatible to avoid the addition of this field, I decided to
remove the paragraph completely, because at the end, the discussion if
BIP 352 could have been made differently to be compatible with BIP 341
tag hashes and reuse BIP 371 fields, belongs to BIP 352 and not here.
This BIP should consider BIP 352 as it is. Changes to BIP 352 belong to
a different BIP proposal.
I have revised the spec to address grammar and phrasing, and included the following updates regarding content:
PSBT_IN_SP_BIP32_DERIVATION field:
PSBT_IN_SP_TWEAK below this new field.*_BIP32_DERIVATION fields.38+* ser<sub>256</sub>(p): serializes the integer p as a 32-byte sequence, most significant byte first.
39+* ser<sub>P</sub>(P): serializes the coordinate pair P = (x,y) as a byte sequence using SEC1's compressed form: (0x02 or 0x03) || ser<sub>256</sub>(x), where the header byte depends on the parity of the omitted Y coordinate.
40+* ''hash<sub>tag</sub>(x)'': refers to ''SHA256(SHA256(tag) || SHA256(tag) || x)''.
41+
42+=== Fields ===
43+
I would suggest including the following:
0This document specifies new fields and new field inclusion/exclusion requirements.
1
2The new per-input types are defined as follows:
Concept ACK 2a3ca6a
Thank you for putting this BIP forward. I support the addition of these two PSBT fields for spending Silent Payments outputs.
Regarding the BIP text I would like to see more explicit use of language to describe the inclusion of these fields for spending Silent Payments, similar to BIP-375 (PSBT_OUT_SCRIPT / PSBT_OUT_SP_V0_INFO). I think the Rationale explains the reasoning but having a more clear specification would reduce ambiguity. I am on the fence as to whether to include the following as general spec statements or in a specific role.