go-nostr has a libsecp256k1 wrapper now, in case you wanted 3x faster signature verification:

https://github.com/nbd-wtf/go-nostr/tree/d06f61136d67aea758845db5585642852d91ebdb/libsecp256k1

It probably works but has bugs, I don't know, but the tests look good.

By the way, is anyone using this library at all besides myself?

Reply to this note

Please Login to reply.

Discussion

yes, and it has come a long way in 2 years, thank you.

I do use it for my own nostr toys!

that library does schnorr signatures? i mean, they are still faster as they are since there's no division operation

you asked, i rewrote it and organised everything with nice names, wrote my own lazy envelope processor and an order-maintaining object marshaler, it uses SIMD SHA256 (minio) so you might want to add thing... you can actually override it even in consuming libraries by using a replace directive in your go.mod

oh yeah and i threw out the binary codec and just use gob, gob is faster and relatively future proof and you are only using it with a Go app so why waste your time writing a badly written binary codec (you could have at least used bytes.Buffer)

I'm not sure gob is faster than my codec, did you benchmark it?

it is most likely equal but by using very stable old code i eliminate complexity in my codebase

plus, seriously, the way you do the offsets is ugly

Yup!

I was going yo develop this exact library, awesome to see it

The cgo build may also add better performance, but in exchange it makes the build more difficult; the build step for applications distributed with Docker will be broken.

Using cgo makes the build step very difficult. A newbie who doesn't know what libsecp256k1 is probably won't be able to build a nostr app written in Go.

If possible, it might be better to use a non-go-nostr product.

It's in a separate package, not included by default. The rest of go-nostr should keep working normally without cgo, or am I wrong?

Oops, I didn't make sure that it was packaged separately. Sorry.