c6cd2b15a0 ci: Add task for static library on Windows + CMake (Hennadii Stepanov)
020bf69a44 build: Add extensive docs on visibility issues (Tim Ruffing)
0196e8ade1 build: Introduce `SECP256k1_DLL_EXPORT` macro (Hennadii Stepanov)
9f1b1904a3 refactor: Replace `SECP256K1_API_VAR` with `SECP256K1_API` (Hennadii Stepanov)
ae9db95cea build: Introduce `SECP256K1_STATIC` macro for Windows users (Hennadii Stepanov)
Pull request description:
Previous attempts:
- https://github.com/bitcoin-core/secp256k1/pull/1346
- https://github.com/bitcoin-core/secp256k1/pull/1362
The result is as follows:
1. Simple, concise and extensively documented code.
2. Explicitly documented use cases with no ambiguities.
3. No workarounds for linker warnings.
4. Solves one item in https://github.com/bitcoin-core/secp256k1/issues/1235.
ACKs for top commit:
real-or-random:
utACK c6cd2b15a0
Tree-SHA512: d58694452d630aefbd047916033249891bc726b7475433aaaa7c3ea2a07ded8f185a598385b67c2ee3440ec5904ff9d9452c97b0961d84dcb2eb2cf46caa171e
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.
7c7467ab7f Refer to ellswift.md in API docs (Pieter Wuille)
c32ffd8d8c Add ellswift to CHANGELOG (Pieter Wuille)
Pull request description:
A follow-up with a CHANGELOG entry for #1129.
ACKs for top commit:
real-or-random:
ACK 7c7467ab7f
theStack:
ACK 7c7467ab7f
Tree-SHA512: 4f066e4b8d5e130f2b5bea0ed4c634e9426bc576342aad6c306e0805a8354e27a5e679b15ec869d4e7d36eb5d53174e46b3bf5e15d19a7e165afc82e46ddfcf5
bc7c8db179 abi: Use dllexport for mingw builds (Cory Fields)
Pull request description:
Addresses the first part of #1181. See the discussion there for more context and history.
After this, all that remains is a (platform-independent) exports checker for c-i. Or perhaps a linker script or .def file could be tricked into testing as a side-effect.
This should fix mingw exports, specifically hiding the following:
`secp256k1_pre_g_128`
`secp256k1_pre_g`
`secp256k1_ecmult_gen_prec_table`
This changes our visibility macros to look more like [gcc's recommendation](https://gcc.gnu.org/wiki/Visibility#How_to_use_the_new_C.2B-.2B-_visibility_support).
Edit:
Note that we could further complicate this by supporting `__attribute__ ((dllexport))` as well, though I didn't bother as I'm not sure what compiler combo would accept that but not the bare dllexport syntax.
Edit2:
As the title implies, this affects this ABI and could affect downstream libs/apps in unintended ways (though it's hard to imagine any real downside). Though because it's win32 only, I'm imagining very little real-world impact at all.
ACKs for top commit:
hebasto:
re-ACK bc7c8db179, only a comment has been adjusted since my recent [review](https://github.com/bitcoin-core/secp256k1/pull/1295#pullrequestreview-1414928537),
real-or-random:
utACK bc7c8db179
Tree-SHA512: 378e15556da49494f551bdf4f7b41304db9d03a435f21fcc947c9520aa43e3c655cfe216fba57a5179a871c975c806460eef7c33b105f2726e1de0937ff2444e
The scheme implemented is described below, and largely follows the paper
"SwiftEC: Shallue–van de Woestijne Indifferentiable Function To Elliptic Curves",
by Chavez-Saab, Rodriguez-Henriquez, and Tibouchi
(https://eprint.iacr.org/2022/759).
A new 64-byte public key format is introduced, with the property that *every*
64-byte array is an encoding for a non-infinite curve point. Each curve point
has roughly 2^256 distinct encodings. This permits disguising public keys as
uniformly random bytes.
The new API functions:
* secp256k1_ellswift_encode: convert a normal public key to an ellswift 64-byte
public key, using additional entropy to pick among the many possible
encodings.
* secp256k1_ellswift_decode: convert an ellswift 64-byte public key to a normal
public key.
* secp256k1_ellswift_create: a faster and safer equivalent to calling
secp256k1_ec_pubkey_create + secp256k1_ellswift_encode.
* secp256k1_ellswift_xdh: x-only ECDH directly on ellswift 64-byte public keys,
where the key encodings are fed to the hash function.
The scheme itself is documented in secp256k1_ellswift.h.
From an API perspective, the functions `secp256k1_keypair_pub` and
`secp256k1_keypair_xonly_pub` always succeed (i.e. return the value 1),
so the other cases in the `pubkey` parameter descriptions never happen
and can hence be removed.
Note that the "1 always" return value description was previously done in
commit b8f8b99f0f (PR #1089), which also
explains why invalid inputs for the affected functions are in practice
only possible in violation of the type system.
For the sake of completeness, add the missing descriptions for the
return value and parameters (`ctx`, `sig64`, `keypair`), in the same
wording/style as for the function `secp256k1_schnorrsig_sign32`.
8e142ca410 Move `SECP256K1_INLINE` macro definition out from `include/secp256k1.h` (Hennadii Stepanov)
77445898a5 Remove `SECP256K1_INLINE` usage from examples (Hennadii Stepanov)
Pull request description:
From [IRC](https://gnusha.org/secp256k1/2023-01-31.log):
> 06:29 \< hebasto\> What are reasons to define the `SECP256K1_INLINE` macro in user's `include/secp256k1.h` header, while it is used internally only?
> 06:32 \< hebasto\> I mean, any other (or a new dedicated) header in `src` looks more appropriate, no?
> 06:35 \< sipa\> I think it may just predate any "utility" internal headers.
> 06:42 \< sipa\> I think it makes sense to move it to util.h
Pros:
- it is a step in direction to better organized headers (in context of #924, #1039)
Cons:
- code duplication for `SECP256K1_GNUC_PREREQ` macro
ACKs for top commit:
sipa:
utACK 8e142ca410
real-or-random:
utACK 8e142ca410
Tree-SHA512: 180e0ba7c2ef242b765f20698b67d06c492b7b70866c21db27c18d8b2e85c3e11f86c6cb99ffa88bbd23891ce3ee8a24bc528f2c91167ec2fddc167463f78eac
b43dd83b43 musig: add missing static keyword to function (Jonas Nick)
068e6a036a musig: add test vectors from BIP MuSig (Jonas Nick)
36621d13be musig: update to BIP v1.0.0-rc.2 "Add ''pk'' arg to ''NonceGen''" (Jonas Nick)
d717a4980b musig: update to BIP v0.8 "Switch from X-only to plain pk inputs." (Jonas Nick)
304f1bc96d extrakeys: add pubkey_sort test vectors from BIP MuSig2 (Jonas Nick)
ae89051547 extrakeys: replace xonly_sort with pubkey_sort (Jonas Nick)
98242fcdd9 extrakeys: add secp256k1_pubkey_cmp (Jonas Nick)
73d5b6654d musig: update to BIP v0.7.0 (NonceGen) (Jonas Nick)
060887e9d7 musig: update to BIP v0.5.1 "Rename ordinary tweaking to plain" (Jonas Nick)
cbe2815633 musig: update to BIP v0.4 "Allow the output of NonceAgg to be inf" (Jonas Nick)
206017d67d musig: update to BIP v0.3 (NonceGen) (Jonas Nick)
d800dd55db musig: remove test vectors (Jonas Nick)
Pull request description:
Version 1.0.0-rc.3 of BIP MuSig2 can be found [here](https://github.com/jonasnick/bips/pull/75). This PR does _not_ implement the following optional features that have been added to BIP MuSig2:
- variable length messages
- deterministic signing
- identifiable aborts
The PR also does _not_ yet change the `secnonce` structure to also contain the signer's public key (which would also imply changing the seckey argument in `sign` to a keypair). Additionally, we may want to rename some things in the future to be more consistent with the BIP (e.g. keyagg_cache vs. keyagg_ctx, applytweak vs. tweak_add).
ACKs for top commit:
ariard:
Light Code Review ACK b43dd83b, mostly looks on how the user API will make sense for Lightning, thanks for the answers!
real-or-random:
ACK b43dd83b43
Tree-SHA512: 9b1410951b55a1b0e6590b8c302052996d1fb6d9771765498b4282ff68b44ab0d6add8144c9330217b682ec5a93508b5546099db9a1f2c865f99253010dd76f4
This fixes a build issue with MSVC. While MSVC imports *functions*
from DLLs automatically when building a consumer of the DLL, it does
not import *variables* automatically. In these cases, we need an
explicit __declspec(dllimport).
This commit simply changes our logic to what the libtool manual
suggests, which has a very comprehensive writeup on the topic. Note
that in particular, this solution is carefully designed not to break
static linking. However, as described in the libtool manual,
statically linking the library with MSVC will output warning LNK4217.
This is still the best solution overall, because the warning is
merely a cosmetic issue.
