BIP-375: correct labeled test vectors to include labeled-spend key in PSBT_OUT_SP_V0_INFO #2207

Includes two changes to align the labeled test vectors and validation reference with BIP-375:

• Sort silent payment codes lexicographically then by output index before assigning k values.
• PSBT_OUT_SP_V0_INFO should carry the labeled-spend public key, not the base-spend public key.

Changed vectors:

• can finalize: one P2WPKH input / two mixed outputs - labeled sp output and BIP 32 change
• can finalize: one input / two sp outputs - output 0 has no label / output 1 uses label=0 convention for sp change
• can finalize: three sp outputs (same scan key) - output 0 uses label=1, outputs 1 and 2 uses label=2 (same spend key)

Test Runner Output

Summary: 41 passed, 0 failed

cc BIP Owners for review: @andrewtoth, @achow101, @josibake

Implementer's note. btclib has a BIP375 implementation and currently assigns k in output index order, so this PR would change what it derives. Working notes and the full measurement are in https://github.com/btclib-org/btclib/issues/768.

Measured, in both directions, with bip-0375/test_runner.py on Python 3.12:

No invalid vector changes verdict under either rule. The two invalid vectors named after ordering do not discriminate between the rules: in invalid[20] the spend keys are already ascending, so index and lexicographic order coincide, and each of the two carries a k assignment no ascending rule produces (the two values swapped in one, three permuted in the other). So the discrepancy is confined to the labeled multi-output vectors, and this PR closes it.

Two remarks, one per half of the PR.

The PSBT_OUT_SP_V0_INFO half looks unambiguous — the field should carry the labeled spend key — and is independent of the ordering question.

On the ordering half, a question about the rule rather than about which artefact is normative. What the rule has to buy appears to be inter-party determinism only: the Signer sets PSBT_OUT_SCRIPT and the Extractor recomputes it, so both must land on the same bytes. Nothing else seems to depend on it — a BIP352 receiver scans by deriving P_k for k = 0, 1, 2 … and matching against the transaction's outputs, so it never learns which output was assigned which k; and permuting k within a scan-key group still pays each recipient the same amount, since an output's script is derived from its own spend key. If that is right, any deterministic rule is equally correct and the choice is a matter of cost, where two things differ:

• lexicographic order needs a canonical encoding of a "code" and a total order on it. The prose says "sort the codes", which could be the 66-byte PSBT_OUT_SP_V0_INFO, the bech32m address string, or the (scan, spend) pair; this PR picks the first, in code. Output indices need no such definition and are already in the psbt;
• the property lexicographic order would buy — invariance under output reordering — looks unavailable here: L185 requires a Signer setting a missing PSBT_OUT_SCRIPT to clear the Inputs Modifiable and Outputs Modifiable flags, and a psbt carrying a script with PSBT_GLOBAL_TX_MODIFIABLE non-zero is invalid (invalid[4]). Outputs cannot be reordered once the scripts exist. The tie-break for identical codes is output index in any case.

So index order looks like the cheaper rule, and it is what all three shipped artefacts did before this PR. That is an argument for amending the two sentences at L240-241 instead, and reducing this PR to its PSBT_OUT_SP_V0_INFO half.

We have no stake beyond interoperability and will follow whichever way this is settled. If the lexicographic rule is kept, one edit would help: have the prose name the sort key — the serialized PSBT_OUT_SP_V0_INFO, ascending, ties by output index, which is what this PR implements. As written, "the codes" leaves the next implementer the same choice that produced this divergence.

Unrelated and not touched here, noted while checking the above: L149 says "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", which names the field, whose table entry at L124 is <33 byte scan key> <33 byte spend key> — 66 bytes, which is what the vectors carry and what the validator requires (invalid[1] reports "wrong length (65 bytes, expected 66)"). Read in its own section the sentence is about the substitute output script used for unique identification, where a version byte prefix contradicts nothing; that is how btclib implemented it. Since the sentence names the field rather than the substitution, one line of disambiguation would help. Glad to send it separately.

Edited: the last paragraph originally called this an inconsistency about the field's length. In its section it is a question of wording, not a contradiction.