RFC: Integrate secp256k1lab v1.0.0 as subtree, use it for BIP-374

theStack commented at 9:25 pm on May 20, 2025: contributor

This PR integrates the recently released secp256k1lab prototyping library as a subtree [1] and uses it in the BIP-374 reference code as a drop-in replacement of the currently used secp256k1.py file (copied in from the Bitcoin Core functional test framework in 0c7e54d780d059ebbab345946d7c6adbc61fef15). This is intended to serve as a showcase in the hope of triggering a discussion with BIP maintainers and authors on how to best integrate current and future BIPs reference implementations that take use secp256k1 curve operations.

I chose to demo this on BIP-374 since that’s the BIP reference implementation I’m most familiar with, and as one can see in the last commit, the interface is fully compatible, i.e. there were no actual changes in the code logic needed. In order to find the vendored copy of secp256k1lab, Python’s sys.path is extended [2]. Similar integrations have been done in the bip-frost-dkg (https://github.com/BlockstreamResearch/bip-frost-dkg/pull/83) and bip-frost-signing (https://github.com/siv2r/bip-frost-signing/pull/23, still WIP) repos.

See also related mailing list threads:

first mentioning of a secp256k1 prototyping library in the ChillDKG thread: https://groups.google.com/g/bitcoindev/c/HE3HSnGTpoQ/m/Y2VhaMCrCAAJ (back then it was called “secp256k1proto”)
secp256k1lab announcement: https://groups.google.com/g/bitcoindev/c/f3MQRO-yxEw/m/cEi6Sd7LBwAJ

[1] added via the command $ git subtree add --prefix=python/secp256k1lab --squash https://github.com/secp256k1lab/secp256k1lab v1.0.0 [2] see e.g. https://github.com/BlockstreamResearch/bip-frost-dkg/pull/81 for an earlier uglier approach; extending sys.path also seems to be a bit hacky, but seems to be the typical way to achieve the goal

Squashed 'python/secp256k1lab/' content from commit 44dc4bd

git-subtree-dir: python/secp256k1lab
git-subtree-split: 44dc4bd893b8f03e621585e3bf255253e0e0fbfb

849750bd3b

Merge commit '849750bd3b69ca1c4afe31c4c2fc46d6fb9b707d' as 'python/secp256k1lab' 18f0081bf4

BIP-374: avoid using sys.path[0] to find current working directory

This approach is incompatible with the sys.path extension approach
in the next commit which is used to to find the vendored copy of
secp256k1lab, so use __file__ instead which works as well.

a49f422593

BIP-374: replace secp256k1.py with vendored copy of secp256k1lab 50b0747453

jonatack added the label Proposed BIP modification on May 21, 2025

jonatack added the label Process on May 21, 2025

murchandamus assigned murchandamus on Jun 20, 2025

murchandamus unassigned murchandamus on Jun 20, 2025

murchandamus requested review from murchandamus on Jun 20, 2025

real-or-random commented at 12:36 pm on January 8, 2026: contributor

Oh, I missed this PR. There’s a recent discussion on the specific issue of how to integrate libraries such as secp256k1lab here: #2004 (comment)

My suggestion there is that each BIP should vendor its own separate version. Having a single secp256k1lab for the entire bips repo will be problematic for multiple reasons:

What if authors of multiple BIP want to make modifications to the library code?
Having an “official” subtree makes secp256k1lab special in the BIPs repo. I don’t think there’s a reason that this library should have a special status, and if anything, it could lead to having two places where the library is maintained. This is bad for the BIP maintainers and for the secp256k1lab maintainers.
What if a future BIP wants to use a more recent version of secp256k1lab, which is not backward compatible?

murchandamus commented at 8:49 pm on January 8, 2026: contributor

My suggestion there is that each BIP should vendor its own separate version.

Sorry for not commenting, yet. I guess I didn’t have a good answer when I first saw your pull request, and then lost track of this. I would not want this repository to turn into a place where software development happens, which would seem inevitable if all BIPs are tied to one version of the library and eventually something would conflict. I like @real-or-random’s idea of BIPs bringing a snapshot of whatever version of secp256k1lab they want to rely on. @real-or-random via #2004 (comment):

We had raised that question in the context of ChillDKG over a year ago on the mailing list, specifically hoping to hear the opinion of the BIPs editors, but noone has commented so far: groups.google.com/g/bitcoindev/c/HE3HSnGTpoQ/m/Y2VhaMCrCAAJ (This post refers to the library as “secp256k1proto”. This was our working title before we switched to “secp256k1lab” when publishing the code in a separate repo.)

@real-or-random: TBH, I don’t think I fully understand the trade-offs of the approaches you proposed. I would prefer that any software with on-going development were maintained outside of the BIPs repository, but maybe we could chat some time so that I better understand the situation.

Let me try to simplify the discussion: If the BIP editors are okay with integrating a snapshot of secp256klab as a subtree in each bip-xxxx folder of a BIP whose code uses secp256k1lab (as currently proposed in this PR and in #2070), then I’m happy with that. I think it’s the best solution.

“Snapshot” means that it is a static thing, and maintenance of secp256k1lab will, of course, happen in its repo. I guess the only reason to ever touch a snapshot subtree in the BIPs repo is to fix a secp256k1 bug that specifically affects the BIP code that uses the library (and even in that case, other ways to resolve the overall issue could be considered).

theStack commented at 11:09 pm on January 8, 2026: contributor

@real-or-random @murchandamus: Thanks for the feedback. I agree that vendoring secp256k1lab per BIP makes much more sense. When I opened this PR, I was assuming a single “set in stone” version would be sufficient and secp256k1lab would likely remain backwards-compatible indefinitely (i.e. a subtree bump would never be problematic), but that assumption seems a bit far-fetched – especially with BIP-specific modifications. Closing this PR, will take a look at #2070 soon.

theStack closed this on Jan 8, 2026

RFC: Integrate secp256k1lab v1.0.0 as subtree, use it for BIP-374 #1855