Open kchalkias opened 2 years ago
I just took a look at this function, and the R-values of signatures in ed25519-consensus are stored as compressed points, so it's hard to implement this optimisation as part of fastcrypto with the ed25519-consensus crate. Should we do this as a PR to ed25519-consensus instead?
@jonas-lj the author prefers to stick w their current implementation. As this optimization only makes sense for known pubKeys, we might need to have a new helper function or fork. Lets sync up offline.
ed25519-concensus batch verification is slower than ed25519_dalek due to extra deserialization/decompression requirements (In practice N extra point decompressions in ed25519-consensus). See https://twitter.com/kostascrypto/status/1566580906113912832 for more.