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 423b6d19d373f1224fd671a982584d7e7900bc93).
This is somewhat arbitrary but at least points readers to relevant changes.
- make version on master always equal to latest release with patch+1
- separate regular from maintenance releases
- add more git commands to prevent accidents
- mention that one needs to somehow deal with release dates
- _LIB_VERSIONS_ -> _LIB_VERSION_
- don't push all tags in step 4
- add required message to git tag
- add suggested commit messages
4386a2306c2b8cf9ad3040d8010e4295f6f01490 examples: Switch to NONE contexts (Tim Ruffing)
7289b51d31bf091330f1bcae397fba8b2b2d54ab docs: Use doxygen style if and only if comment is user-facing (Tim Ruffing)
e7d0185c901dfd6986476ba85aa03f5cfa0951f9 docs: Get rid of "initialized for signing" terminology (Tim Ruffing)
06126364ad988771d762923ce71e63e7f5c56951 docs: Tidy and improve docs about contexts and randomization (Tim Ruffing)
e02d6862bddfc4c18116c22deb86c29380a7bfce selftest: Expose in public API (Tim Ruffing)
e383fbfa66d2c7f48c06a4f4810b5e6db945d2c7 selftest: Rename internal function to make name available for API (Tim Ruffing)
d2c6d48de3c7032fc6d96e8efecb5a933f3c009c tests: Use new name of static context (Tim Ruffing)
53796d2b24e813750feae73e85c0a6eee40dc391 contexts: Rename static context (Tim Ruffing)
72fedf8a6cff9e26882fa0bc923da0429b6916af docs: Improve docs for static context (Tim Ruffing)
316ac7625ad1fbfc5b5b317dfbc7bdab534aaa3e contexts: Deprecate all context flags except SECP256K1_CONTEXT_NONE (Tim Ruffing)
1a553ee8be295f20aca3bc24d85732074b888b87 docs: Change signature "validation" to "verification" (Tim Ruffing)
ee7341fbac1d159a198780c94aa8e0a025e28848 docs: Never require a verification context (Tim Ruffing)
Pull request description:
ACKs for top commit:
sipa:
utACK 4386a2306c2b8cf9ad3040d8010e4295f6f01490
jonasnick:
ACK 4386a2306c2b8cf9ad3040d8010e4295f6f01490
Tree-SHA512: 7bf07dfae0ecbf7de1418de64ef743a23dc5f244aeba2c1cf3ecbdc117d6ac12bb6c8f17f739605566074a9b901765ee4a32288b6edc6f9a0040a70cb472f6ee
a8494b02bfe7578ffb76e66924e76c83556a802d Use compute credits for macOS jobs (Pieter Wuille)
c0ae48c9950a908b637bff27791fabbe2833c4a5 Update macOS image for CI (Pieter Wuille)
Pull request description:
ACKs for top commit:
real-or-random:
ACK a8494b02bfe7578ffb76e66924e76c83556a802d
jonasnick:
ACK a8494b02bfe7578ffb76e66924e76c83556a802d
Tree-SHA512: af99585ef68fc8305785885efaf0a0ebe45e5765661d654523a36ba843fc83e0ac40a554638437fa53804e4aa42dbcd92d597702ee6225b66a044a6304bafd45
41e8704b484652cf5bbb2b7ecc27feedc3cf0ae1 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 41e8704b484652cf5bbb2b7ecc27feedc3cf0ae1
jonasnick:
ACK 41e8704b484652cf5bbb2b7ecc27feedc3cf0ae1
Tree-SHA512: 1dd21037043f2b2c94a92cd2f31e69b505ba5b43119897bc0934966d9ccd84fc4fc20e7509af634f1c3a096710db1a2253090f5f1f107b9d258945a5546e9ba4
99bd3355994a436e25d148c68e097cca11f3c63e Make int128 overflow test use secp256k1_[ui]128_mul (Pieter Wuille)
3afce0af7c00eb4c5ca6d303e36a48c91a800459 Avoid signed overflow in MSVC AMR64 secp256k1_mul128 (Pieter Wuille)
9b5f589d30c3a86df686aadcde63eaa54eeafe71 Heuristically decide whether to use int128_struct (Pieter Wuille)
63ff064d2f7e67bb8ce3431ca5d7f8f056ba6bbd int128: Add test override for testing __(u)mulh on MSVC X64 (Tim Ruffing)
f2b7e88768f86b2fd506be4a8970ba6d1423d0a5 Add int128 randomized tests (Pieter Wuille)
Pull request description:
This is a follow-up to #1000:
* Add randomized unit tests for int128 logic.
* Add CI for the `_(u)mulh` code path (on non-ARM64 MSVC).
* Add heuristic logic to enable int128_struct based arithmetic on 64-bit MSVC, or systems with pointers wider than 32 bits.
* Fix signed overflow in ARM64 MSVC code.
ACKs for top commit:
roconnor-blockstream:
utACK 99bd335
real-or-random:
ACK 99bd3355994a436e25d148c68e097cca11f3c63e tested this also on MSVC locally with the override, including all the benchmark binaries
jonasnick:
utACK 99bd3355994a436e25d148c68e097cca11f3c63e
Tree-SHA512: 5ea897362293b45a86650593e1fdc8c4004a1d9452eed2fa070d22dffc7ed7ca1ec50a4df61e3a33dbe35e08132ad9686286ac44af6742b32b82f11c9d3341c6
a340d9500a9c45e5c261174f48b3eb18b3b3647d ci: add int128_struct tests (Jonas Nick)
dceaa1f57963d1a88b24974eab4b49baac6d04cd int128: Tidy #includes of int128.h and int128_impl.h (Tim Ruffing)
2914bccbc0913806ee64425a27d38cdc27b288e8 Simulated int128 type. (Russell O'Connor)
Pull request description:
Abstracts the int128 type and provides an native version, if available, or a implements it using a pair of int64_t's.
This is activated by setting the configuration flag `--with-test-override-wide-multiply=int128_struct`.
The primary purpose of this PR is to take advantage of MSVC's [umulh](https://docs.microsoft.com/en-us/cpp/intrinsics/umulh?view=msvc-170) intrinsic that we can use to simulate an int128 type which MSVC does not have (AFAIU). This PR lays out the groundwork for this level of MSVC support, but doesn't include the configuration logic to enable it yet.
For completeness, and implementation of `umulh` and `mulh` are also provided for compilers that support neither the intrinsic nor the int128 type (such as CompCert?). This also opens up the possibility of removing the 32-bit field and scalar implementations should that ever be desired.
ACKs for top commit:
sipa:
ACK a340d9500a9c45e5c261174f48b3eb18b3b3647d
jonasnick:
ACK a340d9500a9c45e5c261174f48b3eb18b3b3647d
Tree-SHA512: b4f2853fa3ab60ce9d77b4eaee1fd20c4b612850e19fcb3179d7e36986f420c6c4589ff72f0cf844f989584ace49a1cd23cca3f4e405dabefc8da647a0df679d
6a965b6b98bc08646c87bcfc826181e317079a9e Remove usage of CHECK from non-test file (Tobin C. Harding)
Pull request description:
Currently CHECK is used only in test and bench mark files except for one usage in `ecmult_impl.h`.
We would like to move the definition of CHECK out of `util.h` so that `util.h` no longer has a hard dependency on `stdio.h`.
Done as part of an effort to allow secp256k1 to be compiled to WASM as part of `rust-secp256k1`.
### Note to reviewers
Please review carefully, I don't actually know if this patch is correct. Done while working on #1095. I'm happy to make any changes both in concept and execution - I'm super rusty at C programming.
cc real-or-random
ACKs for top commit:
sipa:
utACK 6a965b6b98bc08646c87bcfc826181e317079a9e
real-or-random:
utACK 6a965b6b98bc08646c87bcfc826181e317079a9e
Tree-SHA512: 6bfb456bdb92a831acd3bc202607e80f6d0a194d6b2cf745c8eceb12ba675d03a319d6d105332b0cbca474e443969295e5a8e938635453e21e057d0ee597440b
After this commit, int128.h and int128_impl.h are included as follows:
- .c files which use int128 include int128_impl.h (after util.h)
- .h files which use int128 include int128.h (after util.h)
This list is exhaustive. util.h needs to included first because it sets
up necessary #defines.
Currently CHECK is used only in test and bench mark files except for one
usage in `ecmult_impl.h`.
We would like to move the definition of CHECK out of `util.h` so that
`util.h` no longer has a hard dependency on `stdio.h`.
Done in preparation for moving the definition of `CHECK` as part of an
effort to allow secp256k1 to be compiled to WASM as part of
`rust-secp256k1`.
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.
