"auto" implies that a value is being chosen based on build system
introspection or host system capabilities. However, for the
`--with-ecmult-gen-kb` option, the value "auto" is hardcoded, which
might lead to confusion.
This change replaces "auto" with a more appropriate default value.
"auto" implies that a value is being chosen based on build system
introspection or host system capabilities. However, for the
`--with-ecmult-window` option, the value "auto" is hardcoded, which
might lead to confusion.
This change replaces "auto" with a more appropriate default value.
This also makes the order in which module options are processed
consistent between CMake and autotools (the reverse order of the listing
printed to stdout).
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.
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.
This warns on certain identifiers reserved by the C standard, namely
* identifiers that begin with an underscore followed by an uppercase
letter, and
* identifiers in the global namespace that begin with an underscore.
We had used such identifiers in the past for macros in include guards,
and we should make sure that we don't reintroduce such identifiers
going forward.
Note that C reserves more identifiers for "future library directions",
e.g., identifiers that begin with "str" followed by a lowercase letter.
But even the C standards committee has decided that this is somewhat
silly and adopted a proposal [1] for C23 that removes the restriction
that programs using these identifiers have UB. Instead, these
identifiers are now "potentially reserved", which is not a normative
restriction but simply an informative warning that the identifiers
may become fully reserved in the future.
[1] https://www.open-std.org/jtc1/sc22/WG14/www/docs/n2625.pdf
This change eases the use of alternate build systems by moving
the variables in `src/libsecp256k1-config.h` to compiler macros
for each invocation, preventing duplication of these variables
for each build system.
Co-authored-by: Ali Sherief <ali@notatether.com>
There are plenty of unreleased variants of libsecp256k1 version 0.1.0
(libsecp256k1.so.0.0.0) in the wild. We choose a new version number to allow a
clear distinction.
There are variants of 0.1.0 that are incompatible with the initial release,
hence we increase the minor version to arrive at version number 0.2.0. For the
same reason, we increase the LIB_VERSION_CURRENT and keep AGE at 0.
The changelog for 0.2.0 consists of the relevant changes since 2021-12-25, which
is the date when the initial release process PR was merged (and the library
version was set to a pre-release, see 423b6d19d3).
This is somewhat arbitrary but at least points readers to relevant changes.
41e8704b48 build: Enable some modules by default (Tim Ruffing)
Pull request description:
This has been discussed in https://github.com/bitcoin-core/secp256k1/issues/817#issuecomment-693198323 and I agree with the arguments brought up there.
Alternatively, we could not enable them and add a discussion to the readme why we discourage people from using the modules. I believe enabling ECDH is not very controversial. But what about recovery? Do we want to leave it off and instead give a reason?
ACKs for top commit:
sipa:
ACK 41e8704b48
jonasnick:
ACK 41e8704b48
Tree-SHA512: 1dd21037043f2b2c94a92cd2f31e69b505ba5b43119897bc0934966d9ccd84fc4fc20e7509af634f1c3a096710db1a2253090f5f1f107b9d258945a5546e9ba4
We don't enable the ECDSA recovery module, because we don't recommend
ECDSA recovery for new protocols. In particular, the recovery API is
prone to misuse: It invites the caller to forget to check the public
key (and the verification function always returns 1).
In general, we also don't recommend ordinary ECDSA for new protocols.
But disabling the ECDSA functions is not possible because they're not
in a module, and let's be honest: disabling ECDSA would mean to ignore
reality blatantly.
We had removed `PKG_PROG_PKG_CONFIG` in 21b2ebaf74
(#1090). But then then the not rebased (!) merge of 2be6ba0fed
(#1084) brought that macro back at another location, without git
complaining about a conflict.
Fixes#1127.
49e2acd927 configure: Improve rationale for WERROR_CFLAGS (Tim Ruffing)
8dc4b03341 ci: Add a C++ job that compiles the public headers without -fpermissive (Tim Ruffing)
51f296a46c ci: Run persistent wineserver to speed up wine (Tim Ruffing)
3fb3269c22 ci: Add 32-bit MinGW64 build (Tim Ruffing)
9efc2e5221 ci: Add MSVC builds (Tim Ruffing)
2be6ba0fed configure: Convince autotools to work with MSVC's archiver lib.exe (Tim Ruffing)
bd81f4140a schnorrsig bench: Suppress a stupid warning in MSVC (Tim Ruffing)
09f3d71c51 configure: Add a few CFLAGS for MSVC (Tim Ruffing)
3b4f3d0d46 build: Reject C++ compilers in the preprocessor (Tim Ruffing)
1cc0941414 configure: Don't abort if the compiler does not define __STDC__ (Tim Ruffing)
cca8cbbac8 configure: Output message when checking for valgrind (Tim Ruffing)
1a6be5745f bench: Make benchmarks compile on MSVC (Tim Ruffing)
Pull request description:
ACKs for top commit:
jonasnick:
ACK 49e2acd927
Tree-SHA512: 986c498fb218231fff3519167d34a92e11dea6a4383788a9723be105c20578cd483c6b06ba5686c6669e3a02cfeebc29b8e5f1428552ebf4ec67fa7a86957548
7f09d0f311 README: mention that ARM assembly is experimental (Jonas Nick)
80cf4eea5f build: stop treating schnorrsig, extrakeys modules as experimental (Jonas Nick)
Pull request description:
Fixes#992
ACKs for top commit:
real-or-random:
ACK 7f09d0f311
fanquake:
ACK 7f09d0f311 - When this is in, I think we'll do a subtree update in Core, and prune some build cruft on our side.
Tree-SHA512: 13deb82dcca88bacb2cd5c1c589a8d4af2277c4d675262337ae4d7e93eb41d43825dda4945ca1c202c36aaa2e6fd42de9c6d711fe8d71bce578368281db698b2
