secp256k1
safegcd-bounds
Our great sponsors
| secp256k1 | safegcd-bounds | |
|---|---|---|
| 9 | 2 | |
| 1,954 | 46 | |
| 1.4% | - | |
| 9.1 | 0.0 | |
| 9 days ago | almost 3 years ago | |
| C | Coq | |
| MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
secp256k1
-
Apple’s 2½ year old iPhone 12 is 6% faster than the new Samsung Galaxy S23 Ultra
Just yesterday I was trying to generate a vanity pub key for Nostr. I was using https://github.com/kdmukai/nostr_vanity_npub which uses the python-nostr library which in turn uses https://github.com/bitcoin-core/secp256k1.
The test (single thread with -j1 flag) has some interesting result. Time taken to calculate 1 million keys:
i7 8650U=2m5s,
-
Usage Of Cryptonite Library In GHCJS
That's a binding to the C library https://github.com/bitcoin-core/secp256k1, so it causes the exact same issue OP had with Cryptonite.
-
Binary GCD
The binary GCD has inferior performance to other approaches for big numbers because those min() comparisons require that you had to update the entire numbers at each step.
I submitted a writeup on the safegcd algorithm used by libsecp256k1 a while back, but it got the HN zomg-bitcoin-related quick flagging: https://github.com/bitcoin-core/secp256k1/blob/master/doc/sa...
Safegcd-like functions requires somewhat more iterations but most of the iterations need to only operate on the least significant bits of the numbers, which makes them faster in practice.
For safegcd-ish functions proving a hard upper bound on the number of require iterations is non-trivial. But it's useful to prove the bound in order to make constant time versions. Here is a writeup on our techniques for proving the upper bounds: https://github.com/sipa/safegcd-bounds#bounds-on-divsteps-it...
-
Dev Meeting Transcript (May 28, 2021)
[4:23 PM] fdov: Soulless | Scamcoin.onlinehttps://github.com/bitcoin-core/secp256k1/issues/451
-
Sha-256 input data type
And the one from libsecp256k1 (which underlies Bitcoin) and is optimized for HMAC: - https://github.com/bitcoin-core/secp256k1/blob/master/src/hash_impl.h
safegcd-bounds
-
Binary GCD
The binary GCD has inferior performance to other approaches for big numbers because those min() comparisons require that you had to update the entire numbers at each step.
I submitted a writeup on the safegcd algorithm used by libsecp256k1 a while back, but it got the HN zomg-bitcoin-related quick flagging: https://github.com/bitcoin-core/secp256k1/blob/master/doc/sa...
Safegcd-like functions requires somewhat more iterations but most of the iterations need to only operate on the least significant bits of the numbers, which makes them faster in practice.
For safegcd-ish functions proving a hard upper bound on the number of require iterations is non-trivial. But it's useful to prove the bound in order to make constant time versions. Here is a writeup on our techniques for proving the upper bounds: https://github.com/sipa/safegcd-bounds#bounds-on-divsteps-it...
What are some alternatives?
cryptohash-sha256 - Fast, pure and practical SHA-256 implementation
constantine - Constantine: modular, high-performance, zero-dependency cryptography stack for proof systems and blockchain protocols.
blst - Multilingual BLS12-381 signature library
RavenStash - Stash for Ravencoin-stuff.
Ravencoin - Ravencoin Core integration/staging tree
dhall - Maintainable configuration files
nostr_vanity_npub - Nostr vanity `npub` generator