[RFC] test: integrate secp256k1lab as subtree and use it for low-level EC ops #34287

1. 
   theStack commented at 5:27 pm on January 14, 2026: contributor

   This PR adds secp256k1lab as a subtree and uses it for low-level secp256k1 field and group arithmetic (i.e. replacing the contents of secp256k1.py) as a first step, primarily for demonstration purposes. Keeping it as a draft right now, to assess if there is conceptual support. The goal would be to keep the test framework code maintained here to Bitcoin Core specific parts and develop secp256k1-specific parts (e.g. MuSig, Silent Payments, FROST etc., to name a few upcoming ones) in secp256k1lab. I’m not sure if that’s a clear win from a maintenance perspective (it could e.g. add friction, having to depend on and coordinate with secp256k1lab maintainers), but I’m curious to hear opinions. Suggested e.g. in #32642#pullrequestreview-2881144268.

   Also, there are still some problems and open questions:

   • CI for “Windows native” job is failing (didn’t check in detail yet, but I assume the secp256k1lab folder is not found due to failing Path.resolve() symlink resolution, i.e. the library is searched within the build folder)
   • BIP340 signing/verification can’t be fully replaced yet (the test framework’s Schnorr signing in key.pyuses special testing parameters like flip_p and flip_r that aren’t available in secp256k1lab)
   • Where to place the subtree? Originally I added it in test_framework/crypto but moved it up directly to test, for not having to add a linter mypy exception, as it only targets test/functional/*; maybe adding the subtree to a new folder like test/libs would be better for clarity
2. Squashed 'test/secp256k1lab/' content from commit b2033d507f

   git-subtree-dir: test/secp256k1lab
   git-subtree-split: b2033d507f7855fe1670e58d80d481fd156554d1

   c0c509070f
3. Merge commit 'c0c509070fa5f9f0b3aff9375e4d63aa9be13e86' as 'test/secp256k1lab' 1e03c081db
4. test: use secp256k1lab for low-level field and group arithmetic (FE, GE, Scalar) b278ad91e6
5. 
   DrahtBot commented at 5:27 pm on January 14, 2026: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/34287.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

6. theStack marked this as a draft on Jan 14, 2026
7. DrahtBot added the label CI failed on Jan 14, 2026
8. 
   fjahr commented at 1:28 pm on January 15, 2026: contributor

   it could e.g. add friction, having to depend on and coordinate with secp256k1lab maintainers

   That would be my main concern. Having worked with the library for BIP specification I would be happy if we use it here too but test code is the part of the code base where we still manage to move relatively quickly and it would be a shame if adding test coverage here would be blocked by changes in secp256k1lab.

   The maintainers of secp256k1lab are also maintainers of secp256k1 and they a pretty busy usually so I would feel better about this if there was at least one other maintainer for lab, maybe with a Bitcoin Core focus.

   Alternatively maybe there can be a solution where we have a wrapper/companion to the library and the functionality that is not provided from it goes in there and in can be ported to lab whenever. That way we could at least not be blocked on conversations if a flip_p etc. should be added to lab or not. But I haven’t thought about what that would look like ideally.

   Where to place the subtree?

   It should be at least in functional/ because it wouldn’t be used outside afaict. Maybe in functional/test_framework/ directly and then the crypto folder could make a transition where it’s only containing hashing stuff and gets renamed accordingly at some point? I would be fine with a lib/ folder too but if we don’t plan to add anything else yet then I don’t think it’s needed.

Contributors
theStack DrahtBot fjahr

Labels
CI failed