Topic: What would the math be behind these claims? (Read 518 times)

Using libsecp256k1+sipa's ec grind commit(which uses endomorphism) I get at most 13 million public keys per second(per core) using a batch of 4096. Which means 4 cores would equal roughly 52 million keys per second on my 8700k. If we use both compressed and uncompressed, I guess it automatically goes to ~104Mkeys/s.

Should I assume that you do not wish to make the math available? Or is it already implemented in libsecp256k1? Cause millions of combos per second is pretty good, on a CPU too.

I wrote that answer.

The current speed of the public keys generation on my laptop is 185 MKeys/s (I compute only compressed keys, only the "x" coordinates). It's real.

If I computed "y" coordinates too I could exploit the fact that (x,y) and (x, p-y) (that is the "symmetrie") are 2 valid points and maybe I would get more speed.
 

I'm talking about public keys generation, not addresses generation. The performance of addresses generation  is obviously lower, about 12.7 MAddresses/s (always on cpu)

If we compare vanitygen and my library on writing addresses speed (not only generation) the difference is even bigger:  

--> https://bitcointalksearch.org/topic/m.23710724


Secp256k1 library too is using optimizations to get more speed:  https://bitcointalksearch.org/topic/m.30174356

Even vanitygen can only do 500k/s with point addition(though we do include sha256 and ripemd160 hashing).

I was reading up on whether it was possible to get faster performance on key generation and came across this post https://crypto.stackexchange.com/questions/29885/can-a-billion-elliptic-curve-keys-be-generated-on-a-laptop-in-less-than-an-hour

The very last post claims pretty high numbers and wanted to know if it was bull or real. If it's real what would the math be for those kinds of speeds? And what is referred by "symmetrie" of seck256k1?

I was reading up on whether it was possible to get faster performance on key generation and came across this post https://crypto.stackexchange.com/questions/29885/can-a-billion-elliptic-curve-keys-be-generated-on-a-laptop-in-less-than-an-hour

The very last post claims pretty high numbers and wanted to know if it was bull or real. If it's real what would the math be for those kinds of speeds? And what is referred by "symmetrie" of seck256k1?

From an EC point of view, you have one private key with one corresponding public key.

The problem is, public keys can be serialized in two ways - compressed (33 bytes) or uncompressed (65 bytes). One is slightly harder to deal with, but as storage space is more critical in Bitcoin, we prefer to use the compressed one. Thus, we now have one private key that corresponds to (from Bitcoin's point of view, as we deal with the serialized versions) two public keys. Each of these public keys has an address (as the hash is calculated from the serialized public key). So, 1 private key, 2 public keys, 2 addresses.

So when you want to import a private key, the software has to know which of the public keys (with corresponding address) should be used. The solution is to add a flag bit to the base58 encoding of the private key, notifying the importer whether or not to use the compressed public keys. Typically, these get called compressed and uncompressed private keys - but it's really just a bit saying whether the corresponding public key is compressed or not.

The only reason not to use a compressed public key is that not all software supports it (they were introduced in Bitcoind/Bitcoin-Qt 0.6 only).

@MoonShadow: EC public keys are actually not numbers but a pair of numbers (X and Y coordinate), and the Y coordinate can be calculated from the X coordinate. That is how "compression" works - it's just a somewhat less redundant encoding. Testnet is unrealted to this.