ECDsa Verification Speed - page 2. | Bitcointalksearch.org

piotr_n

legendary

Activity: 2058

Merit: 1416

aka tonikt

I once had similar problem in Go - it's a pretty optimal compiler, but its current implementation of the big numbers lib is far away from optimal.

So for me it was like 10ms per op, which was still to long, so I decided to use the openssl implementation.
For a moment I even had a solution with a TCP server (written in C, with openssl) that was doing the ECDSAs for my actual app. That was pretty crazy, though it worked..

Later I figured out how to combine the openssl lib with my go app and ever since then it works as fast as I needed.

Most of the languages these days allow creation of wrappers for native libs - that's probably the best way for you to go as well.

jackjack

legendary

Activity: 1176

Merit: 1280

May Bitcoin be touched by his Noodly Appendage

You can try jasvet to see how much time it takes in Python

Remember remember the 5th of November

legendary

Activity: 1862

Merit: 1014

Reverse engineer from time to time

If this was implemented in C, it would be faster. I can see how the Java implementation can be slower.

piotr_n

legendary

Activity: 2058

Merit: 1416

aka tonikt

For such a CPU OpenSSL needs ~1ms per operation. Even less, if you use 64 bit arch.
So I would say that 100ms is not reasonable.

pmlyon

member

Activity: 72

Merit: 10

Hi, I'm working on a c# node implementation and I have a question around the verification of ECDsa signatures. I'm using the BouncyCastle library and calling ECDsaSigner.VerifySignature is taking ~100ms on a quad-core i5-2500K cpu. This means that if I max out all 4 cores I can process about 40 signatures per second. This seems extremely slow to me but I've not used ECDsa before. Does this seem like a reasonable signature verification speed? The wiki scalability page mentions being able to do tens of thousands of signature verifications per second.

Thanks,

Paul

Topic: ECDsa Verification Speed - page 2. (Read 3205 times)