AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 15 Bitcoin

silentpayments: sending

Public commit record

What the developer wrote

Authored by josibake

41/100 · Thin
silentpayments: sending

Add a routine for the entire sending flow which takes a set of private keys,
the smallest outpoint, and list of recipients and returns a list of
x-only public keys by performing the following steps:

1. Sum up the private keys
2. Calculate the input_hash
3. For each recipient group:
3a. Calculate a shared secret
3b. Create the requested number of outputs

This function assumes a single sender context in that it requires the
sender to have access to all of the private keys. In the future, this
API may be expanded to allow for a multiple senders or for a single
sender who does not have access to all private keys at any given time,
but for now these modes are considered out of scope / unsafe.

Internal to the library, add:

1. A function for creating shared secrets (i.e., a*B or b*A)
2. A function for generating the "SharedSecret" tagged hash
3. A function for creating a single output public key

Co-authored-by: w0xlt <94266259+w0xlt@users.noreply.github.com>
✓ Subject identifies a change✓ Provides detailed explanatory context! Too few words to establish purpose
The short version

What changed, and why it matters

This commit adds a new feature to the secp256k1 cryptographic library: the sender-side logic for Bitcoin Silent Payments (BIP352). It lets a wallet create special one-time payment addresses for recipients without revealing which recipient is being paid on the blockchain. The change is a normal, well-documented feature addition with no indication of a security bug or vulnerability fix.

Recommended action

No security action required. Treat as a normal feature addition. Reviewers may optionally audit the new BIP352 implementation for spec compliance and side-channel behavior, but the commit itself does not indicate a vulnerability.

Security signals we found

01

New feature implementation for BIP352 Silent Payments sender side

02

Extensive input validation (ARG_CHECK) and test coverage for malformed keys and bad arguments

03

Sensitive intermediate values (shared secrets, scalars) are explicitly cleared

04

Constant-time serialization of shared secret to preserve transaction indistinguishability

05

No vendor disclosure of security relevance, no CVE, no bug fix language in commit message

Risk score

Why this scored 15/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 10/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.