Repository navigation
How to handle libsecp256k1 ABI non-guarantees of stability #59
Description
taproot support is dependent on libsecp module that is experimental and can change its ABI (see #57 (comment))
and in general the ABI of libsecp is not a guaranteed thing, because they don't have releases yet
other projects just include particular version of libsecp source and build their own library, but that makes the package much havier and adds a lot of potential problems on installation related to compiling native code.
projects can just handle the compilation themselves and load their version of the library directly by supplying path to load_secp256k1_library(), via set_custom_secp256k1_path() or via LD_LIBRARY_PATH environment variable (on systems where it has effect)
This issue is for discussing the ways to handle the problem. What is the best way to handle this to enable the release that supports taproot ?
- Bundle libsecp with bitcontx and compile on install (anyone willing to help writing the needed code for that ?)
- Recommend using particular commit of libsecp with bitcointx, tell projects to handle supplying the correct version of the library themselves at runtime
- Leave as it is now - the hack that checks for
secp256k1_schnorrsig_sign_customas an indicator that the library version is after some particular commit and hope no other changes will happen - Do not merge taproot support into master branch and not do release until there's stable ABI for schnorr signatures in libsecp
Activity
dgpv commentedon Nov 3, 2021
The distro-installed version of libsecp is unlikely to have experimental modules enabled, so anyone who would want to use schnorr sigs will need to compile themselves anyway (until the module becomes non-experimental, at least), so I'm inclining towards combining the options 2 and 3.
dgpv commentedon Nov 3, 2021
The safest is the option 4, of course. But there's no timeline when such stabilization would happen, AFAIK.
dgpv commentedon Nov 3, 2021
We could make enabling the scnorr signature support explicit with some function, like
enable_experimental_schnorrsig_support(). Calling that function will be the indication that the caller is aware of the issue and is certain that the compatible version of the library will be loaded (kinda mirroring the libsecp 'experimental modules' concept)scgbckbone commentedon Nov 10, 2021
dgpv commentedon Nov 25, 2021
The chosen path is:
allow_secp256k1_experimental_modules()or PYTHON_BITCOINTX_ALLOW_LIBSECP256K1_EXPERIMENTAL_MODULES_USE=1 environment variable (this change is in taproot branch)3nprob commentedon Sep 28, 2025
Perhaps this can be revisited and a
pyproject.yamlapproach considered?