About 4 days of claude work, fully vibed:
"Across both the native C-to-C and the JVM/JNI comparison, our custom C secp256k1 implementation — written from scratch — matches or beats Bitcoin's libsecp256k1 on every Nostr-relevant operation, by roughly 10–30% on single ops (sign, verify, ECDH, pubkeyCreate, etc) and 4.5×–8.3× on batch verification."
"On batch operations, our batch verify for 200 events hits ~190,000 ev/s through JNI vs ~23,000 ev/s for JNI/libsecp verifying them individually today, a performance gain of ~826% over the current lib".
And yes, the lib not only passes all tests from Bitcoin core, but all of our event sign and verify tests as well.
Replies (22)
but... vibe coding cryptography...
Math a lot easier for AI than UI UX. Especially when tests and papers are fully available.
This sounds amazing. Is there a repo published anywhere?
Mixed up with amethyst, but I am still checking things out. Maybe I make a separate repo just for this.
people are even doing formal verification to cryptography... not just tests...
I mean it sounds like it would be a massive upgrade for relays
Not sure. The batch verify of schnoor requires batches of the same key. So a feed/profile gets more savings than relays, I think.
Yep, we will see what they say when they verify ours.
Already there
I have absolutely no idea what any of means, but I like it.
oh yeah well i vibed secp256k1 in pure go and skipped all the fancy bitshifting and speed hacks in lieu of highly readable stdlib code and produced something about 10x slower than the reference implementation. and it too passes all the reference tests 😎
Yeah that was our start too :)
Watch out
Idk if you're joking, but it's a serious concern. Vitor are you or someone close to this code a cryptogrqphery? Is this code going to be part of Amethyst?
did you make the operations constant time?
No, I got rid of it. We are not a wallet and the keys are always hot in memory. So the protection didn't do much given that the entire app has access to the key at all times. anyone trying to get the key from physical signals the phones electric circuit emits has a better chance of getting the key by observing other parts of the app, not just the signing.
I love it.
Oooh gotcha.
Claude still king? Moved to chatgpt for a trial for higher limits
On Kotlin, yes... For now...
Can you connect OpenAI subscription with OpenClaw and like ?
About 4 days of claude work, fully vibed:
"Across both the native C-to-C and the JVM/JNI comparison, our custom C secp256k1 implementation — written from scratch — matches or beats Bitcoin's libsecp256k1 on every Nostr-relevant operation, by roughly 10–30% on single ops (sign, verify, ECDH, pubkeyCreate, etc) and 4.5×–8.3× on batch verification."
"On batch operations, our batch verify for 200 events hits ~190,000 ev/s through JNI vs ~23,000 ev/s for JNI/libsecp verifying them individually today, a performance gain of ~826% over the current lib".
And yes, the lib not only passes all tests from Bitcoin core, but all of our event sign and verify tests as well.
