secp256k1: Expose Jacobian point equivalency func. #3436
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
martonp
reviewed
Sep 5, 2024
martonp
approved these changes
Sep 5, 2024
davecgh
force-pushed
the
secp256k1_jacobian_point_equals
branch
from
22760ba
to
3e8b1b1
Compare
Good point. That would be less likely to potentially cause confusion of exact equality versus equivalent points. Updated. |
davecgh
changed the title
davecgh
commented
Sep 5, 2024
davecgh
force-pushed
the
secp256k1_jacobian_point_equals
branch
2 times, most recently
from
7dd885a
to
352daf3
Compare
jrick
approved these changes
Sep 5, 2024
davecgh
commented
Sep 5, 2024
davecgh
force-pushed
the
secp256k1_jacobian_point_equals
branch
from
352daf3
to
d0e846e
Compare
This splits the benchmarks related to curve operations into their own file to be more consistent with other benchmarks in the package.
This move the benchmarks related to public keys into their own file to be more consistent with other benchmarks in the package. It also removes the now empty bench_test.go file.
This splits the closure that determines if two Jacobian represent the same affine point by first converting them to affine points to a separate func for use in upcoming tests and benchmarks.
This exposes a new function on the JacobianPoint type named EquivalentNonConst which efficiently determines if two Jacobian points represent the same affine point without actually converting the points to affine. This provides a significant speedup versus first converting to affine for use cases that need the functionality. One example where it is useful is adaptor signatures. It includes comprehensive tests for edge conditions as well as ongoing randomized testing. The following benchmark shows a before and after comparison of checking Jacobian point equivalency with the new method versus the affine conversion approach: name old time/op new time/op delta -------------------------------------------------------------------------------- JacobianPointEquivalency 17.2µs ± 2% 0.5µs ± 1% -97.24% (p=0.000 n=10+10)
davecgh
force-pushed
the
secp256k1_jacobian_point_equals
branch
from
d0e846e
to
809d21b
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This exposes a new function on the
JacobianPointtype namedEquivalentNonConstwhich efficiently determines if two Jacobian points represent the same affine point without actually converting the points to affine.This provides a significant speedup versus first converting to affine for use cases that need the functionality. One example where it is useful is adaptor signatures.
It includes comprehensive tests for edge conditions as well as ongoing randomized testing.
Finally, it also includes some preliminary commits to make the benchmark structure more consistent and introduce a new benchmark for testing Jacobian point equivalency.
The following benchmark shows a before and after comparison of checking Jacobian point equivalency with the new method versus the affine conversion approach: