Actually a cool read. Optional backend support sounds useful for testing/flexibility. Was compatibility or raw performance the bigger challenge here?
UltrafastSecp256k1 v4.0 — Optional Secondary secp256k1 Backend for Evaluation
4 Comments
@[juhist] Thanks — honestly compatibility/convergence ended up being the harder part.
Raw performance engineering is comparatively straightforward once you isolate invariants, reduce recomputation, optimize hot paths, and benchmark carefully.
The difficult part was making everything continuously agree with each other:
- shim behavior vs libsecp semantics
- CI vs actual execution paths
- benchmark claims vs generated artifacts
- docs vs implementation
- audit tooling vs real cryptographic properties
- platform-specific behavior
- rollback-safe integration
A large amount of the v4.0 cycle was spent fixing small edge-case bugs, compatibility mismatches, CI drift, and verification inconsistencies rather than chasing raw speed.
Performance improvements still happened during that process, but convergence/compatibility definitely consumed more engineering time overall.
Please log in to add a comment.
The optional backend approach is smart idea. No forced adoption, just measurable evidence.
262 exploit PoC modules in your CAAS is solid coverage. Most implementations stop at known-answer tests and fuzzing. Timing side channels and batch soundness are often missed.
I've small question on LTO. The ConnectBlock wins are real but the i-cache penalty without it creates a tradeoff. Do you recommend gating the Ultra flag behind Release+LTO detection for downstream integrators who might not control their build pipeline?
Hope to hear from you soon!
@[Gimi] Yes, non-blocking warning at cmake time is the right approach.
We just landed it. When SECP256K1_BACKEND=ultrafast + CMAKE_BUILD_TYPE=Release + no LTO, cmake now prints:
UltrafastSecp256k1: LTO is OFF
ConnectBlock throughput will be ~10% lower than bundled libsecp256k1
without Link Time Optimisation. With LTO it is +1-2% faster.
For production / packaged builds add:
-DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON
Why non-blocking (not error): Packagers running Debian/Ubuntu hardened builds, local dev builds, and CI without cpupower access all have legitimate reasons to skip LTO. Refusing the build would be hostile to the exact audience we want to adopt it.
The actual numbers from turbo-locked canonical benchmarks:
No-LTO + stripped build: ~-10% ConnectBlock (I-cache, 1.2 MB .text vs 400 KB)
LTO + any build: +1-2% ConnectBlock, +20-26% Schnorr signing
The I-cache story is honest: the algorithm depth that gives the signing wins (GLV, SafeGCD, FE52) is exactly what creates the .text pressure. LTO is the clean resolution — the linker colocates hot functions from both Bitcoin Core and Ultra together, eliminating the competition for L2/L3 cache lines. The warning makes that tradeoff visible without being gatekeeping.
Please log in to add a comment.
Please log in to comment on this post.
More Posts
- © 2026 Coder Legion
- Feedback / Bug
- Privacy
- About Us
- Contacts
- Premium Subscription
- Terms of Service
- Refund
- Early Builders
More From Vano Chkheidze
Related Jobs
- Senior Python Backend Engineer (Django) - RemoteProxify · Full time · Italian Republic
- Senior Backend Python Engineer AWS & CI/CD, RemoteMC Engineering Inc · Full time · Italian Republic
- Backend DeveloperAubay Italia · Full time · Italian Republic
Commenters (This Week)
Contribute meaningful comments to climb the leaderboard and earn badges!