Any plans to add support for schnorr signatures?

[hugohp]

libsecp256k1 exports schnorr signature functionality. Any plans to add include it in this module?
Thanks

[jprupp]

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 stack [--nix] test before shipping new releases, and know that the library will work on most Linux distributions, even those that can run Nix but do not ship secp256k1 directly.

[hugohp]

So that's a no?
Ok, I guess my option is to simply have a local FFI to Schnorr functionality.
Thanks!

[ysangkok]

@hugohp You can use the code linked in #40. No need to develop your own bindings.

[ysangkok]

@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?

[jprupp]

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.

[ysangkok]

@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.

[ysangkok]

Regarding my own question:

Are these Haskell bindings prevented from supporting Schnorr as long as Fedora uses that fork?

I have been looking through the tests, and it does seem like there is a difference in API:

• The upstream version uses secp256k1_schnorrsig_sign_custom and secp256k1_schnorrsig_sign32
• The ABC fork uses secp256k1_schnorrsig_sign

The sign32 variant was introduced in v0.2.0 of the upstream library (which is now on v0.4.0). So it seems like there can't be any ABI compatibility here, since the fork is lagging so far behind. I am assuming that distros will upgrade to recent versions of the upstream library.

[hegjon]

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.

[jtobin]

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.

[hegjon]

Learned today that the Bitcoin-ABC and the Bitcoin-Core implementation of Schnorr differs, so it not only the API that is different

[hegjon]

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.

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
[2] https://src.fedoraproject.org/rpms/hid4java

[ysangkok]

Learned today that the Bitcoin-ABC and the Bitcoin-Core implementation of Schnorr differs, so it not only the API that is different

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?

[hegjon]

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.

[ysangkok]

Citing @jprupp :

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.

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).

[hugohp]

Yes please add this feature if you can, as I have to work with a local fork
There is also another fork here: https://github.com/prolic/secp256k1-schnorr