silentpayments: add light client API #1912

This PR extends the silentpayments module with API functions for prevouts_summary (de)serialization and output public key (k=0) creation, intended to be used by tweak indexers and light clients. Note that this functionality was originally introduced in the take 3 PR (#1698), but was then later intentionally removed again in take 4 (#1765, recently merged and released), in order to reduce the scope and lower the review burden.

The following 3 API functions are added:

• secp256k1_silentpayments_recipient_prevouts_summary_serialize: given a prevouts_summary object, create the corresponding 33-bytes or 65-bytes serialization
• secp256k1_silentpayments_recipient_prevouts_summary_parse: given a 33-byte or 65-byte prevouts_summary representation, create the corresponding prevouts_summary object
• secp256k1_silentpayments_recipient_create_output_pubkeys: given a prevouts_summary object, a recipients scan secret key and a list of spend public keys, create a list of corresponding x-only output public keys (one for each spend public key, each derived with k=0).

Tests, benchmarks and the example are extended accordingly.

Rebased on master (adapting to the _eckey_pubkey_... -> _ge_... serialize/parse renames #1915) and fixed the unintentional accepting of prevouts_summary deserialization if they are in hybrid pubkey format (i.e. 65 bytes with prefix bytes 0x06 or 0x07). This will be a bit simpler and more explicit if #1918 gets in and secp256k1_ge_parse{33,65} can be used, added a TODO comment accordingly.

Tested ACK 0b1cde32d56003bec3071a82b738d20314564c73

Exercised the new light client API against real chain data rather than constructed inputs: the 33-byte tweak a BlindBit Oracle v2 serves for a real 50,000 sat silent payment in mainnet block 965085, paid to a throwaway wallet whose scan key is published.

1. parse the 33-byte tweak the oracle serves
   ok
2. scan that transaction's one output
   found f420241ebdee9a956f88f6ea704b1e02871a64082f61489150222c3a33ee6038
   MATCHES the real 50,000 sat payment
3. round-trip: serialize the parsed summary back to 33 bytes
   in  023497fcdef5a9254be2e60e02a53bcede1e3d4ab67ed1928140a1d69438bb5678
   out 023497fcdef5a9254be2e60e02a53bcede1e3d4ab67ed1928140a1d69438bb5678
   identical
4. the 65-byte form should scan identically
   same payment found via 65-byte form
5. create_output_pubkeys, the filter-matching path, from the same tweak
   k=0 candidate f420241ebdee9a956f88f6ea704b1e02871a64082f61489150222c3a33ee6038
   equals the real output, so a filter would hit

Step 3: the 33-byte serialization is byte-identical to the deployed BlindBit wire format, so an index server can hand its bytes straight to _prevouts_summary_parse.

Tested with: cmake -B build -DSECP256K1_ENABLE_MODULE_SILENTPAYMENTS=ON -DSECP256K1_BUILD_BENCHMARK=ON cmake --build build -j8 && ctest --test-dir build — 223/223 passed x86-64 Linux, gcc 13.3.0. ctime_tests needs valgrind headers I don't have here, unrelated to this PR.

Rebased on master, in order to take use of the split-up group element parsing functions (ge_parse{33,65, introduced in #1918) in secp256k1_silentpayments_recipient_prevouts_summary_parse. Relevant part of the diff:

@@ -499,12 +496,8 @@ int secp256k1_silentpayments_recipient_prevouts_summary_parse(const secp256k1_co
     ARG_CHECK(input != NULL);
     ARG_CHECK(inputlen == 33 || inputlen == 65);
     /* Since an attacker can send us malicious data that looks like a serialized public key but is not, fail early. */
-    /* TODO: remove manual hybrid pubkey rejection and replace with `secp256k1_ge_parse33` and
-     * `secp256k1_ge_parse65` calls (depending on inputlen) once PR [#1918](/bitcoin-core-secp256k1/1918/) gets merged */
-    if (inputlen == 65 && input[0] != SECP256K1_TAG_PUBKEY_UNCOMPRESSED) { /* enforce uncompressed format (0x04 prefix) */
-        return 0;
-    }
-    if (!secp256k1_ge_parse(&pk, input, inputlen)) {
+    is_pubkey_valid = (inputlen == 33) ? secp256k1_ge_parse33(&pk, input) : secp256k1_ge_parse65(&pk, input);
+    if (!is_pubkey_valid) {
         return 0;
     }
     /* A serialized prevouts_summary will always have the input_hash multiplied in, so we set

For any rust developer interested on this, I've implemented bindings for the light client API in rust-secp256k1#998, relevant changes are: https://git.rust-bitcoin.org/nymius/rust-secp256k1/compare/push-smspvupuxvto..push-xymyntzmtovu

Tested f957513d652ccd7fd31922a7d0200fbf55eae1cd for behaviour, not a line-by-line code review: the light-client path (serialize, parse, k=0 candidates, then scan_outputs) finds exactly what the full scan finds, and the 33-byte serialization equals BIP352's input_hash·A. I checked this through ctypes against an independent Python BIP352 implementation, over the BIP352 vectors and 500 random transactions (P2TR/P2WPKH/P2PKH inputs, labels, k up to 4), plus 22 malformed inputs, all rejected. One doc nit: the header could say what the 33 bytes are, BIP352's "tweak data". Happy to share the script.

@theStack could you rebase on a3a5cd45dc619df3b3d6d5e54a6a756ad346b56d? I would like to check rust bindings against #1983 changes.

@theStack could you rebase on a3a5cd4? I would like to check rust bindings against #1983 changes.

Sure, rebased on master.