Add ECDSA pubkey recovery usage example

theStack commented at 12:50 pm on July 30, 2025: contributor

The recovery module is probably not super-relevant these days for newer projects (the primary use-case I’m aware of is message signing in Bitcoin Core and Electrum, likely other wallets; something that is hopefully replaced by BIP-322 one day), but it still seems better to have an example than to have none. It contains all of the five API calls, i.e. for signing, recovering, converting, serializing, parsing. As usual with examples, a lot of code and comments are duplicated (e.g. context creation, keypair generation, cleanup with secret key clearing etc.).

in Makefile.am:169 in 8b3cecfb19 outdated

162@@ -163,6 +163,17 @@ if BUILD_WINDOWS
163 ecdsa_example_LDFLAGS += -lbcrypt
164 endif
165 TESTS += ecdsa_example
166+if ENABLE_MODULE_RECOVERY
167+noinst_PROGRAMS += recovery_example
168+recovery_example_SOURCES = examples/recovery.c
169+recovery_example_CPPFLAGS = -I$(top_srcdir)/include -DSECP256K1_STATIC

hebasto commented at 1:01 pm on July 30, 2025:

I understand that this line follows the pattern, but -DSECP256K1_STATIC flag is relevant for Windows only:https://github.com/bitcoin-core/secp256k1/blob/20e3b4474639edf8fab6766ac6bda161bd9f52e5/include/secp256k1.h#L165-L168

theStack commented at 10:49 pm on July 30, 2025:

I see, so a separate PR could make sense where this is moved into the if BUILD_WINDOWS block for each example? Happy to open one (or review) if that is what you had in mind.

real-or-random commented at 8:03 am on August 4, 2025:

I’m not convinced that if BUILD_WINDOWS is better. Sure, the macro is checked only on Windows but it certainly doesn’t hurt to set it everywhere.

theStack force-pushed on Jul 30, 2025

theStack commented at 10:49 pm on July 30, 2025: contributor

I suppose the CI failures for the Valgrind jobs on MacOS Ventura (https://github.com/bitcoin-core/secp256k1/actions/runs/16623024583/job/47031936047 and https://github.com/bitcoin-core/secp256k1/actions/runs/16623024583/job/47031935996) are caused by the same memcmp-issue as observed in the Silent Payments PR (see #1519 (review) ff.). Stole the my_memcmp_var reimplementation in #1698 from @josibake (thanks!) and force-pushed. Will consider moving it to examples_util.h if it solves the problem.

josibake commented at 7:46 am on July 31, 2025: member

The CI failure seems unrelated and probably just needs a restart; its caused by a 503 when installing packages inside the docker container (if I’m reading the logs correctly): https://github.com/bitcoin-core/secp256k1/actions/runs/16635429498/job/47075060509?pr=1714

fanquake commented at 2:04 pm on July 31, 2025: member

Kicked the failure.

theStack commented at 2:11 pm on July 31, 2025: contributor

The CI failure seems unrelated and probably just needs a restart; its caused by a 503 when installing packages inside the docker container (if I’m reading the logs correctly): https://github.com/bitcoin-core/secp256k1/actions/runs/16635429498/job/47075060509?pr=1714

Yeah indeed. Before the latest force-push (i.e. still using memcmp) the failure looked like this though: https://github.com/bitcoin-core/secp256k1/actions/runs/16623024583/job/47031936047#step:7:1141 pointing to the line using memcmp, so I guess I have to keep the workaround.

Kicked the failure.

Thanks!

josibake commented at 3:37 pm on July 31, 2025: member

Yeah indeed. Before the latest force-push

Sorry, my comment was unclear. What I meant to say is your solution works and the current failure is definitely not related.

real-or-random added the label user-documentation on Aug 1, 2025

in examples/recovery.c:129 in 314da4173f outdated

119+    return_val = secp256k1_ecdsa_recoverable_signature_convert(ctx, &normal_sig, &recoverable_sig);
120+    assert(return_val);
121+    if (!secp256k1_ecdsa_verify(ctx, &normal_sig, msg, &recovered_pubkey)) {
122+        printf("Signature verification with converted recoverable signature failed\n");
123+        return EXIT_FAILURE;
124+    }

jonasnick commented at 7:53 pm on August 5, 2025:

This is true for signatures created with secp256k1_ecdsa_sign_recoverable, but not necessarily for arbitrarily generated ECDSA signatures (see #1718).

theStack commented at 10:33 pm on August 5, 2025:

That’s interesting, wasn’t aware. Added an secp256k1_ecdsa_signature_normalize call before the verification (it’s a no-op in this example, but for demonstration purposes) and tried to explain that with a comment.

Add ECDSA pubkey recovery usage example

Co-authored-by: josibake <josibake@protonmail.com>

0b3dfb7039

examples: add missing dots in paragraphs about context randomization de5b2230fc

theStack force-pushed on Aug 5, 2025

Add ECDSA pubkey recovery usage example #1714