I can’t comment much on these, but for performance benchmarks for example, the Nitrokey HSM (which uses a javacard AFAIK), does 80ms/ECC signature operation
Discussion
pretty fast for something without a dedicated power supply, i think my recent generation Zen processor does them in about 11us, i forget, hmmm imma check so i can speak confidently...
yes, about 11us for the bitcoin core library and 80us for the btcd library
I can get about 10k signature verifications per core per second on a 5950X, so about 100us per verification
this is using the unoptimized decred secp256k1 impl and fiatjaf’s go-nostr
oh yeah, sorry, i'm quoting hash/sign/verify here, i haven't actually benched it on here this is a test that signs and verifies using each library, on 9999 events, and probably forming the canonical message and hashing it is part of the operation
i'm really not bothered to test that stuff so much as verify that i've improved upon that shitty implementation, and i have, dramatically, 7x improvement, and since that improvement is likely more than just one thing i've improved, it's probably a net win of more than 20x in total
i am totally pissed at the C and C++ and Rust guys laughing at us Go programmers... on the basis of work done by DECRED devs
fuckin ridiculous
yeah, iirc my canonical marshal/hash operation costs about 4us on libsecp256k1 and 11us using go-nostr library, it's retardedly slower... hang on what are the figures i did bench this
https://github.com/mleku/nostrbench
yeah, 1 microsecond for the json op and half that for the binary encoder, and the easyjson is 1.7us idk what the hash function is and that's for the standard object format not the canonical array, which is more complex
my encoders are the fastest you can get in Go and yes i promise not to change them at this point
the downside: part of why it's faster is it isn't using strings, the runtime storage for id, pubkey and sig are raw binary, so it's kinda funny that's still faster than a runtime format that keeps them as hex strings to convert to hex... yes, i use the SIMD xxhex library from templexxx and minio/sha256 hash library for the hash functions, though that's nothing to do with the codec exactly
i'm pretty sure with my codec we have no excuse to not wipe the floor with the repeat myself a thousand time fanbois