20 Commits

Author	SHA1	Message	Date
Kgothatso Ngako	5155ee03f7	frost_enrollment: add the example program ... Fifth of six commits. examples/frost_enrollment.c runs a 2-of-3 group through an enrollment to 2-of-4, signs with the new participant, and then repairs a lost share -- all roles in one process, following examples/frost.c's structure. The example exists mostly to demonstrate two things the API cannot enforce and that a reader would otherwise have to reconstruct from the documentation. First, the verification flow, in the order that makes it non-circular: 1. obtain thresh_pk from a source authenticated INDEPENDENTLY of the helpers (here, the dealer step, commented as the stand-in); 2. validate the helpers' public shares against it with secp256k1_frost_threshold_info_validate; 3. derive the expected public share from those validated shares; 4. only then run round 2, passing the same authenticated thresh_pk. Skip step 1 or 2 and every check in round 2 still passes -- on a share from whatever polynomial t colluding helpers chose to present. The example says so at the point where it would be tempting to skip them. Second, the authorization gap. There is no authorization step in the protocol: anyone who convinces t helpers to run it receives a valid share, and in repair mode that is an existing participant's actual share. The precondition sits in the comment on enroll(), where a reader copying the function will see it, and again at the repair call site, which is where it bites hardest. Beyond that the example is a working reference for the parts that are fiddly to get right from the header alone: the transposition between round 1.1's output buffers and round 1.2's input buffer (helper j collects entry j of every helper's buffer), the opposite own-slot conventions of the two round-1.2 buffers, the n -> n+1 bookkeeping with threshold_info_validate over the extended table, and the fact that the resulting signature verifies against the group's ORIGINAL threshold public key, since enrollment changes neither the polynomial nor any existing share. The repair half asserts byte equality with the original secret share and the original public share, so a regression there fails the example rather than passing quietly. Wired into both build systems next to the iceberg example: Makefile.am (noinst_PROGRAMS and TESTS under ENABLE_MODULE_FROST_ENROLLMENT) and examples/CMakeLists.txt. The .gitignore entry landed with the Phase 1 scaffolding. Verification. Autotools: builds warning-free and `make check` reports 12/12 PASS including frost_enrollment_example; five consecutive runs exit 0 (the key material is freshly random each time, so this exercises both threshold-key parities in practice). CMake: with -DSECP256K1_BUILD_EXAMPLES=ON, ctest runs all nine examples and secp256k1.example.frost_enrollment passes; the full ctest suite is 523/523 with frost, chilldkg, iceberg, prefractal and frost-enrollment all enabled. The source is clean under gcc -std=c89 -pedantic -Wall -Wextra. Note for anyone reproducing this: examples are OFF by default in both build systems (--enable-examples for autotools, -DSECP256K1_BUILD_EXAMPLES=ON for CMake), so a plain build will not compile this file at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 04:30:48 +02:00
Kgothatso Ngako	072f6631f3	iceberg: add the example program ... Port examples/iceberg.c from the source tree: a full Iceberg session demonstrating the call order from the module docs -- distributed key generation, pubshare_gen/pubkey_agg to obtain the group public key, nonce_gen/nonce_agg into an ordinary MuSig2 public nonce, and partial_sign/partial_sig_agg into an ordinary MuSig2 partial signature. One content adaptation: the secp256k1_musig_nonce_process call gains a NULL adaptor argument, matching this repo's zkp musig variant. Wired like the chilldkg example: autotools noinst_PROGRAMS + TESTS entry under ENABLE_MODULE_ICEBERG (the example runs as part of make check), CMake example target in examples/CMakeLists.txt, and iceberg_example added to .gitignore. Verified: ./iceberg_example runs to completion (exit 0) under both build systems.	2026-08-31 12:25:09 +02:00
Kgothatso Ngako	d1c817b528	chilldkg: Phase 6 - test vectors, FROST integration, docs, example ... Final phase of the ChillDKG module: upstream test vectors, a DKG->FROST integration test, boundary tests, full module documentation and a runnable example. Test vectors: - tools/test_vectors_chilldkg_generate.py converts all 10 upstream bip-frost-dkg JSON vector files into src/modules/chilldkg/vectors.h (modeled on tools/test_vectors_frost_generate.py; takes the vectors directory as an argument; upstream pinned to commit a91896883f85b159415ecf298d5e844879af112d, recorded in the generated header with the exact regeneration invocation; regeneration is reproducible byte-for-byte). - tests_impl.h vector runners execute 191 of 241 upstream cases through the public API: hostpubkey_gen, params_hash, participant_step1/step2/finalize/investigate, coordinator_step1/finalize/investigate, recover. Happy paths are byte-exact (pmsg1/cmsg1/pmsg2/cmsg2/dkg_output/recovery/cinv); error cases assert both the fault enum and fault_index against expectedError.participantId. The 50 skipped cases are wrong-length/wrong-count inputs not expressible with the fixed-size C API; each skip is documented in vectors.h. Boundary/robustness tests: t=1, t=n, n=2, a full n=128/t=2 session end-to-end with per-participant secshare*G == pubshare checks and a recovery roundtrip, and a state1 memcpy roundtrip (step2 from a copied state object). DKG->FROST integration test (guarded by ENABLE_MODULE_FROST): a full ChillDKG session (n=3, t=2) feeds (secshare, thresh_pk, pubshares) directly into the frost module. ChillDKG's thresh_pk is already TapTweak'ed, so frost_tweak_cache_init is called with no further tweaks (frost's tweaked x-only key asserted equal to the x-only part of the ChillDKG thresh_pk); signers 0 and 2 run nonce_gen, nonce_agg, session_init with the shared x = id+1 convention, frost_sign, partial_sig_verify and partial_sig_agg; the aggregate signature verifies as a plain BIP-340 signature against the threshold key. Example: examples/chilldkg.c runs a full 2-of-3 DKG session (host key generation, params hash, participant/coordinator steps, finalize, and a recovery roundtrip via participant_recover) with fixed-size buffers and secret erasure. Wired into Makefile.am and examples/CMakeLists.txt exactly like frost_example (runs as a TEST); chilldkg_example binary added to .gitignore. Docs: src/modules/chilldkg/chilldkg.md now documents the protocol summary, message-flow table with exact byte sizes, blame taxonomy, recovery workflow, security notes (host key reuse/retention, fresh randomness per session, state secrecy, recovery-data sensitivity) and the pinned reference commit; src/modules/frost/frost.md points at the new module as the intended DKG. Bug fix found by the vector runner (recover tcId 9): the internal recover() passed a possibly-NULL fault_index from coordinator_recover to certeq_verify, which dereferences it on failure; now uses a local. Verified: make check 10/10 (3 test suites + 7 examples incl. chilldkg_example, exit 0 when run); CMake ctest 428/428 with chilldkg + frost, and a no-frost build confirms the ENABLE_MODULE_FROST guard; make distdir includes vectors.h, the example and the generator. The module is feature-complete against bip-frost-dkg v0.3.0-dev at a91896883f85b159415ecf298d5e844879af112d. The BIP is still a draft; tagged hashes and wire formats may change upstream.	2026-08-31 06:52:58 +02:00
Kgothatso Ngako	2d97cc2242	Frost Module logic.	2026-08-31 00:05:16 +02:00
Hennadii Stepanov	8354618e02	cmake: Set LABELS property for tests	2026-01-20 16:53:29 +00:00
Hennadii Stepanov	29f26ec3cf	cmake: Integrate DiscoverTests and normalize test names ... Updates the build system to use the new DiscoverTests module. This also standardizes test names to use dot-separated parts for consistency.	2026-01-20 16:53:17 +00:00
Hennadii Stepanov	87384f5c0f	cmake, test: Add secp256k1_ prefix to test names ... This change improves regex matching options when using `ctest` in downstream projects.	2024-10-17 09:59:04 +01:00
merge-script	e59158b6eb	Merge bitcoin-core/secp256k1#1553: cmake: Set top-level target output locations ... c232486d84 Revert "cmake: Set `ENVIRONMENT` property for examples on Windows" (Hennadii Stepanov) 26e4a7c214 cmake: Set top-level target output locations (Hennadii Stepanov) Pull request description: While testing https://github.com/bitcoin-core/secp256k1/pull/1551, I noticed that when cross-compiling a shared library with examples for Windows, the `ctest` fails to run examples with Wine. Adjusting the `PATH` variable in 4af241b320/examples/CMakeLists.txt (L16-L18) does not help because `WINEPATH` is expected. Another issue with the current implementation is that the examples cannot run individually on Windows. This PR resolves both issues by reverting the implementation from https://github.com/bitcoin-core/secp256k1/pull/1290 in favour of the reworked and improved implementation from https://github.com/bitcoin-core/secp256k1/pull/1233. ACKs for top commit: theuni: Concept ACK and utACK c232486d84. real-or-random: utACK c232486d84 Tree-SHA512: 479b71d15d5d5670f6f69da3da599240c345711003383ca805c821b67065c9baaf269f987792cf1029211cdbfe799aecd401e6940a471539e3929b4a90e0781d	2024-10-15 13:37:21 +02:00
Jonas Nick	168c92011f	build: allow enabling the musig module in cmake	2024-10-07 14:03:42 +00:00
Hennadii Stepanov	c232486d84	Revert "cmake: Set ENVIRONMENT property for examples on Windows" ... This reverts commit 116d2ab3df.	2024-09-18 18:13:44 +01:00
Sebastian Falbesoner	31f84595c4	Add ellswift usage example ... This should hopefully be useful as orientation for users implementing the key exchange part of BIP324. Conceptually the example is not very different to the ECDH one, so a lot of code/comments are just copied (e.g. context creation, secret key generation, shared secret comparison, console output, cleanup with secret key clearing).	2024-06-25 17:11:20 +02:00
Hennadii Stepanov	116d2ab3df	cmake: Set ENVIRONMENT property for examples on Windows ... This change simplifies running examples on Windows, because the DLL must reside either in the same folder where the executable is or somewhere in PATH.	2023-07-14 08:42:48 +01:00
Hennadii Stepanov	cef373997c	cmake, refactor: Use helper function instead of interface library ... This change aims to simplify the following commit.	2023-07-14 08:41:26 +01:00
Hennadii Stepanov	ae9db95cea	build: Introduce SECP256K1_STATIC macro for Windows users ... It is a non-Libtool-specific way to explicitly specify the user's intention to consume a static `libseck256k1`. This change allows to get rid of MSVC linker warnings LNK4217 and LNK4286. Also, it makes possible to merge the `SECP256K1_API` and `SECP256K1_API_VAR` into one.	2023-07-03 13:57:11 +01:00
Hennadii Stepanov	755629bc03	cmake: Use full signature of add_test() command ... An executable target in the `COMMAND` option will automatically be replaced by the location of the executable created at build time. This change fixes tests for Windows binaries using Wine.	2023-04-29 09:49:25 +01:00
Tim Ruffing	6b7e5b717d	Merge bitcoin-core/secp256k1#1275: build: Fix C4005 "macro redefinition" MSVC warnings in examples ... dc0657c762 build: Fix C4005 "macro redefinition" MSVC warnings in examples (Hennadii Stepanov) Pull request description: This PR: - fixes C4005 "macro redefinition" MSVC warnings in examples - removes warning suppressions in both build systems, Autotools-based and CMake-based ones ACKs for top commit: real-or-random: utACK dc0657c762 Tree-SHA512: fe3bb8f06b3ff1d51e5e20754a289e0e6b99ddf4c0bd4e6e4786e2558e71e043ab23ff7782a83a902df5db28d18ae65312674c373fdc49f5af252763a22bd0fb	2023-04-26 16:44:51 +01:00
Cory Fields	ef49a11d29	build: allow static or shared but not both	2023-04-17 16:25:27 +00:00
Hennadii Stepanov	dc0657c762	build: Fix C4005 "macro redefinition" MSVC warnings in examples	2023-04-13 12:23:30 +01:00
Hennadii Stepanov	8be82d4362	cmake: Rename project to "libsecp256k1"	2023-03-08 21:22:24 +00:00
Hennadii Stepanov	5468d70964	build: Add CMake-based build system ... Co-authored-by: Tim Ruffing <crypto@timruffing.de>	2023-03-08 13:33:16 +00:00