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
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?
Sure, if your proposal doesn’t depend on it, you can remove it. I didn’t check the list, I just sorted it and added 370, because the first sentence said that you were adding a field to PSBTv2s, which is BIP 370. :)
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.
I’m not sure what “without following the BIP 340 tagging scheme” is referring to here.
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.
Okay, if you feel it’s clear enough, it’s fine with me, I was just reading it fairly quickly.
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.
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.
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.
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 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
Nit: Version corresponds to the latest line in the Changelog section, but there is no Changelog section here, yet.
98 | +'''''TODO''''' 99 | + 100 | +== Reference implementation == 101 | + 102 | +'''''TODO''''' 103 | +
Copyright section is missing.
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.
I have pushed the changes in separated commits, to squash later. Thanks for the feedback!
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?
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.
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.
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.
Okay, I’ll consider this in your court until you state otherwise in a comment here. :)
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:
This document specifies new fields and new field inclusion/exclusion requirements.
The 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
Included a grammar change that was left outside of last push.
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.
Typo: use 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.
It would be more accurate to say 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))''
Same issue: <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)'',
Missing a closing parenthesis here.
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.
The rationale explains that 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:
==== Signer ====
For 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.
The 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>.
The 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>
The 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.
==== Finalizer ====
For 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.
The 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.
Added comments inline. My major comment is around the lack of Signer and Finalizer roles. The Signer must verify the tweak provided by the Updater for safety.
Thanks, looks good. Just one typo: The new footnote <ref name="why_33_byte_keys> is missing a closing double-quote.
101 | + 102 | +The Signer must verify that the x coordinate of ''d·G'' equals ''P''. 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> 103 | + 104 | +The Signer must produce a BIP 340 Schnorr signature using the private key ''d'' and set the result in the <tt>PSBT_IN_TAP_KEY_SIG</tt> field as defined in BIP 371. 105 | + 106 | +==== Finalizer ====
I will change this from Finalizer to Input Finalizer to match the specified role in BIP 174.
Done in 986e0c2a53d945c35871fdda0c9a02f60a726b98
What is the reason for PSBT_IN_SP_SPEND_BIP32_DERIVATION to be a should and not a must?
I agree must is fine here too. I was erroring on conservative specification constraint.
Hmm I think must is too restrictive. If you only have 1 private key, you don't need a derivation path to find it.
Hmm I think must is too restrictive. If you only have 1 private key, you don't need a derivation path to find it.
But you could still use the field zeroing the derivation path. It isn't disabling the case, it's forcing the explicitness of the keys in the PSBT.
But you could still use the field zeroing the derivation path. It isn't disabling the case, it's forcing the explicitness of the keys in the PSBT.
To me that sounds like making the case for should. Why require a field if it is not needed, only to be forced to zero it out? Zeroing it out is more ambiguous than not including the field at all if not needed.
69 | +| Silent Payment Tweak 70 | +| <tt>PSBT_IN_SP_TWEAK = 0x20</tt> 71 | +| None 72 | +| No key data 73 | +| <tt><32-byte tweak></tt> 74 | +| A 32 byte raw tweak. Input Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
| A 32-byte raw tweak. Input Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed.
95 | + 96 | +==== Signer ==== 97 | + 98 | +For each input that has a <tt>PSBT_IN_SP_TWEAK</tt> field set, the Signer must determine the spend private key ''b<sub>spend</sub>'' 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. 99 | + 100 | +The Signer must compute the signing private key ''d = (b<sub>spend</sub> + tweak) mod n'', where ''tweak'' is the value of <tt>PSBT_IN_SP_TWEAK</tt>. Let ''P'' be the output key from the <tt>PSBT_IN_WITNESS_UTXO</tt> output script. If the y coordinate of ''d·G'' is odd (i.e. does not match the x-only output key ''P''), the Signer must negate ''d''.
The Signer must compute the signing private key ''d = (b<sub>spend</sub> + tweak) mod n'', where ''tweak'' is the value of <tt>PSBT_IN_SP_TWEAK</tt>. Let ''P'' be the output key from the <tt>PSBT_IN_WITNESS_UTXO</tt> output script. If the y-coordinate of ''d·G'' is odd (i.e. does not match the x-only output key ''P''), the Signer must negate ''d''.
97 | + 98 | +For each input that has a <tt>PSBT_IN_SP_TWEAK</tt> field set, the Signer must determine the spend private key ''b<sub>spend</sub>'' 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. 99 | + 100 | +The Signer must compute the signing private key ''d = (b<sub>spend</sub> + tweak) mod n'', where ''tweak'' is the value of <tt>PSBT_IN_SP_TWEAK</tt>. Let ''P'' be the output key from the <tt>PSBT_IN_WITNESS_UTXO</tt> output script. If the y coordinate of ''d·G'' is odd (i.e. does not match the x-only output key ''P''), the Signer must negate ''d''. 101 | + 102 | +The Signer must verify that the x coordinate of ''d·G'' equals ''P''. 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>
The Signer must verify that the x-coordinate of ''d·G'' equals ''P''. 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>
109 | + 110 | +The Input 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 Input 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. 111 | + 112 | +== Rationale == 113 | + 114 | +On PSBTs, when spending non Silent Payment outputs, one can rely on the <tt>PSBT_IN_BIP32_DERIVATION</tt> or any of the allowed <tt>PSBT_IN_TAP_*</tt> combinations available to get the right private keys to sign for each input.
On PSBTs, when spending non-Silent Payment outputs, one can rely on the <tt>PSBT_IN_BIP32_DERIVATION</tt> or any of the allowed <tt>PSBT_IN_TAP_*</tt> combinations available to get the right private keys to sign for each input.
142 | +'''''TODO''''' 143 | + 144 | +== Changelog == 145 | + 146 | +* 0.1.0 (YYYY-MM-DD '''''TODO'''''): 147 | +** Initial version
The version header and Changelog are only required once a BIP reaches the Complete status. If you don’t have content yet, you can omit them at this stage.
107 | + 108 | +For each input that has a <tt>PSBT_IN_SP_TWEAK</tt> field set, the Input 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. 109 | + 110 | +The Input 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 Input 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. 111 | + 112 | +== Rationale ==
The structure of the Rationale reads a bit jumbled. Perhaps consider turning it into a definition list, where each sentence responds to a question, or restructuring it a bit to make it flow more naturally.
I agree, I'm going to work on this.
I've pushed some updates addressing the clarity of the Rationale. Let me know if you have any comments.
What’s the status from your end?
Based on my review, I believe the content is complete, but I am allowing time to receive feedback and apply changes.
I plan to request ACKs on the final document once I have addressed all reviewer comments and sufficient time has passed without receiving new ones.
Perhaps a review from @theStack and @achow101 would be useful?
Thank you for bringing this up. Yes, that would be useful, and it may help cover other angles I might have missed.
Okay, then I’ll continue to leave the "PR Author action required" label on this PR as we previously communicated until you write to let me know that you consider it ready to be published.
I've added the new fields to the BIP 174 table. @murchandamus, I consider this ready for publication. Thanks to all reviewers!
Hey, thanks for letting me know. I’m going to be afk next week, but I’ll give it another pass when I’m back.
94 | + 95 | +==== Signer ==== 96 | + 97 | +For each input that has a <tt>PSBT_IN_SP_TWEAK</tt> field set, the Signer MUST determine the spend private key ''b<sub>spend</sub>'' 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. 98 | + 99 | +The Signer MUST compute the signing private key ''d = (b<sub>spend</sub> + tweak) mod n'', where ''tweak'' is the value of <tt>PSBT_IN_SP_TWEAK</tt>. Let ''P'' be the output key from the <tt>PSBT_IN_WITNESS_UTXO</tt> output script. If the y-coordinate of ''d·G'' is odd (i.e. does not match the x-only output key ''P''), the Signer MUST negate ''d''.
nit: for the sake of completeness, could mention that the PSBT_IN_WITNESS_UTXO output script must be of type P2TR (i.e. in the form 0x5120<32-bytes output key P>)
We can go a little bit further and fail if we have an PSBT_IN_SP_TWEAK combined with a non P2TR PSBT_IN_WITNESS_UTXO, as that's something impossible. What do you think?
diff --git a/bip-0376.mediawiki b/bip-0376.mediawiki
index fecfa2d..49418b2 100644
--- a/bip-0376.mediawiki
+++ b/bip-0376.mediawiki
@@ -96,7 +96,9 @@ The Updater SHOULD add <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt> when spending
For each input that has a <tt>PSBT_IN_SP_TWEAK</tt> field set, the Signer MUST determine the spend private key ''b<sub>spend</sub>'' 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.
-The Signer MUST compute the signing private key ''d = (b<sub>spend</sub> + tweak) mod n'', where ''tweak'' is the value of <tt>PSBT_IN_SP_TWEAK</tt>. Let ''P'' be the output key from the <tt>PSBT_IN_WITNESS_UTXO</tt> output script. If the y-coordinate of ''d·G'' is odd (i.e. does not match the x-only output key ''P''), the Signer MUST negate ''d''.
+If <tt>PSBT_IN_SP_TWEAK</tt> field is set, but <tt>PSBT_IN_WITNESS_UTXO</tt> is not a P2TR output, i.e., of the form `0x5120<32-bytes>`, the Signer MUST fail, as the only Silent Payment outputs possible are P2TR outputs.
+
+The Signer MUST compute the signing private key ''d = (b<sub>spend</sub> + tweak) mod n'', where ''tweak'' is the value of <tt>PSBT_IN_SP_TWEAK</tt>. Let ''P'' be the 32-byte output key from the <tt>PSBT_IN_WITNESS_UTXO</tt> P2TR output script. If the y-coordinate of ''d·G'' is odd (i.e. does not match the x-only output key ''P''), the Signer MUST negate ''d''.
The Signer MUST verify that the x-coordinate of ''d·G'' equals ''P''. 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>
That sounds reasonable yes :+1: IIUC, the only way reaching this state is if "Updater" entity misbehaved or the PSBT have been tampered with, so it makes sense to fail in this case.
Looks good to me overall.
I considered this ready for publication, and I still do, but after last comment I added the following changes:
PSBT_IN_SP_TWEAK field set.Role + Action [ + Reason ] formula to all role paragraphs to reduce ambiguity, and make each protocol step implication stand out on first sight.592 | +| A 32-byte raw tweak. Input Finalizers should remove this field after <tt>PSBT_IN_FINAL_SCRIPTWITNESS</tt> is constructed. 593 | +| 594 | +| 0 595 | +| 2 596 | +| [[bip-0376.mediawiki|376]] 597 | +|-
It’s really a headache that all of these table entries are duplicated and there is not a single source of truth. I’m working on proposing an alternative to that.
Looks very good! No further comments at this time, except that I think I’ll propose a scheme to deduplicate the field definitions, but I guess that could happen after this is published.
94 | + 95 | +==== Signer ==== 96 | + 97 | +The Signer MUST fail if <tt>PSBT_IN_SP_TWEAK</tt> is set, but <tt>PSBT_IN_WITNESS_UTXO</tt> is not a P2TR output, i.e., of the form <tt>0x5120<32-bytes></tt>, as the only Silent Payment outputs possible are P2TR outputs. 98 | + 99 | +The Signer MUST skip any input where either <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt> or <tt>PSBT_IN_SP_TWEAK</tt> is not present.
This language is too strong. It would mean that all P2TR spends must have either of these fields even if no the output is not silent payments.
There's additionally no guarantee nor any requirement that the spend key used BIP 32, so I don't think there needs to be any specific checks for this field, other than using it for derivation path information.
True, this was an oversight. What about:
The Signer MUST skip for the purpose of this specification, any input where <tt>PSBT_IN_SP_TWEAK</tt> is not present.
I don't think this sentence is needed at all. If the field is not present but the output belongs to that signer, they can't sign for it anyways and skips it. There's no need to say anything about must or can skip signing.
123 | +== Rationale == 124 | + 125 | +On PSBTs, when spending non-Silent Payment outputs, one just relies on <tt>PSBT_IN_BIP32_DERIVATION</tt> or any of the allowed <tt>PSBT_IN_TAP_*</tt> combinations. These are used to get the right private keys to sign each input. For Silent Payment outputs, it is not that simple. To get the private key needed to sign a Silent Payment output, you have to combine a private key with the tweak obtained from the transaction corpus. Currently, there is no field prescribed for this. 126 | + 127 | +==== Why not have the Signer compute the tweak? ==== 128 | +The tweak is produced by combining some data from the transaction. This includes the prevout public keys. This not only requires the previous transaction, but also all the outputs that were spent. Besides imposing a burden on the signer, who now has to perform extra cryptographic operations to combine all this, it also increases the amount of data included in the PSBT.
Suggest "but also all the outputs that were spent by that previous transaction."
You spotted a sentence that is also confusing for me.
As I read and placed your sentence into the text I started wondering to which previous transaction I was referring here: the transaction mentioned first in the text?, the transaction that created the outputs? I need the output being spent here and also the other outputs not spent here? what?
To avoid that chain of thought, I rewrote the paragraph to the following:
The tweak is produced by combining some data from the transaction and the public keys belonging to the outputs being spent by that transaction. Providing these outputs not only imposes a burden on the signer, who has to perform extra cryptographic operations to combine this data, but it also increases the total amount of data included in the PSBT.
98 | + 99 | +The Signer MUST skip any input where either <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt> or <tt>PSBT_IN_SP_TWEAK</tt> is not present. 100 | + 101 | +The Signer MUST determine the spend private key ''b<sub>spend</sub>'' using the derivation path provided in <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt> for each input where both <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt> and <tt>PSBT_IN_SP_TWEAK</tt> are set. 102 | + 103 | +The Signer MUST skip any input for which it doesn't have the key matching the indicated fingerprint and path in <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt>.
As I read it, this only applies when PSBT_IN_SP_SPEND_BIP32_DERIVATION is set. Let me know if you think otherwise and I will change it.
What about:
The Signer SHOULD determine the spend private key ''b<sub>spend</sub>'' using the derivation path provided in <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt> for each input where <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt> is set.
The Signer MUST skip any input for which it doesn't have the key matching the indicated fingerprint and path in <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt>.
In general, I don't think it's useful to specify when a signer can or must not sign an input. Either the fields provide enough information for the signer to determine that they can sign, or they do not provide enough information and signing is literally impossible.
102 | + 103 | +The Signer MUST skip any input for which it doesn't have the key matching the indicated fingerprint and path in <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt>. 104 | + 105 | +Let ''P'' be the 32-byte output key from the P2TR output script contained in <tt>PSBT_IN_WITNESS_UTXO</tt>. 106 | + 107 | +The Signer MUST compute the signing private key ''d = (b<sub>spend</sub> + tweak) mod n'', where ''tweak'' is the value of <tt>PSBT_IN_SP_TWEAK</tt>.
And to not reduce the spend key derivation to BIP 32 schemes, I could make the following change:
The Signer MUST compute the signing private key ''d = (b<sub>spend</sub> + tweak) mod n'', where ''tweak'' is the value of <tt>PSBT_IN_SP_TWEAK</tt> and ''b<sub>spend</sub>'' is the untweaked spend private key obtained using either <tt>PSBT_IN_SP_SPEND_BIP32_DERIVATION</tt> or other methods.
I went ahead and applied the changes mentioned above. I'm biased by the craft of the text, so let me know if you think any change should be revisited.
Considering the suggestions from achow101, I've removed the sentences that required the signer to validate input conditions before actually trying to sign them.
I also moved the description of the P output public key to the top of the Signer role paragraph, and combined it with the P2TR script format display, to keep addressing theStack suggestion.
ACK
LGTM