libsecp256k1

musig: check infinity test setup

`pubnonce_summing_to_inf` initializes both sums to infinity before loading the nonce objects.
A load failure could therefore satisfy the expected infinity checks without validating the constructed pair.
Require both nonce-loading operations to succeed before testing their outputs.

recovery: check exhaustive API results

The exhaustive recovery tests decoded and verified signatures without requiring recoverable signing or conversion to succeed.
Check those documented success results before consuming the outputs, matching the ordinary exhaustive signing test.

extrakeys: check test pubkey loads

The x-only parity test compared fields from two loaded points without requiring either load to succeed.
Check both setup operations before reading their outputs.

ellswift: check test operation results

The EllSwift tests inspected outputs without requiring encoding, decoding, or public-key loading to succeed.
They also discarded the field parser result despite relying on its no-overflow precondition.
Check each deterministic success result before inspecting its output.

tests: check exhaustive ecmult success

The exhaustive matrix compared the Jacobian output without requiring `secp256k1_ecmult_multi_var` to succeed.
Require success before consuming the result so a failure cannot satisfy an infinity case accidentally.

Add changelog entry for silentpayments module

silentpayments: API docs and internal comment followups

Addresses follow-up comments and Claude nits from #1765, see
- https://github.com/bitcoin-core/secp256k1/pull/1765#discussion_r3629070333
- https://github.com/bitcoin-core/secp256k1/pull/1765#discussion_r3628888249
- https://github.com/bitcoin-core/secp256k1/pull/1765#discussion_r3629066762
- https://github.com/bitcoin-core/secp256k1/pull/1765#pullrequestreview-4754517850

Note that the "hash output is not a valid scalar" error mentioning in
the API docs for sending is dropped intentionally to reflect the
scanning API docs, where we don't mention this negligible case either.

Co-authored-by: Tim Ruffing <me@real-or-random.org>

nonce: terminate RFC6979 loop at UINT_MAX

The public nonce callback accepts `UINT_MAX`, but `nonce_function_rfc6979_impl` never returns for that attempt.
Its `i <= counter` loop wraps after the final candidate and starts again.

Generate the candidate before checking whether it is the requested attempt.
This preserves the result for every `unsigned int` attempt, including `UINT_MAX`, and exits before the index can wrap.

Co-authored-by: Tim Ruffing <me@real-or-random.org>

extrakeys: check invariant that x-only pubkeys have even Y

silentpayments: drop "shuffle outputs" recommendation from API docs

silentpayments: flush labels before direct match

A direct x-only match stops scanning before a partial batch of earlier label candidates is checked.
The batch-inversion optimization can therefore return a later unlabeled output and discard label metadata for the earlier output.

Check the pending batch before accepting the direct match.
This restores the scan order from before batching, where the first matching output wins.

The regression puts a labeled `k = 0` output before its unlabeled counterpart and requires scanning to return it with the label.

silentpayments: extract label batch checker

Move the existing label-batch conversion and lookup into a helper.
The helper preserves the lookup order and keeps each scan exit on the same batch path.

tests: add constant time tests

Co-authored-by: Jonas Nick <2582071+jonasnick@users.noreply.github.com>
Co-authored-by: Sebastian Falbesoner <91535+thestack@users.noreply.github.com>

docs: update README

silentpayments: skip slow benchmarks for low iters count (<= 2)

The worst-case scanning benchmarks and the common-case scanning
benchmarks with N>10 are relatively slow, leading to signifcantly
long run times of CI jobs. Avoid this by skipping these if the
iters count is <= 2 (CI jobs run with SECP256K1_BENCH_ITERS=2).
This is the same approach used in the ecmult benchmarks (bench_ecmult).

tests: add sha256 tag test

Test midstate tags used in silent payments.

ci: enable silentpayments module

tests: add BIP-352 test vectors

Add the BIP-352 test vectors. The vectors are generated with a Python script
that converts the .json file from the BIP to C code:

$ ./tools/tests_silentpayments_generate.py test_vectors.json > ./src/modules/silentpayments/vectors.h

Co-authored-by: Ron <4712150+macgyver13@users.noreply.github.com>
Co-authored-by: Sebastian Falbesoner <91535+thestack@users.noreply.github.com>
Co-authored-by: Tim Ruffing <1071625+real-or-random@users.noreply.github.com>

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>

silentpayments: optimize scanning by using batch inversion

This improves the worst-case scanning scenario performance by ~2.5x
and also helps notably in the common case ("no match") scenario,
especially if the number of outputs is high.

Benchmark results on parent commit (without optimization):

Benchmark , Min(us) , Avg(us) , Max(us)

silentpayments_scan_nomatch_N=2 , 40.1 , 40.1 , 40.2
silentpayments_scan_nomatch_N=5 , 43.7 , 43.8 , 43.8
silentpayments_scan_nomatch_N=10 , 50.1 , 50.1 , 50.1
silentpayments_scan_nomatch_N=100 , 166.0 , 168.0 , 173.0
silentpayments_scan_nomatch_N=1000 , 1363.0 , 1368.0 , 1376.0
silentpayments_scan_nomatch_N=2323 , 3107.0 , 3113.0 , 3122.0
silentpayments_scan_nomatch_N=23250 , 30719.0 , 30764.0 , 30813.0
silentpayments_scan_worstcase_K=10 , 336371.0 , 336429.0 , 336492.0
silentpayments_scan_worstcase_K=100 , 3081573.0 , 3082413.0 , 3082899.0
silentpayments_scan_worstcase_K=1000 , 29909353.0 , 29931334.0 , 29951917.0
silentpayments_scan_worstcase_K=2323 , 67392236.0 , 67410087.0 , 67440159.0

Benchmark results on this commit (with optimization):

Benchmark , Min(us) , Avg(us) , Max(us)

silentpayments_scan_nomatch_N=2 , 39.3 , 39.3 , 39.4
silentpayments_scan_nomatch_N=5 , 40.5 , 40.5 , 40.6
silentpayments_scan_nomatch_N=10 , 43.5 , 43.5 , 43.5
silentpayments_scan_nomatch_N=100 , 90.0 , 92.7 , 100.0
silentpayments_scan_nomatch_N=1000 , 578.0 , 579.0 , 584.0
silentpayments_scan_nomatch_N=2323 , 1296.0 , 1300.0 , 1310.0
silentpayments_scan_nomatch_N=23250 , 12629.0 , 12649.0 , 12664.0
silentpayments_scan_worstcase_K=10 , 137746.0 , 137781.0 , 137813.0
silentpayments_scan_worstcase_K=100 , 1261417.0 , 1261614.0 , 1261774.0
silentpayments_scan_worstcase_K=1000 , 12245097.0 , 12249587.0 , 12258039.0
silentpayments_scan_worstcase_K=2323 , 27591765.0 , 27594324.0 , 27597324.0

(Benchmark machine: arm64 notebook, Snapdragon X Elite X1E-78-100)

silentpayments: add examples/silentpayments.c

Demonstrate sending and scanning on full nodes.

silentpayments: respect per-group recipients protocol limit (K_max=2323)

This affects both the sending and scanning API functions:
* Sending fails if any group is exceeding the limit.
* Scanning doesn't look beyond the limit.

Also add a recommendation to the API docs to shuffle the
`tx_outputs` input array, which improves the worst-case by ~2x.

Co-authored-by: nymius <155548262+nymius@users.noreply.github.com>

silentpayments: receiving

Add routine for scanning a transaction and returning the necessary
spending data for any found outputs. This function works with labels via
a lookup callback and requires access to the transaction outputs.
Requiring access to the transaction outputs is not suitable for light
clients, but light client support is enabled in a future release.

Add an opaque data type for passing around the prevout public key sum
and the input hash tweak (input_hash). This data is passed to the scanner
before the ECDH step as two separate elements so that the scanner can
multiply the scan_key * input_hash before doing ECDH.

Finally, add test coverage for the receiving API.

Co-authored-by: w0xlt <94266259+w0xlt@users.noreply.github.com>

silentpayments: recipient label support

Add function for creating a label tweak. This requires a tagged hash
function for labels. This function is used by the receiver for creating
labels to be used for a) creating labeled addresses and b) to populate
a labels cache when scanning.

Add function for creating a labeled spend pubkey. This involves taking
a label tweak, turning it into a public key and adding it to the spend
public key. This function is used by the receiver to create a labeled
silent payment address.

Add tests for the label API.

Co-authored-by: w0xlt <94266259+w0xlt@users.noreply.github.com>

silentpayments: add benchmarks for scanning

Add a benchmark for a full transaction scan, both for the common
case and worst-case (full-block sized tx) scenarios.
Only benchmarks for scanning are added as this is the most
performance critical portion of the protocol.

Co-authored-by: Sebastian Falbesoner <91535+thestack@users.noreply.github.com>