-
Notifications
You must be signed in to change notification settings - Fork 35
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
Any plans to add support for schnorr signatures? #46
Comments
I want this package to build without flags, and work well against secp256k1 libraries as they are provided by major Linux distributions. If the package supports Schnorr signatures, it will fail to to build on some distributions, requiring a flag to hide Schnorr support by default. This would make it necessary to maintain automation that uses containers to run tests with and without the Schnorr flag, and perhaps even automatically compile and install secp256k1 as needed, before I can do releases. Container-based test setups are often finicky and require time and tweaks to work when things change upstream. At the moment I just need to run |
So that's a no? |
@jprupp libsecp256k1 version 0.2.0 is the version that was released with Schnorr enabled by default. So if we assume that distributions haven't disabled it, this page gives an overview of which releases have old versions of libsecp256k1: https://repology.org/project/libsecp256k1/versions For example, Ubuntu 22.04 LTS shipped an older version of libsecp256k1. 22.04's standard security maintenance runs until 2027. It's Expanded Security Maintenance runs until 2032. At which point would you consider adding Schnorr support? Before or after 2032? |
If current versions Ubuntu LTS, Debian Stable, Fedora and Nix all have the Schnorr support enabled, I would like to have this library include it, regardless of the support cycle duration for prior versions of the distributions. |
@jprupp Fedora is currently shipping the Bitcoin-ABC fork of the library, as you can see on packages.fedoraproject.org. It seems like they do not offer the upstream library associated with Bitcoin Core. Are these Haskell bindings prevented from supporting Schnorr as long as Fedora uses that fork? Otherwise, your conditions should be satisfied in April when Ubuntu 24.04 LTS comes out. |
Regarding my own question:
I have been looking through the tests, and it does seem like there is a difference in API:
The |
I'm the Fedora Linux maintainer, I will look into switching back to upstream since Schnorr have been added there, I also see that there is now proper releases, so that makes it easier to know when to upgrade. |
Out of curiosity, would there be any issue in simply vendoring the dependency explicitly as e.g. rust-secp256k1 does? No need to worry about what various distros are doing, then. |
Learned today that the Bitcoin-ABC and the Bitcoin-Core implementation of Schnorr differs, so it not only the API that is different |
It is usually not an issue as a package maintainer, I maintain at least two packages that does that [1][2]. If going that route, then it would be nice if it was easy to un-bundle, either with a flag during build or with a easy to read patch. Fedora Linux requires all binaries to be built by our infrastructure, so if upstream ships binaries then those are deleted before the build. [1] https://src.fedoraproject.org/rpms/python-hidapi |
That is not surprising, since Bitcoin Cash (which I think ABC is derived from?) added Schnorr before standardization had completed. As you can see in 2019-05-15-schnorr.md, it links to test vectors at @sipa's private WIP branch, which isn't even available any more. The completed standard is at bip-340.mediawiki, and it was only accepted in 2020. BTW, @hegjon, are you still going to switch Fedora to using the upstream version? |
I have built the Bitcoin-Core variant for Fedora rawhide (aka testing/unreleased), I will probably make a different package for Bitcoin ABC variant since the implementation differs, one issue is that both the libraries use the same .so library name, so I will probably also rename the file names. |
Citing @jprupp :
I think these conditions are now all fulfilled. It would be nice to hear if you're planning to add this before the end of this year? Because it seems silly to have everyone maintain their own forks. Which I think is what @hugohp and @GambolingPangolin are doing (correct me if I am wrong, please). |
Yes please add this feature if you can, as I have to work with a local fork |
libsecp256k1 exports schnorr signature functionality. Any plans to add include it in this module?
Thanks
The text was updated successfully, but these errors were encountered: