Updated motivation for supporting secp256k1

I have written a comment regarding what has happened in the past (soon) two years since I first proposed adding secp256k1 to Swift Crypto

You can find it here

Does anyone feel Ive missed something? Can anything be made better? More clear?



I appreciate it is holidays and you are all super busy, but friendly nudge @lukasa and @tomerd did you see my updates motivation on Github?

Happy new years guys! 2022 will be such an amazing year for Swift :heart_eyes:

Considering bitcoint/secp256k1 doesn't offer versioned or even tagged releases, it seems unsuitable to use it as a dependency, if a dependency outside of BoringSSL is even on the table. How is that library supposed to be consumed?

Right now I don’t wanna focus too much on implementation, since it is irrelevant if a PR with some solution always would be ignored/closed.

Since the current state is exclusion of secp256k1, I think we should focus on getting Apple onboard with the idea of the addition of this curve first.

@Jon_Shier as to answer your specific question, BoringSSL is just included with a specific commit hash in swift-crypto today… see e.g. this commit that updates the BoringSSL version, so why couldn’t the same method of inclusion of e.g. libsecp256k1 be used

Happy new year’s btw! :champagne:

Terms of Service

Privacy Policy

Cookie Policy