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.
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.
PSBT_IN_SP_TWEAK must be included when an input spends a Silent Payment output
PSBT_IN_SP_SPEND_BIP32_DERIVATION should be included when spending a Silent Payment output using BIP 32 derivation schemes
I agree, I will add them to the Updater in the same fashion as BIP 375.
What is the reason for PSBT_IN_SP_SPEND_BIP32_DERIVATION to be a should and not a must?
What is the reason for
PSBT_IN_SP_SPEND_BIP32_DERIVATIONto be ashouldand not amust?
I agree must is fine here too. I was erroring on conservative specification constraint.
I’ve included a preamble to the Field specification, and expanded on the requirements of the Updater role.
I’ve squashed all commits in f6ef1a8c12634cf9598bad2ea84620bbc770698a.
I’m open to receive another round of reviews.
cc: @macgyver13 @craigraw
20+
21+This document proposes additional per input fields for BIP 370 PSBTv2 that allows BIP 352 Silent Payment tweaks to be included in a PSBT of version 2. These fields will be relevant to Silent Payment outputs spending.
22+
23+=== Motivation ===
24+
25+BIP 352 specify the Silent Payment protocol, which provides a new way to create P2TR outputs and spend them.
specifies instead of specify.
57+! Versions Allowing Inclusion
58+|-
59+| Silent Payment Spend Key BIP 32 Derivation Path<ref name="why_sticking_to_bip32_derivation">''' Why only considering BIP 32 for spend key generation?''' Although alternative key derivation methods exist (e.g., FROST) and have devised mechanisms to interact with PSBTs without modifying the format, the vast majority of hardware wallets are architected around BIP 32 derivation scheme. As primary consumers of the PSBT format, these devices have significantly influenced its design. Consequently, this BIP avoids preemptively enforcing a shift away from the established BIP 32 paradigm.</ref>
60+| <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION = 0x1f</tt>
61+| <tt><33-byte spend key></tt>
62+| The 33-byte spend public key locking this input.
The 33-byte spend public key used to derive the key locking this input. The tweaked key actually locks the input.
68+|-
69+| Silent Payment Tweak
70+| <tt>PSBT_IN_SP_TWEAK = 0x20</tt>
71+| None
72+| No key data
73+| <tt><32-byte hash></tt>
<32-byte hash> is misleading. When a label is used, the value is t_k + label_tweak — a sum of two scalars, not a hash. Should be <32-byte tweak> to match the field name and the description.
75+|
76+| 0
77+| 2
78+|}
79+
80+Per [https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#spending BIP 352 spending] the <tt><32-byte-hash></tt> is ''hash<sub>BIP0352/SharedSecret</sub>(ser<sub>P</sub>(ecdh_shared_secret) || ser<sub>32</sub>(k))''
<32-byte-hash> should be <32-byte tweak> for consistency.
77+| 2
78+|}
79+
80+Per [https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#spending BIP 352 spending] the <tt><32-byte-hash></tt> is ''hash<sub>BIP0352/SharedSecret</sub>(ser<sub>P</sub>(ecdh_shared_secret) || ser<sub>32</sub>(k))''
81+
82+or ''hash<sub>BIP0352/SharedSecret</sub>(ser<sub>P</sub>(ecdh_shared_secret) || ser<sub>32</sub>(k)) + hash<sub>BIP0352/Label</sub>(ser<sub>256</sub>(b<sub>scan</sub>) || ser<sub>32</sub>(m)'',
89+
90+==== Updater ====
91+
92+The updater '''must add''' <tt>PSBT_IN_SP_TWEAK</tt> when an input spends a Silent Payment output.
93+
94+The updater '''must add''' <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION_TWEAK</tt> when spending a Silent Payment output using BIP 32 derivation scheme. If the updater does not want to reveal the fingerprint or derivation path, it can set the value of the field to zero.
Field name typo: PSBT_IN_SP_SPEND_BIP32_DERIVATION_TWEAK should be PSBT_IN_SP_SPEND_BIP32_DERIVATION.
Also, “set the value of the field to zero” is a little ambiguous. Should clarify the structure, for example: “it can set the value to a 4-byte zero fingerprint with an empty derivation path”.
109+
110+For the Silent Payment spending tweak, the <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.
111+
112+Assuming different tweaking schemes available, <tt>PSBT_IN_TAP_RAW_TWEAK</tt> would be a more general solution, but PSBT fields are usually specified as to the nature of the contents, and is unclear how a hardware wallet will determine what the content of the field were in the first more general case.
113+
114+The inclusion of the tweak in the PSBT is insufficient in isolation; it must be accompanied by the information required to derive the correct private key. Silent Payment spend public key cannot utilize <tt>PSBT_IN_TAP_BIP32_DERIVATION</tt> because BIP 352 specifies 33-byte spend keys, which do not fit within this <tt>keydata</tt> field. Furthermore, reliance on <tt>PSBT_IN_BIP32_DERIVATION</tt> is precluded because BIP 352 spending rules follow BIP 341, which mandates the use of Schnorr signatures.
PSBT_IN_TAP_BIP32_DERIVATION can’t be used because BIP 352 uses 33-byte spend keys, but doesn’t explain why 33-byte (compressed) form is needed rather than 32-byte x-only. The reason is that the spend key is an intermediate value, and the parity matters when computing d = b_spend + tweak and then checking against the x-only output key.
This left me wondering why spend/scan key were left uncompressed not made x-only and force script pub key parity in the silent payment derivation. Fingerprinting? (again, I confused key parity with x-only keys)
It would be a good addition to BIP 352 rationales.
90+==== Updater ====
91+
92+The updater '''must add''' <tt>PSBT_IN_SP_TWEAK</tt> when an input spends a Silent Payment output.
93+
94+The updater '''must add''' <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION_TWEAK</tt> when spending a Silent Payment output using BIP 32 derivation scheme. If the updater does not want to reveal the fingerprint or derivation path, it can set the value of the field to zero.
95+
Roles for the Signer and Finalizer are not present. I think they need to be, particularly for verifying the tweak is correct. Without it, a signer blindly trusts the updater’s tweak. By checking d*G == P (where P is determined from the required PSBT_IN_WITNESS_UTXO field), the signer confirms the tweak is consistent with the output being spent. This is cheap (one EC multiplication) and prevents signing for an attacker-controlled key.
The Finalizer role should specify the additional cleanup required.
I suggest the following:
0==== Signer ====
1
2For each input that has a <tt>PSBT_IN_SP_TWEAK</tt> field set, the Signer must determine the spend private key <tt>b<sub>spend</sub></tt> using the derivation path provided in <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt>. If this field is not present, or the Signer does not have the key matching the indicated fingerprint and path, the Signer must skip this input.
3
4The Signer must compute the signing private key <tt>d = (b<sub>spend</sub> + tweak) mod n</tt>, where <tt>tweak</tt> is the value of <tt>PSBT_IN_SP_TWEAK</tt>. Let <tt>P</tt> be the output key from the <tt>PSBT_IN_WITNESS_UTXO</tt> scriptPubKey. If the Y coordinate of <tt>d·G</tt> is odd (i.e. does not match the X-only output key <tt>P</tt>), the Signer must negate <tt>d</tt>.
5
6The Signer must verify that the X coordinate of <tt>d·G</tt> equals <tt>P</tt>. If they are not equal, the Signer must fail, as the tweak does not correspond to the spent output.<ref name="why_verify_tweak">''' Why must the Signer verify the tweak?''' The tweak is provided by the Updater and could be incorrect, either through error or malice. Without verification, the Signer would produce a valid Schnorr signature for a key it does not control, which could be used to steal funds. Verifying that the tweaked key matches the output key ensures the Signer is signing for the expected output.</ref>
7
8The Signer must produce a BIP 340 Schnorr signature using the private key <tt>d</tt> and set the result in the <tt>PSBT_IN_TAP_KEY_SIG</tt> field as defined in BIP 371.
9
10==== Finalizer ====
11
12For each input that has a <tt>PSBT_IN_SP_TWEAK</tt> field set, the Finalizer must verify that a <tt>PSBT_IN_TAP_KEY_SIG</tt> field is present. If not, the input is not fully signed and cannot be finalized.
13
14The Finalizer must construct the <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> containing the single witness element from <tt>PSBT_IN_TAP_KEY_SIG</tt>, as per the BIP 341 key path spending rule. The Finalizer must then remove the <tt>PSBT_IN_SP_TWEAK</tt>, <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt>, <tt>PSBT_IN_TAP_KEY_SIG</tt>, and <tt>PSBT_IN_WITNESS_UTXO</tt> fields.
Agree.
Some lights on my thought process: I followed BIP 370 approach for this, and it left all this unspecified as it relies mainly in BIP 341. I thought we could rely back in BIP 352 too.
This was clearly an oversight.
<ref name="why_33_byte_keys> is missing a closing double-quote.