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

Feedback for secp256k1 #144

Open
Kixunil opened this issue Dec 19, 2022 · 2 comments
Open

Feedback for secp256k1 #144

Kixunil opened this issue Dec 19, 2022 · 2 comments

Comments

@Kixunil
Copy link

Kixunil commented Dec 19, 2022

From your readme:

type safety: Error cases you would typically have to deal with when using other APIs are ruled out at compile time using rust's type system.

Could you give examples or help to make the upstream secp256k1 itself more type safe? I think this kind of thing belongs there.

@LLFourn
Copy link
Owner

LLFourn commented Dec 19, 2022

note secp256k1 is not upstream from this crate. secp256k1 offers a high level API which is pretty type safe for most things that are designed to be done with it.

To give an example where secpfun's type safety is better than secp1s, when multiplying a non-zero point by a non-zero scalar we can rule out zero being a possibility here where as in secp256k1 you have to deal with a result: https://docs.rs/secp256k1/0.25.0/secp256k1/struct.PublicKey.html#method.mul_tweak.

This is not really a big deal though since you are not meant to implement crypto algorithms with secp1. The zero/non_zero type provided by secpfun really shines when you are implementing schnorr, musig, frost zkps from these primitives (which you should absolutely not do using secp1's API). It has caught loads of my mistakes!

@Kixunil
Copy link
Author

Kixunil commented Dec 20, 2022

Oh, so mul_tweak we should have NonZeroScalar and have a conversion for ThirtyTwoBitHash. That makes sense.

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

No branches or pull requests

2 participants