chore(payment): Implement silent payments #2269

jvgelder · 2025-10-08T16:16:35Z

Draft for now looking for a bit of feedback on how we can expose the functionality to the developer

Implements bip352 and exposes the following functions:

scanForSilentPayments: to find if given outputs belong to our sp address
deriveOutput: to create a new silent payment output
encodeSilentPaymentAddress
decodeSilentPaymentAddress

Note it tests against vectors taken from: https://github.com/bitcoin/bips/blob/master/bip-0352/send_and_receive_test_vectors.json

TODO:

Decide how we expose scanning and deriving to the developer i guess via the p2sp object ?
Decide whether we return the found hex endcoded or Uint8Array output
Figure out of we can remove modN32 and subBE as they might exist?
Add derivation logic
Replace getPubkeyFromInputTS from test with something that exists?

Do note that when this bitcoin-core/secp256k1#1698 gets merged and we make it available in https://github.com/bitcoinjs/tiny-secp256k1 part of this code becomes redundant but at least we already have the interfaces in place.

Bluewallet also has a TS implementation : https://github.com/BlueWallet/SilentPayments/blob/master/src/index.ts

This PR implements bip352 and exposes the following functions: - scanForSilentPayments: to find if given outputs belong to our sp address - deriveOutput: to create a new silent payment output TODO: - [] Decide how we expose scanning and deriving to the developer i guess via the p2sp object ? - [] Decide whether we return the found hex endcoded or Uint8Array output - [] Figure out of we can remove `modN32` and `subBE` as they might exist? - [] Add derivation logic - [] Replace `getPubkeyFromInputTS` from test with something that exists?

Tags were missing from the TAGS

Some outputs wernt matching what we expected them to be.

junderw · 2025-10-09T15:25:17Z

I've been in discussions on the best way to handle this, and I think it would be a better idea to pass in a cached key.

Instead of calculating the sum of the inputs in real time every time, The payment should only take a special key ie. inputAggregate or something with an easier name. Then separate from the Payments API we would offer a helper function that can calculate the aggregate key from given inputs array.

This is primarily because our friends over at BlueWallet see a future where apps like electrs or mempool etc will pre-calculate the aggregate keys and index them for us....

But... yeah... ballooning Payments API into something that encompasses a whole transaction seems like a bit much. At that point we might as well turn it into a method on the Psbt.

junderw · 2025-10-09T15:27:05Z

@Overtorment if you'd like to chime in, feel free.

jvgelder · 2025-10-10T10:49:50Z

I've been in discussions on the best way to handle this, and I think it would be a better idea to pass in a cached key.

Instead of calculating the sum of the inputs in real time every time, The payment should only take a special key ie. inputAggregate or something with an easier name. Then separate from the Payments API we would offer a helper function that can calculate the aggregate key from given inputs array.

This is primarily because our friends over at BlueWallet see a future where apps like electrs or mempool etc will pre-calculate the aggregate keys and index them for us....

But... yeah... ballooning Payments API into something that encompasses a whole transaction seems like a bit much. At that point we might as well turn it into a method on the Psbt.

ye maybe use the following logic:

If shared secret S?: Uint8Array and inputTweak?: Uint8Array are set we go straight to deriveOutputs
else if inputs?: Input[] and privKeys?: Array<{ priv: Uint8Array; isXOnly: boolean }> we do calculate the tweak and shared secret
else we throw an error.

Is there a use case to allow the user to provide A_sum instead of the private keys?
Besides returning outputs we may also want to return a transaction that can be signed or is this not the place to do that?
Similar to the point above do we want to return signed outputs?

Overtorment · 2025-10-10T11:56:26Z

ill take a look.

btw we have a TS implementation of SP here: https://github.com/BlueWallet/SilentPayments/

Shouldent something have failed here?

Added lazy prop for outputs.

jvgelder · 2025-10-10T12:13:03Z

I've been in discussions on the best way to handle this, and I think it would be a better idea to pass in a cached key.
Instead of calculating the sum of the inputs in real time every time, The payment should only take a special key ie. inputAggregate or something with an easier name. Then separate from the Payments API we would offer a helper function that can calculate the aggregate key from given inputs array.
This is primarily because our friends over at BlueWallet see a future where apps like electrs or mempool etc will pre-calculate the aggregate keys and index them for us....
But... yeah... ballooning Payments API into something that encompasses a whole transaction seems like a bit much. At that point we might as well turn it into a method on the Psbt.

ye maybe use the following logic:
* If shared secret `S?: Uint8Array` and `inputTweak?: Uint8Array` are set we go straight to `deriveOutputs`

* else if `inputs?: Input[]` and `privKeys?: Array<{ priv: Uint8Array; isXOnly: boolean }>` we do calculate the tweak and shared secret

* else we throw an error.


1. Is there a use case to allow the user to provide A_sum instead of the private keys?

2. Besides returning outputs we may also want to return a transaction that can be signed or is this not the place to do that?

3. Similar to the point above do we want to return signed outputs?

Allow various cases for deriving of outputs :

bitcoinjs-lib/ts_src/payments/p2sp.ts

Line 89 in 4f52dde

lazy.prop(o, 'outputs', () => {

jvgelder · 2025-10-10T13:07:51Z

ts_src/payments/p2sp.ts

+      network,
+    );
+  });
+  lazy.prop(o, 'outputs', () => {


This is something I am unsure about.

Should outputs be the ones create to send?

Where and how do we store resulting UTXO when we scanned?

jvgelder · 2025-10-10T14:01:36Z

ill take a look.

btw we have a TS implementation of SP here: https://github.com/BlueWallet/SilentPayments/

Ye I mentioned on the top :) (thought I referred to to something inside the core bluewallet app).
Reason for this PR is that I think most of the code belongs in bitcoinjslib (see the use of tagged hash for example).
If you think you have more elegant parts feel free to point out / overwrite some of my code here ( I am not that familiar with typescript)

junderw · 2025-10-10T14:03:07Z

ye maybe use the following logic:

If shared secret S?: Uint8Array and inputTweak?: Uint8Array are set we go straight to deriveOutputs

else if inputs?: Input[] and privKeys?: Array<{ priv: Uint8Array; isXOnly: boolean }> we do calculate the tweak and shared secret

else we throw an error.

Is there a use case to allow the user to provide A_sum instead of the private keys?

Besides returning outputs we may also want to return a transaction that can be signed or is this not the place to do that?

Similar to the point above do we want to return signed outputs?

I would like to repeat what I said before:

ballooning Payments API into something that encompasses a whole transaction seems like a bit much. At that point we might as well turn it into a method on the Psbt.

It seems like your reply is ignoring this and talking about placing all of that inside the p2sp Payment API still... am I misunderstanding your response? Could you please clarify?

jvgelder · 2025-10-10T14:25:17Z

ye maybe use the following logic:

If shared secret S?: Uint8Array and inputTweak?: Uint8Array are set we go straight to deriveOutputs

else if inputs?: Input[] and privKeys?: Array<{ priv: Uint8Array; isXOnly: boolean }> we do calculate the tweak and shared secret

else we throw an error.

Is there a use case to allow the user to provide A_sum instead of the private keys?

Besides returning outputs we may also want to return a transaction that can be signed or is this not the place to do that?

Similar to the point above do we want to return signed outputs?

I would like to repeat what I said before:

ballooning Payments API into something that encompasses a whole transaction seems like a bit much. At that point we might as well turn it into a method on the Psbt.

It seems like your reply is ignoring this and talking about placing all of that inside the p2sp Payment API still... am I misunderstanding your response? Could you please clarify?

scratch point 2 and 3 indeed.

For the inputs/outputs i was thinking of a bare minimal set of data, the parsing of the transactions into receiving inputs would be done elsewhere. I think the lazy output property kinda reflects this now right? or do you still think even that is too much here?

Overtorment · 2025-10-10T14:32:07Z

i feel a bit out of element here, every time i get distracted from SP i completely forget how they work and getting familiar again means re-reading all the specs again, and it takes time.

are there any specific questions for me? if yes, dumb it down for me.
otherwise, the standalone lib https://github.com/BlueWallet/SilentPayments/ does the job well, and embeds nicely into whatever js library for bitcoin you are going to use (not necessarily bitcoinjs-lib, more modern js apps choose to use scure-btc-signer instead )

jvgelder · 2025-10-10T14:43:43Z

i feel a bit out of element here, every time i get distracted from SP i completely forget how they work and getting familiar again means re-reading all the specs again, and it takes time.

are there any specific questions for me? if yes, dumb it down for me. otherwise, the standalone lib https://github.com/BlueWallet/SilentPayments/ does the job well, and embeds nicely into whatever js library for bitcoin you are going to use (not necessarily bitcoinjs-lib, more modern js apps choose to use scure-btc-signer instead )

no worries thanks for making me aware of scure-btc-signer also mentioned the blue wallet repo there as there was an issue open for silent payments too.

jvgelder · 2025-10-10T14:45:42Z

ts_src/payments/p2sp.ts

+      });
+    }
+    // If we have all the inputs, aSum and only the spend keys for the recipients we need to calculate the input hash and secret
+    else if (


this case drags in inputs (hashes) and we may not want to have this here

jvgelder · 2025-10-10T14:45:59Z

ts_src/payments/p2sp.ts

+      });
+    }
+    // If we have all the inputs, privKeys and only the spend keys for the recipients we need to calculate the Sum, the input hash and secret
+    else if (


same here for inputs

jvgelder added 5 commits October 8, 2025 18:12

fix(crypto): Added missing tags

d6f3297

Tags were missing from the TAGS

fix(p2sp): Function signature and output fixes

52148d8

Some outputs wernt matching what we expected them to be.

fix(tests): Properly load fixtures

77c07f7

chore(tests): Cleanup unused or redundant functions

bd2f200

Armss9936 approved these changes Oct 8, 2025

View reviewed changes

jvgelder added 3 commits October 10, 2025 14:04

chore(test): Clean up unused variables

4042a59

fix(test): Set k on deriveOutput

c8518f3

Shouldent something have failed here?

chore(p2sp): Move main function to top and add lazy prop

4f52dde

Added lazy prop for outputs.

jvgelder commented Oct 10, 2025

View reviewed changes

jvgelder mentioned this pull request Oct 10, 2025

Implement silent payments bip 352 paulmillr/scure-btc-signer#90

Open

jvgelder commented Oct 10, 2025

View reviewed changes

chore(payment): Implement silent payments #2269

Are you sure you want to change the base?

chore(payment): Implement silent payments #2269

Conversation

jvgelder commented Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

junderw commented Oct 9, 2025

Uh oh!

junderw commented Oct 9, 2025

Uh oh!

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

Uh oh!

Uh oh!

Overtorment commented Oct 10, 2025

Uh oh!

jvgelder commented Oct 10, 2025

Uh oh!

jvgelder Oct 10, 2025

Choose a reason for hiding this comment

Uh oh!

jvgelder commented Oct 10, 2025

Uh oh!

junderw commented Oct 10, 2025

Uh oh!

jvgelder commented Oct 10, 2025

Uh oh!

Overtorment commented Oct 10, 2025

Uh oh!

jvgelder commented Oct 10, 2025

Uh oh!

jvgelder Oct 10, 2025

Choose a reason for hiding this comment

Uh oh!

jvgelder Oct 10, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jvgelder commented Oct 8, 2025 •

edited

Loading

jvgelder commented Oct 10, 2025 •

edited

Loading