Feat/sp sending by jvgelder · Pull Request #496 · caravan-bitcoin/caravan

jvgelder · 2026-03-24T21:05:40Z

What kind of change does this PR introduce?

feature

Issue Number:

Fixes #467

Summary

Implements sending to silent payment Bip352 address via psbtv2 bip375.

Still work in progress but gives some insights in how I plan to integrate.

TODO:

Improve test coverage

Does this PR introduce a breaking change?

Should not introduce any breaking changes

Checklist

I have tested my changes thoroughly.
I have added or updated tests to cover my changes (if applicable).
I have verified that test coverage meets or exceeds 95% (if applicable).
I have run the test suite locally, and all tests pass.
I have written tests for all new changes/features
I have followed the project's coding style and conventions.
I have created a changeset to document my changes (npm run changeset)

Other information

Have you read the contributing guide?

Yes

Added encoders and decoders for the given silent payment fields. Since we add new fields that are not allowed by v0 we also need to delete them when converting to v0.

Allow the user to set and get a silentpayment object instead of a script. As per BIP375 we need to make sure there is either an OUPUT_SCRIPT or PSBT_OUT_SP_V0_INFO updated getter, validation and unsignedtx accordingly.

- Add silentpayment.ts with pure BIP352 crypto primitives: eligibleIndices, sumECDHShares, computeInputHash, deriveSilentPaymentOutput, bip352TaggedHash - Add computeSilentPaymentOutputScripts() to PsbtV2 (Signer role) implementing BIP375 output script derivation from ECDH shares

changeset-bot · 2026-03-24T21:05:45Z

🦋 Changeset detected

Latest commit: 5a12230

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@caravan/psbt	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

vercel · 2026-03-24T21:05:47Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
caravan-coordinator	Ready	Preview, Comment	Jun 23, 2026 3:55pm

Return empty string instead of changing the signature, feels vary shaky.

@macgyver13

Credits to @macgyver13 taken from bitcoin/bips#2046

- validate SegWit version range - use full compressed spend keys in derivation - enforce BIP352 scalar validity checks

Instead of having multiple places where we define checks call the proper assert functions. Also added a missing Bspend check.

Our assert was contained the wrong message (mentioned k instead of m). Also added a separate assert for 0 < k < Kmax (2323) output index check.

github-actions · 2026-05-02T04:43:37Z

This pull request has been inactive for 30 days and has been marked as stale. It will be closed in 7 days if no further activity occurs. To keep this PR open, add the "long-lived" label or comment on it.

jvgelder · 2026-05-02T10:28:44Z

@Legend101Zz could you have a look ?

Legend101Zz · 2026-05-04T03:15:50Z

@Legend101Zz could you have a look ?

Hi @jvgelder — really sorry for the delay. I hadn’t had a chance to review this closely yet, but I’ll start going through it today or tomorrow. Thanks a lot for the PR!

jvgelder · 2026-05-04T09:47:33Z

@Legend101Zz could you have a look ?

Hi @jvgelder — really sorry for the delay. I hadn’t had a chance to review this closely yet, but I’ll start going through it today or tomorrow. Thanks a lot for the PR!

Thanks note this is the first part after this we should add the DLEQ proofs which I think should be part of this PR.

After that we need to add the actual usage of this code to the wallet? to allow users to specify the silent payment address they want to send to (and thus address decoding too)

Legend101Zz · 2026-05-15T18:46:51Z

@Legend101Zz could you have a look ?

Hi @jvgelder — really sorry for the delay. I hadn’t had a chance to review this closely yet, but I’ll start going through it today or tomorrow. Thanks a lot for the PR!

Thanks note this is the first part after this we should add the DLEQ proofs which I think should be part of this PR.

After that we need to add the actual usage of this code to the wallet? to allow users to specify the silent payment address they want to send to (and thus address decoding too)

Hi @jvgelder thanks for the heads up ... let me get back to you once I go through the PR , finally got the chance to review it ... thanks for your patience :)

Removed function overhead. Moved ProjectivePoint for reusability.

We previously did not check dleq so we disabled those tests now we do so we reenable them.

Legend101Zz

@jvgelder Thanks for the patience here, and thanks for pushing this PR forward. I finally got time to do an initial deeper review.

Overall, this looks like a solid PSBT-layer foundation for BIP375/Silent Payments. The current version is much stronger than the first pass I looked at :)

The main things I think still need attention before this is safe to merge are:

enforce SIGHASH_ALL when adding partial signatures to a PSBT with Silent Payment outputs
verify that BIP32 derivation pubkeys used for P2WPKH/P2SH-P2WPKH/P2PKH Silent Payment derivation actually match the prevout script
either fully support labeled Silent Payment outputs or reject/keep them non-final until label-aware verification exists

After this PSBT layer is correct, I think the next PRs should tackle the usable Caravan path: Silent Payment address decoding, coordinator PSBTv2 construction, clear input eligibility checks, signer/wallet handling for ECDH shares and DLEQ proofs, and a precise Taproot-support story, do you plan to have all those in this PR itself ?

Legend101Zz · 2026-05-25T04:07:16Z

        throw Error("PsbtV2 input hight locktime is gte 500000000.");
      }
    }
+    this.validateSilentPayments();


I think this needs one more BIP375 guard before signatures are accepted on a
silent-payment PSBT. validateSilentPayments() rejects explicit
PSBT_IN_SIGHASH_TYPE values that are not SIGHASH_ALL, but addPartialSig()
can still add a partial signature whose trailing sighash byte is SIGHASH_NONE
or SIGHASH_SINGLE when no PSBT_IN_SIGHASH_TYPE field is present.

Like , BIP375 says that if silent payment outputs are present, a signer must fail when
the sighash type is not SIGHASH_ALL , if no sighash type is provided, it must
sign using SIGHASH_ALL. The current code only uses handleSighashType() to
update modifiable flags after inserting the signature, so a non-ALL signature
can be serialized and reparsed successfully.

So should we reject this in addPartialSig() or in handleSighashType() when
this.hasSilentPaymentOutputs is true? A regression test should cover a silent
payment PSBT where PSBT_OUT_SCRIPT is already computed and addPartialSig()
is called with a signature ending in 0x02 or 0x03.

Added a check https://github.com/caravan-bitcoin/caravan/pull/496/changes#diff-cefa8ce7b34d9637fc1bfd4f54edc413efd6e74068ebf1e97e4ab8cad063ee2fR1683-R1699

Legend101Zz · 2026-05-25T04:10:09Z

+        pubkeyBytes = getTaprootOutputKeyFromWitnessUtxo(witnessUtxo);
+      }
+
+      if (!pubkeyBytes) {


So for P2WPKH, P2SH-P2WPKH, and P2PKH inputs, this uses the first
PSBT_IN_BIP32_DERIVATION key as the input public key for DLEQ verification
and input_hash right, but I do not see a check that this pubkey actually matches
the prevout script.

That leaves a dangerous case: like a PSBT can spend a P2WPKH prevout whose script
hash commits to pubkey A, but include a BIP32 derivation key for pubkey B. The
DLEQ proof can be valid for B, and the SP output script can be computed from B,
while the final transaction is signed with A. The transaction can still be
consensus-valid, but the receiver scans using the actual input pubkey A and
will not find the output.

This may not affect Caravan's current classic multisig coordinator path directly,
because P2WSH/P2SH-P2WSH multisig inputs are not BIP352 shared-secret inputs.
But since this PR is adding generic BIP375 support in @caravan/psbt, I think
the P2WPKH/P2SH-P2WPKH/P2PKH public-key path should still verify that the
PSBT_IN_BIP32_DERIVATION pubkey matches the prevout script before using it for
DLEQ verification and input_hash.

Otherwise, a PSBT can provide a derivation pubkey B, generate a valid DLEQ proof
and SP output for B, while the actual input spends a prevout committed to pubkey
A. The final transaction can still be valid, but receivers scan using the actual
input pubkey revealed on-chain, so they would derive with A and miss the output.

see new vectors : https://github.com/caravan-bitcoin/caravan/pull/496/changes#diff-bc1ee7a599cdf1acc66b16e760460b1be919fd420a1484423afc522a5510d3ffR679-R713
thanks to macgyver13

if you have more vectors you can think of :) https://github.com/macgyver13/bip375-test-generator/commits/bip32-more-cases/

Legend101Zz · 2026-05-25T04:11:22Z

+
+    // Only non-labeled SP outputs can be recomputed from public PSBT data.
+    // Labeled outputs require recipient-side label state / scan private key.
+    const computedSPScanKeys = new Set<string>();


I think labeled outputs need to be either fully verified or explicitly rejected
for now. Right now validation skips outputs that have PSBT_OUT_SP_V0_LABEL
when deciding which scan keys need ECDH coverage and output-script validation.
That means a labeled SP output with an arbitrary PSBT_OUT_SCRIPT can pass
validation once PSBT_GLOBAL_TX_MODIFIABLE is zeroed, even with no ECDH share
or DLEQ proof for that scan key.

This is especially risky because BIP375 uses labels for SP change verification.
If this implementation cannot derive or verify labeled outputs yet, I think the
safe behavior is to fail validation when a labeled SP output has a script, or to
keep it non-final/in-progress until label-aware verification exists. Otherwise
the PSBT layer can bless an output script that is not tied to the stored silent
payment data, what do you think ?

Just talked with @macgyver13 and the PSBT_OUT_SP_V0_LABEL is just there as a hint for the hardware wallet: hey the output address i sent you is actually one of our labeled addresses when you verify you need to derive it properly to arrive at the same address.

To clarify the scan will most likely always has to live in the coordinator otherwise it will be close to impossible to scan for your incoming payments. Hence the coordinator can actually also derive labeled address from the scan key.

jvgelder · 2026-05-26T12:12:43Z

@jvgelder Thanks for the patience here, and thanks for pushing this PR forward. I finally got time to do an initial deeper review.

Overall, this looks like a solid PSBT-layer foundation for BIP375/Silent Payments. The current version is much stronger than the first pass I looked at :)

Thanks a lot for taking the time to review it, this gives me some more energy to move it forward.

The main things I think still need attention before this is safe to merge are:
* enforce `SIGHASH_ALL` when adding partial signatures to a PSBT with Silent Payment outputs

Good one, wasn't sure if I should alter those functions but a simple assert (if silent output && sighash != All ) should suffice I guess.

* verify that BIP32 derivation pubkeys used for P2WPKH/P2SH-P2WPKH/P2PKH Silent Payment derivation actually match the prevout script

Il have a look.

* either fully support labeled Silent Payment outputs or reject/keep them non-final until label-aware verification exists

While we are at it we should support it in full :)

After this PSBT layer is correct, I think the next PRs should tackle the usable Caravan path: Silent Payment address decoding, coordinator PSBTv2 construction, clear input eligibility checks, signer/wallet handling for ECDH shares and DLEQ proofs, and a precise Taproot-support story, do you plan to have all those in this PR itself ?

I Might but just to manage the expectations a bit I am also working on various other projects, if we can get more people excited, I would direct more of my energy (and tokens) here ^^.
Would need some pointers on where to implement address en/decoding and how to change the UI so that it can handle silent payment output addresses.

Replace the first-BIP32-pubkey fallback with candidate pubkey recovery from BIP32 derivations, partial signatures, and finalized input scripts. Only pubkeys matching the spent output are used for DLEQ verification and input_hash recomputation, preventing SP outputs from being derived from a decoy key.

Add Silent Payment helpers that recover an input public key only when a candidate pubkey matches the prevout script. This prepares validation to reject PSBTs that provide decoy pubkeys for Silent Payment shares or DLEQ proofs.

Use only input pubkeys that match the spent prevout script when verifying silent payment DLEQ proofs and computing BIP352 input_hash. This prevents PSBTs from deriving silent payment outputs from a decoy pubkey while spending with a different key. Also tighten SP signing/validation guards for computed outputs, NUMS taproot script-path inputs, and non-SIGHASH_ALL partial signatures.

jvgelder · 2026-05-02T10:33:42Z

      ) {
        console.warn(
-          `Output ${i} is missing previous out script or amount. Skipping.`,
+          `Output ${i} is missing SP_INFO, script or amount. Skipping.`,


should have added SP_INFO instead of replaced previous out

jvgelder · 2026-06-10T21:26:49Z

-      indices.push(value.toString("hex"));
-    }
-    return indices;
+      if (!value) return "";


return "" and checking on empty string seems like a bad idea

would it be possible to maintain the throw when PSBT_OUT_SP_V0_INFO is not present in the output map.

yes changed it back

macgyver13

Thanks for getting the ball rolling on the silent payments PSBT integration!

macgyver13 · 2026-05-29T21:36:11Z

+  const eBytes = taggedHash(
+    "BIP0374/challenge",
+    Buffer.concat([
+      ABytes,
+      BBytes,
+      CBytes,
+      Buffer.from(G.toRawBytes(true)),
+      R1Bytes,
+      R2Bytes,
+      m,
+    ]),
+  );


tidy: function for dleqChallenge could be reused in verify too

macgyver13 · 2026-05-29T21:43:59Z

+  multiplyCompressedPoint,
+  verifyDLEQProof,
+} from "./dleq";
+import { verifySilentPaymentDLEQProof } from "./silentpayment";


nit: import not used

macgyver13 · 2026-05-30T19:41:14Z

+export function bip352TaggedHash(tag: string, data: Buffer): Buffer {
+  const tagHash = createHash("sha256").update(tag).digest();
+  return createHash("sha256")
+    .update(tagHash)
+    .update(tagHash)
+    .update(data)
+    .digest();
+}


duplicate taggedHash implementation in dleq.ts

macgyver13 · 2026-06-10T21:43:21Z

-      indices.push(value.toString("hex"));
-    }
-    return indices;
+      if (!value) return "";


would it be possible to maintain the throw when PSBT_OUT_SP_V0_INFO is not present in the output map.

Even though the version number is lower the tests should be newer.

- Created reusable taggedChallenge/tagged hash function (can be replaced with bitcoinJs tagged hash if needed) - Added verifyDleq proof for external use to prevent recalculation of points.

Instead of returning an empty string, throw error and handle it.

Previously removed to much readded previous out.

jvgelder added 4 commits March 24, 2026 14:34

chore(psbt): Add silent payment fields

81981ca

chore(psbt): Add silent payment fields

dcfc2a9

Added encoders and decoders for the given silent payment fields. Since we add new fields that are not allowed by v0 we also need to delete them when converting to v0.

chore(psbt): Add output functionality

8b2a8ab

Allow the user to set and get a silentpayment object instead of a script. As per BIP375 we need to make sure there is either an OUPUT_SCRIPT or PSBT_OUT_SP_V0_INFO updated getter, validation and unsignedtx accordingly.

vercel Bot had a problem deploying to Preview March 24, 2026 21:07 Failure

fix(psbt): Prevent creating breaking change with PSBT_OUT_SCRIPT

296fa75

Return empty string instead of changing the signature, feels vary shaky.

vercel Bot deployed to Preview March 24, 2026 21:47 View deployment

jvgelder added 3 commits March 30, 2026 15:32

chore(psbtv2): Added test vectors from BIP375

80e7c11

Credits to @macgyver13 taken from bitcoin/bips#2046

chore(psbtv2): Add validation

8f0df4b

fix(psbtv2): correct silent payment output derivation

0e57be0

- validate SegWit version range - use full compressed spend keys in derivation - enforce BIP352 scalar validity checks

vercel Bot deployed to Preview March 30, 2026 13:37 View deployment

chore(psbtv2): Replace checks with assert calls

23cff68

Instead of having multiple places where we define checks call the proper assert functions. Also added a missing Bspend check.

vercel Bot deployed to Preview March 30, 2026 13:47 View deployment

chore(psbtv2): Proper label and k checking

ea81977

Our assert was contained the wrong message (mentioned k instead of m). Also added a separate assert for 0 < k < Kmax (2323) output index check.

vercel Bot deployed to Preview March 31, 2026 09:52 View deployment

macgyver13 mentioned this pull request Apr 29, 2026

Unchained Capital Silent Payments + BIP-375 silent-payments/roadmap#58

Open

github-actions Bot added the stale label May 2, 2026

github-actions Bot removed the stale label May 3, 2026

jvgelder added 2 commits May 20, 2026 12:22

fix(caravan-psbt): harden BIP375 silent payment validation

1408cc2

feat(caravan-psbt): add BIP374 DLEQ proofs for silent payments

20b7395

vercel Bot had a problem deploying to Preview May 20, 2026 10:28 Failure

jvgelder added 2 commits May 20, 2026 14:58

chore(dleq): Cleanup functions

124ba9e

Removed function overhead. Moved ProjectivePoint for reusability.

chore(bip375): Enable all tests

e1f7cfd

We previously did not check dleq so we disabled those tests now we do so we reenable them.

fix(psbtv2): Fix nums check

8ee5f65

vercel Bot deployed to Preview May 20, 2026 13:01 View deployment

Legend101Zz suggested changes May 25, 2026

View reviewed changes

jvgelder added 6 commits June 5, 2026 17:10

test(caravan-psbt): update BIP375 vector fixtures

d97620a

fix(caravan-psbt): enforce prevout-matched silent payment input keys

80bfccc

refactor(caravan-psbt): expose NUMS script-path detection for validation

98ce2c3

vercel Bot deployed to Preview June 10, 2026 15:56 View deployment

jvgelder commented Jun 10, 2026

View reviewed changes

macgyver13 reviewed Jun 10, 2026

View reviewed changes

jvgelder added 3 commits June 23, 2026 17:41

chore(pstv2): Update vectors

af82d43

Even though the version number is lower the tests should be newer.

chore(psbtv2): Cleanup redundant code

6fc4630

- Created reusable taggedChallenge/tagged hash function (can be replaced with bitcoinJs tagged hash if needed) - Added verifyDleq proof for external use to prevent recalculation of points.

chore(psbtv2): Revert PSBT_OUT_SCRIPT changes

0275c92

Instead of returning an empty string, throw error and handle it.

vercel Bot deployed to Preview June 23, 2026 15:44 View deployment

chore(psbtv2): Improve missing warning

5a12230

Previously removed to much readded previous out.

jvgelder requested review from Legend101Zz and macgyver13 June 23, 2026 15:52

vercel Bot deployed to Preview June 23, 2026 15:55 View deployment

Uh oh!

Conversation

jvgelder commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

changeset-bot Bot commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

vercel Bot commented Mar 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented May 2, 2026

Uh oh!

jvgelder commented May 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Legend101Zz commented May 4, 2026

Uh oh!

jvgelder commented May 4, 2026

Uh oh!

Legend101Zz commented May 15, 2026

Uh oh!

Legend101Zz left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jvgelder Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jvgelder Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jvgelder commented May 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

macgyver13 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jvgelder commented Mar 24, 2026 •

edited

Loading

changeset-bot Bot commented Mar 24, 2026 •

edited

Loading

vercel Bot commented Mar 24, 2026 •

edited

Loading

jvgelder commented May 2, 2026 •

edited

Loading

Legend101Zz left a comment •

edited

Loading

jvgelder Jun 10, 2026 •

edited

Loading

jvgelder Jun 10, 2026 •

edited

Loading