903da53c06
Adds `prefractal`, an experimental module that lets a FROST t-of-n group
occupy ONE participant slot of an ordinary MuSig2 (BIP 327) session. Each
member computes
s_i = k1_i + b_frost*b_musig*k2_i + e*a*lambda_i*g*gacc*d_i
and the group publishes one ordinary MuSig2 public nonce and one ordinary
MuSig2 partial signature, so cosigners need no support for it and cannot tell
a group is involved.
Four public functions, all sessionless (every call takes its session
parameters explicitly, so there are no new opaque types, magics or *_SIZE
constants to keep synchronised):
secp256k1_prefractal_nonce_agg group wire nonce + unscaled aggnonce
secp256k1_prefractal_sign one member's partial signature
secp256k1_prefractal_partial_sig_verify identifiable abort
secp256k1_prefractal_partial_sig_agg sum -> musig partial signature
Three deliberate deviations from BIP 445, all documented in the public header:
1. b_frost does not commit to the message. The target protocols publish the
group's wire nonce before the message exists, so a message-committing
coefficient could not be computed in round one and rebuilt later. The outer
b_musig does commit to the message and multiplies this one, so the product
still binds it. Same trade the iceberg module makes, for the same reason.
The preimage is BIP 445's with the message dropped and the group key
carried in full rather than x-only, since it is used as a full point
downstream.
2. There is NO g_frost factor. Stock FROST normalises its threshold key to
even Y (g_times_gacc_parity = gacc_parity ^ pk_odd, frost/session_impl.h
:664) because it produces a BIP 340 x-only signature. Here the threshold
key is an inner participant of the outer key aggregation and is used as a
full point, so all key-side parity normalisation happens once, at the
aggregate level, off the OUTER keyagg cache. Note this is NOT implied by
the tweak cache being the identity: with an identity cache g_frost is still
-1 for every odd-Y group key, i.e. about half of them. Importing frost's
key-side parity here would yield a signer that works for even-Y groups and
fails for odd-Y ones.
3. The FROST tweak cache must be the identity (tacc == 0, gacc_parity == 0).
Checked in sign and partial_sig_verify, not only in partial_sig_agg, so the
key a member signs under is tied to the cache that was validated; sign and
verify additionally require thresh_pk to equal the cache's own key so the
two arguments cannot disagree.
The verification equation lives in one helper used both by sign's BIP 445
self-check and by partial_sig_verify, so the two cannot drift apart.
Build wiring. Three files order their module blocks differently and the
constraints point in opposite directions:
- src/secp256k1.c: the include goes AFTER frost and musig, because the
module calls their static internals.
- src/CMakeLists.txt: the block goes BEFORE both, because its set() calls
are only observed by blocks that run later.
- configure.ac: the block likewise goes before the musig block, NOT at
iceberg's position further down. configure.ac orders musig and frost ahead
of iceberg, and iceberg's late enable_module_musig=yes is harmless only
because musig defaults to yes. frost defaults to no, so a late
force-enable would leave -DENABLE_MODULE_FROST=1 unemitted while
AM_CONDITIONAL still observed the mutation - a library whose secp256k1.c
never included frost, built alongside frost's own sources.
frost is also the first default-OFF module anything depends on, which breaks
the dependency-guard idiom used everywhere else in both build systems: the
existing "DEFINED X AND NOT X" (CMake) and "x$X = xno" (autotools) tests read
as "the user disabled it explicitly" only for default-ON modules, and are true
by default for a default-OFF one. Since neither build system can distinguish
an explicit disable from the default once both are in the cache, enabling
prefractal simply implies frost; the guard is kept for musig, where it still
means what it says. The CMake block additionally lifts both dependencies into
the parent scope so the top-level configuration summary reports what was
actually built rather than printing "frost OFF" while compiling frost in.
Verified on both build systems:
cmake -B build -DSECP256K1_ENABLE_MODULE_PREFRACTAL=ON -DSECP256K1_BUILD_TESTS=ON
-> musig/frost/prefractal all ON, tests pass, 4 prefractal symbols exported
cmake -B build -DSECP256K1_BUILD_TESTS=ON
-> prefractal OFF, default build unchanged, tests pass
./configure --enable-experimental --enable-module-prefractal && make && make check
-> frost=yes forced on, -DENABLE_MODULE_FROST=1 emitted, 3/3 pass
./configure --enable-module-prefractal
-> correctly refused: "Prefractal module is experimental"
tests_impl.h is a placeholder here so the module links; the real suite lands
next.
libsecp256k1-zkp
A fork of libsecp256k1 with support for advanced and experimental features
Added features:
- Experimental module for ECDSA adaptor signatures.
- Experimental module for ECDSA sign-to-contract.
- Experimental modules for Confidential Assets (Pedersen commitments, range proofs, and surjection proofs).
- Experimental module for address whitelisting.
- Experimental module for Schnorr signature half-aggregation.
- Experimental module for FROST (BIP 445).
- Experimental module for ChillDKG, distributed key generation for FROST (bip-frost-dkg draft).
- Experimental module for Iceberg, a threshold scheme that lets a group of parties stand in for a single MuSig2 (BIP 327) participant.
Experimental features are made available for testing and review by the community. The APIs of these features should not be considered stable.
Build steps
Obtaining and verifying
The git tag for each release (e.g. v0.6.0) is GPG-signed by one of the maintainers.
For a fully verified build of this project, it is recommended to obtain this repository
via git, obtain the GPG keys of the signing maintainer(s), and then verify the release
tag's signature using git.
This can be done with the following steps:
- Obtain the GPG keys listed in SECURITY.md.
- If possible, cross-reference these key IDs with another source controlled by its owner (e.g. social media, personal website). This is to mitigate the unlikely case that incorrect content is being presented by this repository.
- Clone the repository:
git clone https://github.com/bitcoin-core/secp256k1 - Check out the latest release tag, e.g.
git checkout v0.7.1 - Use git to verify the GPG signature:
% git tag -v v0.7.1 | grep -C 3 'Good signature' gpg: Signature made Mon 26 Jan 2026 07:42:46 PM UTC gpg: using RSA key 2840EAABF4BC9F0FFD716AFAFBAFCC46DE2D3FE2 gpg: Good signature from "Pieter Wuille <pieter@wuille.net>" [unknown] gpg: aka "Pieter Wuille <pieter.wuille@gmail.com>" [full] gpg: aka "[jpeg image of size 5996]" [undefined] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 133E AC17 9436 F14A 5CF1 B794 860F EB80 4E66 9320 Subkey fingerprint: 2840 EAAB F4BC 9F0F FD71 6AFA FBAF CC46 DE2D 3FE2
Building with Autotools
$ ./autogen.sh # Generate a ./configure script
$ ./configure # Generate a build system
$ make # Run the actual build process
$ make check # Run the test suite
$ sudo make install # Install the library into the system (optional)
To compile optional modules (such as Schnorr signatures), you need to run ./configure with additional flags (such as --enable-module-schnorrsig). Run ./configure --help to see the full list of available flags. For experimental modules, you will also need --enable-experimental as well as a flag for each individual module, e.g. --enable-module-rangeproof.
Building with CMake
To maintain a pristine source tree, CMake encourages to perform an out-of-source build by using a separate dedicated build tree.
Building on POSIX systems
$ cmake -B build # Generate a build system in subdirectory "build"
$ cmake --build build # Run the actual build process
$ ctest --test-dir build # Run the test suite
$ sudo cmake --install build # Install the library into the system (optional)
To compile optional modules (such as Schnorr signatures), you need to run cmake with additional flags (such as -DSECP256K1_ENABLE_MODULE_SCHNORRSIG=ON). Run cmake -B build -LH or ccmake -B build to see the full list of available flags.
Cross compiling
To alleviate issues with cross compiling, preconfigured toolchain files are available in the cmake directory.
For example, to cross compile for Windows:
$ cmake -B build -DCMAKE_TOOLCHAIN_FILE=cmake/x86_64-w64-mingw32.toolchain.cmake
To cross compile for Android with NDK (using NDK's toolchain file, and assuming the ANDROID_NDK_ROOT environment variable has been set):
$ cmake -B build -DCMAKE_TOOLCHAIN_FILE="${ANDROID_NDK_ROOT}/build/cmake/android.toolchain.cmake" -DANDROID_ABI=arm64-v8a -DANDROID_PLATFORM=28
Building on Windows
The following example assumes Visual Studio 2022. Using clang-cl is recommended.
In "Developer Command Prompt for VS 2022":
>cmake -B build -T ClangCL
>cmake --build build --config RelWithDebInfo
Usage examples
Usage examples can be found in the examples directory. To compile them you need to configure with --enable-examples.
- ECDSA example
- Schnorr signatures example
- Deriving a shared secret (ECDH) example
- ElligatorSwift key exchange example
- MuSig2 Schnorr multi-signatures example
To compile the examples, make sure the corresponding modules are enabled.
Benchmark
If configured with --enable-benchmark (which is the default), binaries for benchmarking the libsecp256k1-zkp functions will be present in the root directory after the build.
To print the benchmark result to the command line:
$ ./bench_name
To create a CSV file for the benchmark result :
$ ./bench_name | sed '2d;s/ \{1,\}//g' > bench_name.csv
Reporting a vulnerability
See SECURITY.md
Contributing to libsecp256k1
See CONTRIBUTING.md