I have written a comment regarding what has happened in the past (soon) two years since I first proposed adding secp256k1 to Swift Crypto
Does anyone feel Ive missed something? Can anything be made better? More clear?
Thanks!
5 Likes
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 
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! 