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.

Sign up for GitHub

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

Jump to bottom

Build flags needed? #25

Closed
FrankC01 opened this issue Jun 22, 2018 · 2 comments
Closed

Build flags needed? #25

FrankC01 opened this issue Jun 22, 2018 · 2 comments

Comments

@FrankC01
Copy link
Contributor

To build with ECDH and RANGEPROOF do I need to pass any flags into the build steps on the README or....?

Thanks
Frank
@instagibbs
Copy link
Contributor

flags into the configure step.

IIRC:

./configure --enable-experimental --enable-blah

@FrankC01
Copy link
Contributor Author

Great, I'm not that familiar with the tools/language so this is very helpful.

tomtau pushed a commit to crypto-com/secp256k1-zkp that referenced this issue Jul 9, 2020
@TheBlueMatt
Merge pull request BlockstreamResearch#25 from tamasblummer/ignore_in…
01fb305 
…tellij

ignore intellij files
jonasnick pushed a commit to jonasnick/secp256k1-zkp that referenced this issue Sep 19, 2023
@theStack
tests: simplify random_fe_non_zero (remove loop limit and unneeded …
dc55141 
…normalize)

`random_fe_non_zero` contains a loop iteration limit that ensures that
we abort if `random_fe` ever yielded zero more than ten times in a row.
This construct was first introduced in PR BlockstreamResearch#19 (commit 09ca4f3) for
random non-square field elements and was later refactored into the
non-zero helper in PR BlockstreamResearch#25 (commit 6d6102f). The copy-over to the
exhaustive tests happened recently in PR #1118 (commit 0f86420).

This case seems to be practically irrelevant and I'd argue for keeping
things simple and removing it; if there's really a worry that the test's
random generator is heavily biased towards certain values or value
ranges then there should consequently be checks at other places too
(e.g. directly in `random_fe` for 256-bit values that repeatedly
overflow, i.e. >= p).

Also, the _fe_normalize call is not needed and can be removed, as the
result of `random_fe` is already normalized.
jonasnick pushed a commit to jonasnick/secp256k1-zkp that referenced this issue Sep 19, 2023
@real-or-random
Merge bitcoin-core/secp256k1#1395: tests: simplify `random_fe_non_zer…
ee7aaf2 
…o` (remove loop limit and unneeded normalize)

c45b7c4 refactor: introduce testutil.h (deduplicate `random_fe_`, `ge_equals_` helpers) (Sebastian Falbesoner)
dc55141 tests: simplify `random_fe_non_zero` (remove loop limit and unneeded normalize) (Sebastian Falbesoner)

Pull request description:

  `random_fe_non_zero` contains a loop iteration limit that ensures that we abort if `random_fe` ever yielded zero more than ten times in a row. This construct was first introduced in PR BlockstreamResearch#19 (commit 09ca4f3) for random non-square field elements and was later refactored into the non-zero helper in PR BlockstreamResearch#25 (commit 6d6102f). The copy-over to the exhaustive tests happened recently in PR #1118 (commit 0f86420).

  This case seems to be practically irrelevant and I'd argue for keeping things simple and removing it (which was already suggested in bitcoin-core/secp256k1#1118 (comment)); if there's really a worry that the test's random generator is heavily biased towards certain values or value ranges then there should consequently be checks at other places too (e.g. directly in `random_fe` for 256-bit values that repeatedly overflow, i.e. >= p).

  Also, the _fe_normalize call is not needed and can be removed, as the result of `random_fe` is already normalized.

ACKs for top commit:
  real-or-random:
    utACK c45b7c4
  siv2r:
    ACK `c45b7c4` (reviewed the changes and tests for both the commits passed locally).

Tree-SHA512: 4ffa66dd0b8392d7d0083a71e7b0682ad18f9261fd4ce8548c3059b497d3462db97e16114fded9787661ca447a877a27f5b996bd7d47e6f91c4454079d28a8ac
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@FrankC01 @instagibbs