bip-0375: say the version byte belongs to the identifier, not to the field #2257

pull fametrano wants to merge 1 commits into bitcoin:master from fametrano:bip375-sp-info-identifier-serialization changing 1 files +1 −1

fametrano commented at 5:24 PM on August 14, 2026: contributor

One sentence, in the Unique Identification section:

The PSBT_OUT_SP_V0_INFO should be serialized as a zero byte for the version, followed by the 33 bytes of the scan key and then 33 bytes for the spend key.

It names the field, and the field is 66 bytes: its table entry is <33 byte scan key> <33 byte spend key>, bip375_test_vectors.json carries 66, and validator/validate_psbt.py refuses anything else — invalid[1] reports "Output 0 SP_V0_INFO has wrong length (65 bytes, expected 66)".

Read in its section the sentence is not about the field but about the output script that stands in for a silent payment output when building the unsigned transaction used for unique identification, where 67 bytes contradicts nothing. That is also where it came from: d29e2f8 added it together with the unique-identification paragraph above it.

Both readings are available to someone reading the sentence alone, and one of them contradicts three other artefacts. This picks the one that does not, without changing anything normative.

No changelog entry or version bump: nothing about the format changes, and leaving them out keeps this from conflicting with #2207 or #2256, both of which touch the changelog. Glad to add both if you would rather have them.

scripts/link-format-chk.sh, scripts/buildtable.pl, scripts/diffcheck.sh and typos pass locally.

Noticed while implementing BIP375 in btclib, which serializes the version byte in the identifier and not in the field: https://github.com/btclib-org/btclib/issues/768
jonatack commented at 9:43 PM on August 14, 2026: member

@fametrano Thank you for your contribution. Out of personal curiosity, what AI did you use to make 228 GitHub contributions (so far) today? The PR description is a little hard to grok, can you summarize more concisely in your own words, please?
fametrano commented at 2:51 PM on September 7, 2026: contributor

@jonatack in my own words: PSBT_OUT_SP_V0_INFO is 66 bytes everywhere else in the BIP (field table, vectors, validator), but one sentence in Unique Identification says to serialize it with a leading version byte, which is 67. That sentence describes the placeholder output script used to compute the identifier, not the field. The rewording makes that reading the only one available; nothing normative changes.

On the tooling question: Claude Code, driven by me. The measurements are run locally and I review every text before it is posted; most of that day's contributions were in my own btclib-org repositories, where BIP375 was being implemented. Point taken on the descriptions, I will keep them shorter.
fametrano force-pushed on Sep 12, 2026
fametrano force-pushed on Sep 19, 2026
fametrano force-pushed on Sep 23, 2026

in bip-0375.mediawiki:149 in d6e0215728

 145 | @@ -146,7 +146,7 @@ If only PSBT_OUT_SCRIPT is present for an output, then the output is not being s
 146 |  ===Unique Identification===
 147 |  
 148 |  Silent payment capable PSBTs can be uniquely identified the same way as PSBTv2s, except when including silent payment outputs. If an output contains the PSBT_OUT_SP_V0_INFO field, it must use that field instead of PSBT_OUT_SCRIPT as the output script when creating the unsigned transaction used for unique identification.<ref name="why_use_sp_info_field"> ''' Why use PSBT_OUT_SP_V0_INFO when serializing for a unique identifier?''' Since the same silent payment capable PSBT is valid whether or not a PSBT_OUT_SCRIPT is included in an output that has PSBT_OUT_SP_V0_INFO set, using the PSBT_OUT_SCRIPT if present for the unique identifier will cause malleability. The identifier will be different depending on whether PSBT_OUT_SCRIPT is present, so always using PSBT_OUT_SP_V0_INFO if it exists makes sure the PSBT is always identified uniquely.</ref>
 149 | -The PSBT_OUT_SP_V0_INFO should be serialized as a zero byte for the version, followed by the 33 bytes of the scan key and then 33 bytes for the spend key.
 150 | +In that unsigned transaction, the output script of such an output is a zero byte for the version, followed by the 33 bytes of the scan key and then 33 bytes for the spend key; the PSBT_OUT_SP_V0_INFO field itself is the two keys, without the version byte.

achow101 commented at 10:31 PM on September 23, 2026:

the PSBT_OUT_SP_V0_INFO field itself is the two keys, without the version byte.

I don't think it is necessary to specify this again, it's already specified elsewhere.

fametrano commented at 5:27 PM on September 24, 2026:

Agreed, dropped it: the sentence now ends at the spend key.

murchandamus added the label Fixups on Sep 23, 2026
fametrano force-pushed on Sep 24, 2026
fametrano force-pushed on Sep 26, 2026

bip-0375: say the version byte belongs to the identifier, not to the field

"The PSBT_OUT_SP_V0_INFO should be serialized as a zero byte for the
version, followed by the 33 bytes of the scan key and then 33 bytes for
the spend key" names the field, and the field is 66 bytes: its table
entry is "<33 byte scan key> <33 byte spend key>", the test vectors carry
66, and the validator refuses anything else.

The sentence is in the Unique Identification section and was added with
it, so what it describes is the output script that stands in for a silent
payment output when building the unsigned transaction that identifies the
psbt -- 67 bytes there, and nothing about the field. Read as the field's
own serialization it contradicts the table, which is how it first read
here.

Only the wording changes.

ce77b5cc17

fametrano force-pushed on Sep 27, 2026

Contributors

Labels

Linked (view graph)

#2207 BIP-375: correct labeled test vectors to include labeled-spend key in PSBT_OUT_SP_V0_INFO #2256 bip-0375: assign k in output index order, fix labeled test vectors