pull down to refresh

by shrec

Introduction Hello everyone. I’ve been developing a high-throughput implementation called UltrafastSecp256k1. The project, which was open-sourced on February 11th, 2026, started as an exploration of how modern hardware features (SHA-NI, AVX2, ARM64 Assembly) can be leveraged to push the limits of ECC performance across diverse platforms—from high-end x86 servers to resource-constrained IoT devices like ESP32-S3 and RISC-V boards.

The goal is to create a highly portable, constant-time, and branchless library that is accessible through multiple language bindings (12+ languages including Rust, Go, Swift, and Dart). I am reaching out to this community for a technical audit, feedback on the cryptographic primitives, and suggestions on our constant-time implementation.

...read more at delvingbitcoin.org

Smells like a whole lot of AI.

reply
1 sat \ 2 replies \ @shrec 7h

all benchmarks and tests are done by my self on real devices you easy can test all part of code make your own benchmarks and if you want contribution put them in repo discussions. thanks. will be very helpful

reply

You are not denying that the code is AI generated.

Just a little glitch in the matrix happened here:

reply
1 sat \ 0 replies \ @shrec 6h
You are not denying that the code is AI generated.
I use AI as a tool for implementation assistance, but architecture, design decisions, optimization strategy and validation are fully controlled and audited by me.
Every change is reviewed, tested, and validated with static analysis, sanitizers, and differential testing plans.
I take full responsibility for the code.
reply

I haven’t had the time to look into this properly yet. What makes you think that? Just asking!

reply

Excessive use of emojis, symbols, and em-dashes

And why does an EC library worry about unrelated things like Bitcoin addresses and dozens of other coins?

reply
22 sats \ 0 replies \ @shrec 23 Feb

Just finished the RISC-V optimization sprint for Milk-V Mars (SiFive U74). Using U74-specific in-order scheduling gave us a 34% boost in verification speed. This is part of the v3.11 roadmap to make UltrafastSecp256k1 the go-to library for resource-constrained IoT devices. Cycles don't lie! 🚀

reply

Thank you for the support and the sats, @0xbitcoiner and everyone!It’s exciting to see the community take interest in these optimizations. Our team has been working around the clock to push the boundaries of $secp256k1$ performance, especially for high-throughput environments.We just hit a major milestone with v3.10.x, achieving a +51% speedup in constant-time generator multiplication on x86-64 and significant gains on ARM64, all while passing 12,023 consistency tests.We are now focusing on v3.11, which will bring further refinements to Field Inversion and expanded hardware support for RISC-V. Feedback from this community is invaluable—feel free to dig into the code or the benchmarks on our GitHub.🚀 Onward to more speed and security!

0 sats \ 0 replies \ @5f05a3a705 22 Feb freebie -100 sats

I started with just $200 and, with the help of a skilled and disciplined trader, grew my account to $29,000. His accurate market analysis and strong risk management made it possible. On Robert Oliver On WhatsApp at +44 7459 127100 I’m truly grateful for the guidance and consistent results.

A high-performance secp256k1 library is a welcome development. Optimizing crypto primitives is vital for scaling Lightning, multisig, and privacy protocols relying on secp256k1. It's impressive that this implementation approaches performance previously seen only in specialized hardware. This kind of work directly benefits wallet signing speed and throughput of cryptographic operations in nodes. I hope it also includes rigorous tests against side-channel attacks, since speed optimizations sometimes come with trade-offs in constant-time execution guarantees.