Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge v0.3.0 in FROST #20

Merged
merged 126 commits into from
Nov 22, 2023
Merged

Merge v0.3.0 in FROST #20

merged 126 commits into from
Nov 22, 2023

Conversation

matteonardelli
Copy link

No description provided.

real-or-random and others added 30 commits February 21, 2022 11:25
The code currently switches to the alternative formula for lambda only if (R,M)
= (0,0) but the alternative formula works whenever M = 0: Specifically, M = 0
implies y1 = -y2. If x1 = x2, then a = -b this is the r = infinity case that we
handle separately. If x1 != x2, then the denominator in the alternative formula
is non-zero, so this formula is well-defined.

One needs to carefully check that the infinity assignment is still correct
because now the definition of m_alt at this point in the code has changed. But
this is true:

Case y1 = -y2:
  Then degenerate = true and infinity = ((x1 - x2)Z == 0) & ~a->infinity .
  a->infinity is handled separately.
  And if ~a->infinity, then Z = Z1 != 0,
  so infinity = (x1 - x2 == 0) = (a == -b) by case condition.

Case y1 != -y2:
  Then degenerate = false and infinity = ((y1 + y2)Z == 0) & ~a->infinity .
  a->infinity is handled separately.
  And if ~a->infinity, then Z = Z1 != 0,
  so infinity = (y1 + y2 == 0) = false by case condition.

Co-Authored-By: Pieter Wuille <[email protected]>
02ebc29 release cleanup: bump version after 0.2.0 (Jonas Nick)
b6b360e doc: improve message of cleanup commit (Jonas Nick)

Pull request description:

ACKs for top commit:
  sipa:
    ACK 02ebc29

Tree-SHA512: b887e31a531f7d21025558ed0a64ff5f68dee6feff8288478f7eb023189ceb20e5ca8baf0434ebd2ee49488d35d7aebc1b837888ff8c6e6420e6b86cc2f99cb1
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 <[email protected]>
…bles as an error

7a74688 ci: add missing CFLAGS & CPPFLAGS variable to print_environment (Jonas Nick)
c2e0fda ci: set -u in cirrus.sh to treat unset variables as an error (Jonas Nick)

Pull request description:

  This PR is supposed to prevent accidental misuse of cirrus.sh. Maybe there is a way to check if `CC`, `AR` and `NM` are set within the loop that deals with the other variables, but so far I did not come up with one (that's POSIX shell compliant).

ACKs for top commit:
  real-or-random:
    ACK 7a74688
  hebasto:
    re-ACK 7a74688

Tree-SHA512: 91e42b3f1192fbf86e6fb43942713e78b2bee977ddd95256ea7448f84324369399d31ec4eedd47af595bf994bbc9396e26bb5c93bdb7f58c4310b5d3d5d66731
9c5a4d2 Do not define unused `HAVE_VALGRIND` macro (Hennadii Stepanov)
ad8647f Drop no longer relevant files from `.gitignore` (Hennadii Stepanov)
b627ba7 Remove dependency on `src/libsecp256k1-config.h` (Hennadii Stepanov)

Pull request description:

  Cherry-picked the first commit from bitcoin-core#1142 and addressed a [comment](bitcoin-core#1142 (comment)).

ACKs for top commit:
  sipa:
    utACK 9c5a4d2
  real-or-random:
    utACK 9c5a4d2

Tree-SHA512: c6f268261fc5edee855a7e69fdf9f6c5f4b859eb1e078e3c44c3ee4c9c445738af3de9fc2fbcca90db9b9e38681da8217faaeb0735201052b16ea397a7817db9
c30b889 Clarify that the ABI-incompatible versions are earlier (Pieter Wuille)
881fc33 Consistency in naming of modules (Pieter Wuille)
9ecf814 Reduce font size in changelog (Pieter Wuille)
2dc133a Add more changelog entries (Pieter Wuille)
ac233e1 Add links to diffs to changelog (Pieter Wuille)
cee8223 Mention semantic versioning in changelog (Pieter Wuille)

Pull request description:

ACKs for top commit:
  real-or-random:
    ACK c30b889
  jonasnick:
    ACK c30b889

Tree-SHA512: 0f753eae0ea4d65035bfbcd81b90169111ea030cf7196dd072fb1ccc8aac1437768031f3fcef431584028da68b66873204e16e03bcde4a6ae96b08ab7f97a480
… which returns (void)

a49e094 docs: Fix typo (Tim Ruffing)
2551cda tests: Fix code formatting (Tim Ruffing)
c635c1b Change ARG_CHECK_NO_RETURN to ARG_CHECK_VOID which returns (void) (Tim Ruffing)
cf66f23 refactor: Add helper function secp256k1_context_is_proper() (Tim Ruffing)

Pull request description:

ACKs for top commit:
  sipa:
    utACK a49e094
  jonasnick:
    ACK a49e094

Tree-SHA512: 0fd4ee88510f2de0de96378ae69ce6e610a446000bb78597026c5924803e1ce5a4f76303fc6446233a6129f9c42dce1b1549f93bef935131101e47b5a69cdf2f
d216475 test secp256k1_i128_to_i64 (Russell O'Connor)
4bc4290 Add a secp256k1_i128_to_u64 function. (Russell O'Connor)

Pull request description:

  I wanted to experiment with what would be required to split up `secp256k1_i128_to_i64` between those cases when a signed 64 bit value is being demoted, versus an unsigned 64 bit value is being extracted from the lower bits, and this is the result.

  I'm not sure this is a useful PR, so feel free to close it.  However, since it is already written, I figured it is worth at least discussing.

ACKs for top commit:
  sipa:
    utACK d216475
  real-or-random:
    ACK d216475

Tree-SHA512: 41dbb1d33b3078bee8e71a838cfad6f1859c0bba602ae061259add8e9e8ea5aa482daa41de79dbd7433ddbef4a0bc52757f3c45d63acc9c0eb05aa3ca891b922
…mpilation

c0a555b Bugfix: pass SECP_CONFIG_DEFINES to bench compilation (Pieter Wuille)

Pull request description:

ACKs for top commit:
  real-or-random:
    utACK c0a555b
  apoelstra:
    ACK c0a555b

Tree-SHA512: 4ec6ca4c012166beb6c5bdd1b2ed939554415e03545c176cf281000145c4000a460e231d5da26f617a81b048cd0fa3f8f16b61a207aed9479fdd854483e35ded
User applications shouldn't need or rely on `SECP_CONFIG_DEFINES`.
hebasto and others added 5 commits March 8, 2023 21:22
8be82d4 cmake: Rename project to "libsecp256k1" (Hennadii Stepanov)

Pull request description:

  Was discussed today on IRC.

ACKs for top commit:
  sipa:
    ACK 8be82d4
  real-or-random:
    ACK 8be82d4

Tree-SHA512: 4ea0fe6722c34acc50ebfba9f3c0503c773e268f8c3df6368e20c829ea800e3cb96758eec2813ed9f56ae4aae1f3919d8ae2755d55582e8c1811a08386f1b925
b40adf2 release: prepare for 0.3.0 (Jonas Nick)

Pull request description:

ACKs for top commit:
  sipa:
    ACK b40adf2
  real-or-random:
    ACK b40adf2
  hebasto:
    ACK b40adf2

Tree-SHA512: 221ba2d846804cefa139bee28b985414e293106cf63ef71ce4b34f815a62e5efd58d4ca6a03d6bcd5d843010d18f5be8d1cf43721a92e5196d732f5325499377
@matteonardelli matteonardelli force-pushed the frost-merge-0.3.0 branch 11 times, most recently from 80abae5 to d880d93 Compare November 22, 2023 10:24
In v0.3.0, secp256k1 also added support for building via CMake. Let's add a CI
workflow to exercise it.


Co-authored-by: Antonio Muci <[email protected]>
@muxator muxator force-pushed the frost-merge-0.3.0 branch 6 times, most recently from 7c56b9f to a6d843b Compare November 22, 2023 11:37
Copy link

@muxator muxator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@muxator muxator merged commit a6d843b into frost Nov 22, 2023
3 checks passed
@muxator muxator deleted the frost-merge-0.3.0 branch November 22, 2023 12:46
muxator pushed a commit that referenced this pull request Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants