BIP375: Add test vectors + validator #2046

macgyver13 commented at 9:09 PM on November 26, 2025: contributor

This PR provides bip-0375/bip375_test_vectors.json and a reference bip-0375/validator/validate_psbt.py for validating Sending Silent Payments with PSBTs. PSBTs are validated against v2 requirements with BIP-375 rules (building on BIP-352 silent payment derivation and BIP-374 DLEQ proofs).

Changes since last force-push:

Add vendored dependencies in bip-0375/deps:
- secp256k1lab (ECC operations)
- bitcoin_test (PSBT parsing adapted from Bitcoin Core test framework)
Implement 4-stage sequential PSBT validation: structure, ECDH coverage + DLEQ correctness, input eligibility, and output script verification
Expanded test vector coverage:
- mixed + ineligible inputs
- output script validation with same scan key / spend key, same scan / different spend key, different scan key
- introduce P2TR inputs
Add test vector version field (starting at 1.1)
Update BIP-0375 Test Vectors section
Added a Changelog and Version header
Updated BIP text about eligible inputs

Feedback welcome @andrewtoth @achow101 @theStack

<details> <h2>Test Runner Output</h2>

Description: BIP-375 Test Vectors Version: 1.1

Invalid PSBTs: 22 psbt structure: missing PSBT_OUT_SP_V0_INFO field when PSBT_OUT_SP_V0_LABEL set psbt structure: incorrect byte length for PSBT_OUT_SP_V0_INFO field psbt structure: incorrect byte length for PSBT_IN_SP_ECDH_SHARE field psbt structure: incorrect byte length for PSBT_IN_SP_DLEQ field psbt structure: PSBT_GLOBAL_TX_MODIFIABLE field is non-zero when PSBT_OUT_SCRIPT set for sp output psbt structure: missing PSBT_OUT_SCRIPT field when sending to non-sp output ecdh coverage: P2TR input with NUMS internal key cannot derive sp output ecdh coverage: only one ineligible P2SH multisig input when PSBT_OUT_SCRIPT set for sp output ecdh coverage: missing PSBT_IN_SP_ECDH_SHARE field for input 0 when PSBT_OUT_SCRIPT set for sp output ecdh coverage: missing PSBT_IN_SP_DLEQ field for input when PSBT_IN_SP_ECDH_SHARE set ecdh coverage: missing PSBT_GLOBAL_SP_DLEQ field when PSBT_GLOBAL_SP_ECDH_SHARE set ecdh coverage: invalid proof in PSBT_IN_SP_DLEQ field ecdh coverage: invalid proof in PSBT_GLOBAL_SP_DLEQ field ecdh coverage: missing PSBT_IN_BIP32_DERIVATION field for input when PSBT_IN_SP_DLEQ set ecdh coverage: output 1 missing ECDH share for scan key with one input / three sp outputs (different scan keys) ecdh coverage: input 1 missing ECDH share for output 1 with two inputs / two sp outputs (different scan keys) ecdh coverage: input 1 missing ECDH share for scan key with two inputs / one sp output input eligibility: segwit version greater than 1 in transaction inputs with sp output input eligibility: non-SIGHASH_ALL signature on input with sp output output scripts: PSBT_OUT_SCRIPT does not match derived sp output output scripts: two sp outputs (same scan / different spend keys) not sorted lexicographically by spend key output scripts: k values assigned to wrong output indices with three sp outputs (same scan / spend keys)

Valid PSBTs: 19 can finalize: one P2PKH input single-signer can finalize: two inputs single-signer using global ECDH share can finalize: two inputs single-signer using per-input ECDH shares can finalize: two inputs / two sp outputs with mixed global and per-input ECDH shares can finalize: one input / one sp output with both global and per-input ECDH shares can finalize: three sp outputs (different scan keys) with multiple global ECDH shares 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: two sp outputs - output 0 uses label=3 / output 1 uses label=1 can finalize: two inputs using per-input ECDH shares - only eligible inputs contribute shares (P2SH excluded) can finalize: two inputs using global ECDH share - only eligible inputs contribute shares (P2SH excluded) can finalize: two mixed input types - only eligible inputs contribute ECDH shares (NUMS internal key excluded) can finalize: three sp outputs (same scan key) - each output has distinct k value can finalize: three sp outputs (same scan key) / two regular outputs - k values assigned independently of output index in progress: two P2TR inputs, neither is signed in progress: one P2TR input / one sp output with no ECDH shares when PSBT_OUT_SCRIPT field is not set in progress: two inputs / one sp output, input 1 missing ECDH share when PSBT_OUT_SCRIPT field is not set in progress: one input / two sp outputs, input 0 missing ECDH share for output 0 when PSBT_OUT_SCRIPT field is not set in progress: large PSBT with nine mixed inputs / six outputs - some inputs signed

Summary: 41 passed, 0 failed

</details>

Test vector generator is available in an external repo

jonatack added the label Proposed BIP modification on Nov 27, 2025

jonatack added the label Pending acceptance on Nov 27, 2025

macgyver13 force-pushed on Dec 1, 2025

macgyver13 force-pushed on Dec 3, 2025

macgyver13 force-pushed on Dec 5, 2025

macgyver13 force-pushed on Jan 8, 2026

in bip-0375/test_runner.py:37 in 61d0c7bd80 outdated

  32 | +        # Decode PSBT
  33 | +        psbt_data = base64.b64decode(psbt_b64)
  34 | +
  35 | +        # Check magic bytes
  36 | +        if len(psbt_data) < 5 or psbt_data[:5] != b"psbt\xff":
  37 | +            return False, "Invalid PSBT magic"

nymius commented at 7:29 PM on January 14, 2026:

This check is also in parse_psbt_structure. I would keep it only in one of both places.

in bip-0375/parser.py:61 in 61d0c7bd80 outdated

  56 | +            value_data = data[offset : offset + value_len]
  57 | +            offset += value_len
  58 | +
  59 | +            # Extract field type and handle key-value pairs
  60 | +            if key_data:
  61 | +                field_type = key_data[0]

nymius commented at 7:38 PM on January 14, 2026:

The extraction of field_type from key_data is odd. I would use de-structure assignment to keep them separated when assigning key_data, and also use the names stated in BIP 174, e.g.:

key_type, *key_data = data[offset : offset + key_len]

in bip-0375/validator.py:136 in 45106322ef

 131 | +            witness_utxo = input_fields[PSBTFieldType.PSBT_IN_WITNESS_UTXO]
 132 | +            if check_invalid_segwit_version(witness_utxo):
 133 | +                return False, f"Input {i} uses segwit version > 1 with silent payments"
 134 | +
 135 | +    # Eligible input type requirement
 136 | +    # When silent payment outputs exist, ALL inputs must be eligible types

nymius commented at 8:58 PM on January 14, 2026:

What does ALL inputs must be eligible types mean in this context? This is checking all inputs are valid for shared secret derivation, which is not a condition all inputs must fulfill in order to create a silent payment transaction.

macgyver13 commented at 12:11 AM on January 16, 2026:

Good catch - will address in the next revision

in bip-0375/validator.py:194 in 45106322ef

 189 | +        if PSBTFieldType.PSBT_OUT_SP_V0_INFO not in output_fields:
 190 | +            continue
 191 | +
 192 | +        sp_info = output_fields[PSBTFieldType.PSBT_OUT_SP_V0_INFO]
 193 | +        if len(sp_info) != 66:
 194 | +            continue

nymius commented at 1:43 PM on January 15, 2026:

Shouldn't this be a validation error?

nymius commented at 1:47 PM on January 15, 2026:

I see, you're doing validation before. Ignore this comment.

in bip-0375/test_vectors.json:144 in 45106322ef

 139 | +        }
 140 | +      ],
 141 | +      "comment": "Silent payment outputs require SIGHASH_ALL signatures only"
 142 | +    },
 143 | +    {
 144 | +      "description": "Mixed segwit versions with silent payments",

nymius commented at 6:05 PM on January 15, 2026:

I would prefer explicitness rather than conciseness in test case descriptions: Input with segwit script version greater than 1, even if it is more verbose.

in bip-0375/test_vectors.json:145 in 45106322ef

 140 | +      ],
 141 | +      "comment": "Silent payment outputs require SIGHASH_ALL signatures only"
 142 | +    },
 143 | +    {
 144 | +      "description": "Mixed segwit versions with silent payments",
 145 | +      "psbt": "cHNidP8B+wQCAAAAAQIEAgAAAAEEBAEAAAABBQQBAAAAAQYBAwABDiCuv6p7LnQnsTi6F7UesBJ3TJOXBoHuPhb2Y3hjUklAJAEPBAAAAAABASughgEAAAAAACJSIIYiz2yIzTx5hSOFG+T1WYNgEYY+sDBYObtzXueh9KPpARAE/v///yIGA9NX98BxjyR44/2PjMwnKd3YwMyusfArGBpvRNQ7n42NBAAAAAABAwQBAAAAIh0C0Cn/lt4svPeCvkNZxIYg6pK83WvvAyuVFYuRoWk/tPghAlUWTnkm1Q1SoJ/5kGR6XpXB2xv8aKYW+8LaITkn+Yv/Ih4C0Cn/lt4svPeCvkNZxIYg6pK83WvvAyuVFYuRoWk/tPhAwdZ/OHiCv4F5FeoVgh1k1bODXB/AXFWM49gkkqF9kIwQSH27m93BCAyMLZwZcbJmCDxpBU4iGT8kQSisZnN+YAABAwgYcwEAAAAAAAEEIlEgIZ6/eW18O5peg4tLa+KXfHTrjWr+b09YgAaz1sNh63wBCUIC0Cn/lt4svPeCvkNZxIYg6pK83WvvAyuVFYuRoWk/tPgCTVGDU/S9GNdpz2j/Yu8QZptwhiRrCmQD/le95JIRRIsA",

nymius commented at 6:08 PM on January 15, 2026:

I wasn't able to decode this psbt as it is using bitcoin-cli, have you?

P.S.: I converted to hex and was able to decode, but it feels as something was off with bitcoin-cli.

macgyver13 commented at 8:46 PM on January 15, 2026:

First thank you for the review!
Starting with this comment first, will be able to look at the rest over the next few days.

I had not tested version 2 PSBTs against bitcoin core but there is a version limitation based on my quick scan of psbt.h

src/psbt.h:L79-80 defines PSBT_HIGHEST_VERSION = 0
src/psbt.h:L1315-1317

if (*m_version > PSBT_HIGHEST_VERSION) {
    throw std::ios_base::failure("Unsupported version number");
}

nymius commented at 1:14 PM on January 16, 2026:

Obviously, if core doesn't support BIP 370, then why bitcoin-cli should decode it... well, why not? I overlooked this, thanks!

in bip-0375/test_vectors.json:510 in 45106322ef

 505 | +          "is_silent_payment": true,
 506 | +          "sp_info": "02d029ff96de2cbcf782be4359c48620ea92bcdd6bef032b95158b91a1693fb4f8024d518353f4bd18d769cf68ff62ef10669b7086246b0a6403fe57bde49211448b",
 507 | +          "sp_label": null
 508 | +        }
 509 | +      ],
 510 | +      "comment": "Output script doesn't match BIP-352 computed address"

nymius commented at 6:15 PM on January 15, 2026:

What's the difference between comment and description? Could we keep only one?

macgyver13 commented at 12:15 AM on January 16, 2026:

I agree these test vectors don't need both - will consolidate in next revision

nymius commented at 6:27 PM on January 15, 2026: contributor

cACK 45106322ef3b809e61a13d9b817eb38193fa19fa

I haven't been able to decode the PSBT's using bitcoin-cli decodepsbt in a per test basis. Did you have any issues?
I would consider copying the approach taken in bitcoin/bips#2084, and use secp256k1lab here.
As each PSBT change is reflected in BIP 174, maybe is worth moving the parsing, fields and PSBT validation logic to BIP 174 directory, and keep the role logic of each protocol on its own directory, like here.

macgyver13 commented at 9:23 PM on January 15, 2026: contributor

cACK 4510632

I haven't been able to decode the PSBT's using bitcoin-cli decodepsbt in a per test basis. Did you have any issues?

Details in comment above - PSBT v2 not supported

I would consider copying the approach taken in #2084, and use secp256k1lab here.

I agree that approach is better than the current bip-0374 import. The current import process would have to adapt to that change regardless. I'll put that on the list for the next revision.

As each PSBT change is reflected in BIP 174, maybe is worth moving the parsing, fields and PSBT validation logic to BIP 174 directory, and keep the role logic of each protocol on its own directory, like here.

Interesting idea. Are you suggesting a storage change for this PR or expand the scope of the PSBT parsing, fields and validation to v0 and other v2 fields and move to other BIPS directories?

nymius commented at 1:17 PM on January 16, 2026: contributor

Interesting idea. Are you suggesting a storage change for this PR or expand the scope of the PSBT parsing, fields and validation to v0 and other v2 fields and move to other BIPS directories?

I'm suggesting the second one, but as it seems to involve more components, I wouldn't pursue it in this PR.

macgyver13 commented at 9:48 PM on January 22, 2026: contributor

This PR depends on #2084.

Converting to draft while dependent work is evaluated. In parallel reworking a few test cases for better coverage of spec. ie. (ECDH share coverage and unique identification)

macgyver13 marked this as a draft on Jan 22, 2026

murchandamus commented at 11:14 PM on February 27, 2026: member

@macgyver13: It looks like your dependency moved forward. Could you take another look whether this is ready for an update?

macgyver13 renamed this:
~~BIP375: Add test vectors + runner~~
BIP375: Add test vectors + validation runner
on Mar 9, 2026

macgyver13 renamed this:
~~BIP375: Add test vectors + validation runner~~
BIP375: Add test vectors + validator
on Mar 9, 2026

macgyver13 force-pushed on Mar 18, 2026

BIP-375: Add bitcoin test framework as dependency - deps/bitcoin_test a8aa5ed548

Squashed 'bip-0375/deps/secp256k1lab/' content from commit 44dc4bd

git-subtree-dir: bip-0375/deps/secp256k1lab
git-subtree-split: 44dc4bd893b8f03e621585e3bf255253e0e0fbfb

eedb7f9a31

Merge commit '96000a36c22f6528e834c54f0d115db675198e57' as 'bip-0375/deps/secp256k1lab' e70510193f

macgyver13 force-pushed on Mar 23, 2026

macgyver13 marked this as ready for review on Mar 23, 2026

macgyver13 commented at 10:43 PM on March 23, 2026: contributor

Ready for review again — appreciate the patience. Main additions since marking as draft are in the PR description above.

Will need feedback on the two open questions before this PR can be finalized.

murchandamus commented at 1:14 AM on March 25, 2026: member

I see no review by the BIP owners so far. Are you talking to them out of band, or should the be requested here?

andrewtoth commented at 1:17 AM on March 25, 2026: contributor

Sorry, haven't had a chance to look at this yet. Will review shortly.

macgyver13 commented at 1:48 AM on March 25, 2026: contributor

I see no review by the BIP owners so far. Are you talking to them out of band, or should the be requested here?

theStack mentioned he would take a look soon when we spoke last week.

andrewtoth commented at 9:46 PM on March 28, 2026: contributor

This is awesome, thank you!

BIP-375 allows PSBT_OUT_SCRIPT field to be optional if PSBT_OUT_SP_V0_INFO field is present for an output, should PSBT_OUT_SCRIPT field with empty value_data be considered valid? - I prefer invalid

This seems out of scope for BIP375. I believe if present, the PSBT_OUT_SCRIPT should have a valid script. So, empty is invalid.

Should BIP text be clarified for Computing the Output Scripts as follows? - added 'from eligible inputs'

Or perhaps the BIP can be modified to prohibit adding a share for ineligible inputs. I think that would fix this ambiguity and also catch issues sooner. Wdyt?

I don't see a test case for a P2PKH input, can we add one? Also, a test case of a global ECDH share (so signer has all keys) for a mix of eligible and ineligible inputs could be added.

jvgelder referenced this in commit 80e7c117b9 on Mar 30, 2026

macgyver13 force-pushed on Mar 30, 2026

macgyver13 commented at 8:39 PM on March 30, 2026: contributor

This is awesome, thank you!

Appreciate the review, happy to help!

BIP-375 allows PSBT_OUT_SCRIPT field to be optional if PSBT_OUT_SP_V0_INFO field is present for an output, should PSBT_OUT_SCRIPT field with empty value_data be considered valid? - I prefer invalid

This seems out of scope for BIP375. I believe if present, the PSBT_OUT_SCRIPT should have a valid script. So, empty is invalid.

I agree that this is out of scope for BIP-375. Removed: psbt structure: empty PSBT_OUT_SCRIPT field when sending to non-sp output

Should BIP text be clarified for Computing the Output Scripts as follows? - added 'from eligible inputs'

Or perhaps the BIP can be modified to prohibit adding a share for ineligible inputs. I think that would fix this ambiguity and also catch issues sooner. Wdyt?

I prefer the prohibition of shares for ineligible inputs - it's the cleanest way to handle validation based on my experience. I have updated the Signer section of the BIP to reflect this; let me know what you think. Modified test name only: ~~output scripts: P2TR input with NUMS internal key cannot derive sp output~~ ecdh coverage: P2TR input with NUMS internal key cannot derive sp output

I don't see a test case for a P2PKH input, can we add one? Also, a test case of a global ECDH share (so signer has all keys) for a mix of eligible and ineligible inputs could be added.

Modified one of the many P2WPKH test to use P2PKH instead to give more coverage. ~~can finalize: one input single-signer~~ can finalize: one P2PKH input single-signer

Good idea on global ECDH share with a mix of eligible and ineligible inputs -- this new test caught an invalid assumption in my Rust validator implementation. Added: can finalize: two inputs using global ECDH share - only eligible inputs contribute shares (P2SH excluded) Modified test name only: ~~can finalize: two mixed input types - only eligible inputs contribute ECDH shares (P2SH excluded)~~ can finalize: two inputs using per-input ECDH shares - only eligible inputs contribute shares (P2SH excluded)

andrewtoth commented at 9:39 PM on March 30, 2026: contributor

I prefer the prohibition of shares for ineligible inputs - it's the cleanest way to handle validation based on my experience. I have updated the Signer section of the BIP to reflect this; let me know what you think.

Thinking about this more, this is backwards incompatible change. So, modifying the BIP in this way needs a mailing list post and some time to gather feedback from existing implementers.

macgyver13 force-pushed on Mar 31, 2026

macgyver13 force-pushed on Apr 1, 2026

BIP-375: add test vector file 8b46bd63b5

BIP-375: add BIP375PSBT extension classes

BIP375PSBT (a PSBT subclass that deserializes into BIP375PSBTMap instances)
BIP375PSBTMap (a PSBTMap subclass with BIP-375 field access helpers)

fc9918d8c0

BIP-375: add test_runner and validate PSBT structure

Implement psbt structure checks
Add test_runner.py for processing test vectors

66053ae879

BIP-375: add ecdh coverage validation

Add deps/dleq.py (Adapted from bip-0374/reference.py)
Extract pubkey from PSBT inputs 
- PSBT_IN_BIP32_DERIVATION
- PSBT_IN_WITNESS_UTXO for P2TR
Add script type helpers
- bip352 input eligibility helpers

6a91f88030

BIP-375: add input eligibility validation

Verify segwit version >1 not used if silent payment outputs present (bip352)
Verify SIGHASH_ALL requirement

ab30224051

BIP-375: add output scripts validation

Add support for computing bip352 output scripts
Extract ECDH shares and public key from PSBT and aggregate both if necessary
Refactor validate_ecdh_coverage to use collect_input_ecdh_and_pubkey

fb105b7e51

BIP-375: update documentation

Update Test Vectors section
Add README.md to explain validation tooling and dependencies

cf7a16a5f9

BIP-375: address review feedback

correctly label witness_utxo vs non_witness_utxo key in supplementary inputs

Summary of test vector changes:
removed test: 
- psbt structure: empty PSBT_OUT_SCRIPT field when sending to non-sp output
modified test:
- ecdh coverage: only one ineligible P2SH multisig input when PSBT_OUT_SCRIPT set for sp output
- can finalize: one P2PKH input single-signer
- can finalize: two inputs using per-input ECDH shares - only eligible inputs contribute shares (P2SH excluded)
added test: 
- can finalize: two inputs using global ECDH share - only eligible inputs contribute shares (P2SH excluded)

7b4f1d6b4e

BIP-375: clarify eligible input restriction in Signer text 9536c863cf

BIP-375: clarify eligible inputs restriction in Computing the Output Scripts text 6295a70405

BIP-375: skip ineligible inputs when combining ecdh shares

add fake ecdh share and dleq proof to P2SH input for valid test: two inputs using per-input ECDH shares - only eligible inputs contribute shares (P2SH excluded)

remove unused return string from is_input_eligible

897455dab7

in bip-0375.mediawiki:180 in 4536c175fb outdated

 176 | @@ -177,7 +177,7 @@ All rules must be followed from PSBTv2 for this role. If there are any outputs w
 177 |  If any input is spending an output with script using Segwit version > 1, the Signer must fail.
 178 |  
 179 |  For each output with PSBT_OUT_SP_V0_INFO set, the Signer should:
 180 | -* Compute and set an ECDH share and DLEQ proof for each input it has the private key for, or set a global ECDH share and DLEQ proof if it has private keys for all eligible inputs.
 181 | +* Compute and set an ECDH share and DLEQ proof for each eligible input it has the private key for, or set a global ECDH share and DLEQ proof if it has private keys for all eligible inputs.

macgyver13 commented at 5:21 PM on April 1, 2026:

After reflecting on the previous version of the Signer text change I realized I had inserted a 'must' bullet into a 'should' section. I think the addition of eligible as a 'should' resolves the ambiguity and I don't see this as a backward incompatible change.

I chose to isolate this change in a single commit for easy review and linkage if necessary. @andrewtoth - If you think a Mailing List Update is warranted let me know.

andrewtoth commented at 11:25 PM on April 2, 2026:

Thanks for adding the test cases.

This is a good change to the spec :+1:.

After thinking about this more as well, I think my suggestion is not necessary and your proposal to add "from eligible inputs" to the "Computing the Output Scripts" section is the right approach.

This change here directs signers to not produce shares for ineligible inputs, but explicitly directing the consumer to also ignore shares from ineligible inputs makes the spec robust from both sides.

I don't believe either change is backwards incompatible. The producer side already says "for each eligible input" in the detailed ECDH procedure, so no conforming implementation should be producing shares for ineligible inputs in the first place. Can we do both?

macgyver13 commented at 1:55 AM on April 3, 2026:

Your reasoning for including the eligible inputs clarification in both areas of BIP text makes sense to me. The last update includes the change to the "Computing the Output Scripts" section.

That clears up the last open question for me. Thank you.

andrewtoth commented at 1:39 PM on April 3, 2026:

Can we have a test vector that validates a PSBT that has shares on both eligible and ineligible inputs? As per the spec now, this test should pass by ignoring the shares on ineligible inputs.

Producers should not add these shares, but the consumer should also not fail if they are present.

macgyver13 commented at 1:47 PM on April 3, 2026:

Here is a snip from executing python test_runner.py -vv

can finalize: two inputs using per-input ECDH shares - only eligible inputs contribute shares (P2SH excluded)
  All checks passed
can finalize: two inputs using global ECDH share - only eligible inputs contribute shares (P2SH excluded)
  All checks passed
can finalize: two mixed input types - only eligible inputs contribute ECDH shares (NUMS internal key excluded)
  All checks passed

Unless I am not understanding your question each of these valid tests demonstrates computing output scripts by using just eligible inputs.

andrewtoth commented at 2:28 PM on April 3, 2026:

Sorry for not being clear. These lines in the validator fail a PSBT if an ineligible input has a share set:

                if not is_eligible and ecdh_share:
                    return (
                        False,
                        f"Input {i} has ECDH share but is ineligible for silent payments",
                    )

But, that is against spec. If an ineligible input has a share it should just be ignored. So, we should remove this check, and have an explicit test where a valid PSBT has an extra share of dummy data attached to an ineligible input.

macgyver13 commented at 1:00 AM on April 6, 2026:

This valid test now includes dummy ecdh shares and dleq proof for the ineligible input: can finalize: two inputs using per-input ECDH shares - only eligible inputs contribute shares (P2SH excluded)

macgyver13 force-pushed on Apr 6, 2026

murchandamus commented at 9:02 PM on April 6, 2026: member

cc: @theStack, @achow101

BIP-375: fix label byte order used by labelhash

Test vectors with labels now use big-endian byte order instead of little-endian, matching BIP-352 specification

Summary of test vector changes:
- psbt structure: missing PSBT_OUT_SP_V0_INFO field when PSBT_OUT_SP_V0_LABEL set
- can finalize: one P2WPKH input / two mixed outputs - labeled sp output and BIP 32 change
- can finalize: two sp outputs - output 0 uses label=3 / output 1 uses label=1

b217897a62

andrewtoth commented at 1:23 AM on April 11, 2026: contributor

ACK b217897a628e3d5db369497d2697f76e5bab7f4d

murchandamus commented at 10:41 PM on April 13, 2026: member

Since this PR has been signed off by one author, I will slate this PR for merging. @theStack, @achow101, please take a look in the next few days if you want to review before merging.

macgyver13 commented at 5:10 PM on April 15, 2026: contributor

Since this PR has been signed off by one author, I will slate this PR for merging. @theStack, @achow101, please take a look in the next few days if you want to review before merging.

Thanks! I have held off on rebasing during review to keep commits stable. Could you give me a heads up before merging so I can do a final cleanup pass?

murchandamus commented at 6:18 PM on April 15, 2026: member

@macgyver13: I usually do a merge commit when the commits are well-structured like here, and I squash the commits when it’s a topsy-turvy collection of omnibus commits and typo fix commits. I was gonna merge this PR before the end of the week if nothing else were to happen, but I’m happy to wait for your cue that it’s in the shape you want it.

in bip-0375.mediawiki:252 in b217897a62 outdated

 248 | @@ -249,7 +249,156 @@ Silent payment capable PSBTs are backwards compatible with PSBTv2 once all outpu
 249 |  
 250 |  ==Test Vectors==
 251 |  
 252 | -Todo
 253 | +A [[bip-0375/bip375_test_vectors.json|collection of test vectors in JSON format]] is provided. Each test vector contains a base64-encoded PSBT string, which alone can be used to verify sending Silent Payments with PSBTs.

jonatack commented at 7:28 PM on April 15, 2026:

Consider adding a changelog to the BIP (as done in this pull for secp256k1lab) with a minor release update for adding the test vectors.

murchandamus commented at 8:46 PM on April 15, 2026:

Slight amendment: BIP3 recommends bumping PATCH for a change such as adding test vectors. The Changelog section is also optional before a BIP is advanced to Complete. Should you add a Changelog, please also add a Version header.

macgyver13 commented at 4:31 PM on April 16, 2026:

Changelog Section added - let me know if I need to make more tweaks

andrewtoth commented at 3:52 PM on April 16, 2026: contributor

cc @craigraw I believe you implemented BIP375 in sparrow wallet.

macgyver13 commented at 4:34 PM on April 16, 2026: contributor

@macgyver13: I usually do a merge commit when the commits are well-structured like here, and I squash the commits when it’s a topsy-turvy collection of omnibus commits and typo fix commits. I was gonna merge this PR before the end of the week if nothing else were to happen, but I’m happy to wait for your cue that it’s in the shape you want it. @murchandamus Thank you for the perspective. I am comfortable leaving the commits as-is based on your feedback. I consider this PR ready for merge when you see fit.

in bip-0375.mediawiki:408 in d447a197fb

 399 | @@ -400,6 +400,18 @@ Use the provided [[bip-0375/test_runner.py|test runner]] to validate each test v
 400 |  | large PSBT with nine mixed inputs / six outputs - some inputs signed
 401 |  |}
 402 |  
 403 | +== Changelog ==
 404 | +
 405 | +To help implementers understand updates to this document, we attach a version number that resembles ''semantic versioning'' (<code>MAJOR.MINOR.PATCH</code>).
 406 | +The <code>MAJOR</code> version is incremented if changes to the BIP are introduced that are incompatible with prior versions.
 407 | +The <code>MINOR</code> version is incremented whenever the inputs or the output of an algorithm changes in a backward-compatible way or new backward-compatible functionality is added.
 408 | +The <code>PATCH</code> version is incremented for other changes that are noteworthy (bug fixes, test vectors, important clarifications, etc.).

jonatack commented at 5:01 PM on April 16, 2026:

No need for these lines of boilerplate. (Can squash the removal commit into the last commit d447a19 that adds them.)

jonatack commented at 5:04 PM on April 16, 2026: member

so I can do a final cleanup pass @macgyver13 I agree the squash and merge commits could be cleaned up, among any others you had in mind.

macgyver13 force-pushed on Apr 16, 2026

in bip-0375.mediawiki:12 in b186b39d6b

murchandamus commented at 6:00 PM on April 16, 2026:

Please also add the Version header corresponding to the Changelog in the Preamble:

 Discussion: https://groups.google.com/g/bitcoindev/c/5G5wzqUXyk4
+Version: 0.1.1
 Requires: 352, 370, 374

murchandamus commented at 6:02 PM on April 16, 2026: member

LGTM, one amendment requested

BIP-375: add changelog section

Add Changelog section
Begin with version 0.1.0 as this BIP is Draft phase

8c0a9bfa57

macgyver13 force-pushed on Apr 16, 2026

murchandamus commented at 8:08 PM on April 16, 2026: member

Changes since [@andrewtoth](/bitcoin-bips/contributor/andrewtoth/)’s ACK are only the addition of the Changelog and Version header.

andrewtoth commented at 10:44 PM on April 16, 2026: contributor

ACK 8c0a9bfa57c515205fa07851128d758ef72e433b

jonatack removed the label Pending acceptance on Apr 16, 2026

in bip-0375.mediawiki:407 in 8c0a9bfa57

 403 | +|}
 404 | +
 405 | +== Changelog ==
 406 | +
 407 | +* '''0.1.1''' (2026-04-16):
 408 | +** Add test vectors and reference for validating Sending Silent Payments with PSBTs.

jonatack commented at 11:44 PM on April 16, 2026:

There are also updates to the BIP about eligible inputs / restrictions. Should that be mentioned?

jonatack commented at 11:48 PM on April 16, 2026:

Nit (not a blocker for this already substantial and BIP author approved improvement):

Referencing the above comment as well as https://github.com/bitcoin/bips/pull/2046/changes#r3089267494, it seems to me that those updates, along with the new addition of the Valid PSBTs section, might suggest incrementing a minor, rather than patch, version (e.g., to 0.2.0), if the specification is considered to be modified/extended (in a backward-compatible way).

(Both of these comments can be handled in a follow-up PR.)

murchandamus commented at 12:47 AM on April 17, 2026:

I read the addition of "eligible" as a simple clarification, because only some inputs are relevant to Silent Payments.

jonatack commented at 11:54 PM on April 16, 2026: member

Appended the following to the PR description (@macgyver13 feel free to improve/tweak):

- Added a Changelog and Version header
- Updated BIP text about eligible inputs

murchandamus merged this on Apr 17, 2026

murchandamus closed this on Apr 17, 2026