brute-forcing public keys at amazing speed 2.2 PH/s on CPU [malware warning]

[Etar]

Hi, everybody!
You know that CPU XEON 2680v2 can brute-force public key (secp256k1 curve)  at speed 55TH/s per thread  
Totaly double CPU can do 2.2PH/s !!!!     ->>40 threads with 55TH/s each.


I mean that if you have public key and you whant to get private key of this public key, than you can do brute-forcing at this speed on CPU.
The indicated speed requires 32GB of RAM memory. Each doubling of memory leads to a 2-fold increase in speed. At 128GB you can get a speed of 10PH/s and so on..

For example:
You whant get private key from public key 0xa1eb046a8c225e0e173965a0ff7a4a899f745a3e2b3d21f926f4d59c955b4324bbd92c53c53c1 7404810a4c44ee82b5cdcebc1e62a56c4714c6c193ef10344a8
If you limit the memory to 4GB, you will get speed around 400TH/s at CPU XEON 2680v2
If starting private key will be 0x0000000000000000000000000000000000000000000000000000000000000001
Private key for this public key is 0x0000000000000000000000000000000000000000000000000013fea895f7b601
Totaly you need brute-force 5628024581502464 private keys. At speed 400TH/s you can do this in 14s -> 5628024581502464 / 400000000000000

Of course the number 2 ** 256 is incredibly huge and even such a speed is dust  

[1715094947]

1715094947

[1715094947]

1715094947

[1715094947]

1715094947

[gmaxwell]

Hi, everybody!
You know that CPU XEON 2680v2 can brute-force public key (secp256k1 curve)  at speed 55TH/s per thread  
Totaly double CPU can do 2.2PH/s !!!!     ->>40 threads with 55TH/s each.

That CPU cannot do *any* operation at that speed, not even a single 32-bit multiply. Your post is an outright untruth.

My guess is that you intend to trick people into running malware or just rip them off selling them cracking software that lies about its performance.

[Etar]

Hi, everybody!
You know that CPU XEON 2680v2 can brute-force public key (secp256k1 curve)  at speed 55TH/s per thread  
Totaly double CPU can do 2.2PH/s !!!!     ->>40 threads with 55TH/s each.

That CPU cannot do *any* operation at that speed, not even a single 32-bit multiply. Your post is an outright untruth.

My guess is that you intend to trick people into running malware or just rip them off selling them cracking software that lies about its performance.

if you do not know how, this does not mean that it is impossible.
I'm not going to post programs, source codes or algorithms. It's just a fact.

But any way i can prove speed in easy way  
You can make private in range
from
0x0000000000000000000000000000000000000000000000000000000000000001
to
0x00000000000000000000000000000000000000000000000031f5c4ed27680000
than make public key(64bytes) from this private key and  show me this public key.

Total points in this range 3600000000000000000, so i will limit speed to 1Ph/s and i my CPU should  brute-force this range in 1hour.
If i find private key that you make i will post him.
But if I fail, you must show your private key so that I can verify it with the public key you specify.

If i win, you should remove malware warning from topic, if i fail you can delete this topic. ok?

[Jean_Luc]

Hello,

Even if you solve ECDLP for a 64bits key, that does not prove the speed you announce.
You can use variant of the DP method on a reduced subset of private keys and get a complexity of O(2^32).
I wrote a GPU program that looks for partial collision on addresses (not the same process but the method is similar)
It founds 64bits collision in few minutes on a GTX 1050 Ti.
So post the code and we will see.

https://github.com/JeanLucPons/BTCCollider

[Etar]

Hello,
Even if you solve ECDLP for a 64bits key, that does not prove the speed you announce.
https://github.com/JeanLucPons/BTCCollider

There is no reference to 64 bits..
The desired private key can be located anywhere in the allowed range from 0x01 to 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
The only question is the time spent finding this key, and the speed from this will not change.
Only processor power affects the speed, the number of threads and the amount of allocated memory for searching.

Ok, programm used many optimizations and i can open 2 of them:
1 optimization>>
For ex. we start brutforce from key 0x01
We make public key from this privatkey -> 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483ADA7726A3C 4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
After this we  add in loop only G-point to this public key. And 1 to privatekey. So that in the cycle our private key and public match.
Each addition of a G-point gives the same effect as if adding 1 to private key and again getting a public key from it.
With this optimization we get rid of unnecessary conversions from the private key to the public key

2 optimization>>
if you now bottleneck in addplt function is inverse function that take many cpu time, so..
Instead of adding a G-point to the public key each time and spending a lot of time on it.
We can create an array of points that starts at point is G and each subsequent point is equal to the previous +G
For ex. we create array of 1000points.  so we can get diiferents for each point and our public key and in the and of array we will get total diiferents of this points
make 1time inverse for total diiferents value and after this we can calculate inverse for each point in array in simple way.
After this optimization you make 1 inverse for 1000 points enstead of 1000inverse.

[Jean_Luc]

You can make private in range
from
0x0000000000000000000000000000000000000000000000000000000000000001
to
0x00000000000000000000000000000000000000000000000031f5c4ed27680000
than make public key(64bytes) from this private key and  show me this public key.

You specify this range to prove your speed which is a 62bits range (not 64bits you're right).
If you want to prove your speed, post your code.
Solving ECDLP on sepck1 for a reduced priv key range does not prove the speed you announce.
The speed of a method depend first on the complexity of the used algorithm not only on the speed of the hardware.

[Etar]

You can make private in range
from
0x0000000000000000000000000000000000000000000000000000000000000001
to
0x00000000000000000000000000000000000000000000000031f5c4ed27680000
than make public key(64bytes) from this private key and  show me this public key.

You specify this range to prove your speed which is a 62bits range (not 64bits you're right).
If you want to prove your speed, post your code.
Solving ECDLP on sepck1 for a reduced priv key range does not prove the speed you announce.
The speed of a method depend first on the complexity of the used algorithm not only on the speed of the hardware.

i repeat again that no matter where your private key located.
This range was chosen only so that I could show that I can bruteforce this range in 1 hour
this range can be for ex. from
0x0000000000000000000000000000000000000000000000000013fea895f7b601
to
0x0000000000000000000000000000000000000000000000000027fd512bef6c02
any way total point will be 3600000000000000000 if i start with 0x0000000000000000000000000000000000000000000000000013fea895f7b601
if i start with 0x0000000000000000000000000000000000000000000000000000000000000001 i will need 2hour

[Jean_Luc]

You will just prove that you are able to solve ECDLP for a subset of priv key of a size near 2^62 in one hour.
But we have no proof of the algorithm used which can be in O(2^31).
Why you don't want to post your code ?

[Tamarindei]

Hi. It sounds like generic ECDLP "Baby step giant step" algorithm to me.
It's useful when you know the interval of the targeted privatekey only.

[gmaxwell]

But any way i can prove speed in easy way  
You can make private in range
from
0x0000000000000000000000000000000000000000000000000000000000000001
to
0x00000000000000000000000000000000000000000000000031f5c4ed27680000
than make public key(64bytes) from this private key and  show me this public key.

Total points in this range 3600000000000000000, so i will limit speed to 1Ph/s and i my CPU should  brute-force this range in 1hour.

That isn't impressive at all and wouldn't prove your claim.  Because you fix a range, you could simply have a table of 2^31 entries (1G, 2G, 3G) based on X-only, you step by twice the size of your table, checking only the X to get a positive and negative offset, and find the match in one hour at a terribly slow rate of 1.2 million keys a second.

At that speed you are missing even the most basic optimizations.

Go away scammer.

Or come back with a private key who's pubkey x coordinate begins with >=68 zero bits within two days... (other than the one with pubkey 00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63).

[Etar]

But any way i can prove speed in easy way  
You can make private in range
from
0x0000000000000000000000000000000000000000000000000000000000000001
to
0x00000000000000000000000000000000000000000000000031f5c4ed27680000
than make public key(64bytes) from this private key and  show me this public key.

Total points in this range 3600000000000000000, so i will limit speed to 1Ph/s and i my CPU should  brute-force this range in 1hour.

That isn't impressive at all and wouldn't prove your claim.  Because you fix a range, you could simply have a table of 2^31 entries (1G, 2G, 3G) based on X-only, you step by twice the size of your table, checking only the X to get a positive and negative offset, and find the match in one hour at a terribly slow rate of 1.2 million keys a second.

At that speed you are missing even the most basic optimizations.

Go away scammer.

Or come back with a private key who's x coordinate begins with >=68 zero bits within two days... (other than the one with pubkey 00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63).

I think yo do not understand what are you talking...
And if you do not understand the topic, you do not need to call everyone scammers. I did not post any files..
Give me public key what ever you whant and give me start private key with whom I can find public key for 1 day with speed 1Ph/s
this will drop options with tables 2 ^ 31
If i win you clear all the charges and apologize publicly for calling me a scammer.
Have you agreed?
If i failed you post private key from your public key, we compare him and and check if it falls outside the range of 1 day..
I can spend 1 day CPU resources to prove to you that you are wrong!

[Etar]

And it is clear test with other CPU.
I will use a slower processor I7 3770 (4core,8 threads) and the memory limit will be 8GB
I generate random private key in range
from
0x0000000000000000000000000000000000000000000000000000000000000001
to
0x00000000000000000000000000000000000000000000000031f5c4ed27680000

my private key turned out to 0x0000000000000000000000000000000000000000000000002022f3ed27580c00
the public key of this private key is
0x284e5d2ed67c10aa8be9ff03aa56969d3acfa3b5f4cf145617ce883f16c97bb4ad9c7b2da401a fb1bc49f96bf57ca58f9dd8a6de4bda706559ee23147de8c047

We give this public key to the program.
Note! It does not know about the private key.
Data preparation took about 10 minutes.
Each thread give 35TH/s, total 250TH/s
Brutforcing was completed in: 8411seconds
Total points that program brutforced: 2315681358314736639
Average speed: 275313GH/s

[gmaxwell]

I think yo do not understand what are you talking...

Clearly you're looking to fool people who don't, sadly for you I'm not one of them. Though the fact that you don't recognize that I do is odd...

Give me public key what ever you whant and give me start private key with whom I can find public key for 1 day with speed 1Ph/s

This is exactly the same as what you offered above-- you just offset the starting position of the interior step.

In what you describe, I choose x and y so that their difference is 60-ish bits. Then I give you y and xG.    You would compute yG - xG and begin adding steps of the 2 x table_size * G to it and looking up the result in the table.  Once you find a hit, you add the table position, the loop offset, and the y value to yield x.

What I described to you -- finding a private key whos pubkey begins with a long fixed string is an actual test of performance. To make it a better test, instead of zeros (which you could have precomputed over weeks or months) it would be better to use the hash of a recent block hash to bound the starting time. But zeros would be good enough for the discussion here.

I'm sure if you got anywhere near a 68 bit chosen prefix in two days you'd be setting a world record in "purebasic" computation for sure.

[Jean_Luc]

@Etar
Your tests does not prove anything.
If you want to prove your key rate, follow the test given by gmaxwell.
If you manage to get 275313 GKey/s , you should be able to find a public key (and its corresponding private key) with a X starting with ~60 zero bits in 1 hour, (~64 bits in 1 day)
And to be sure that you didn't make any precomputation we should choice a random starting key.

[Etar]

I think yo do not understand what are you talking...

Clearly you're looking to fool people who don't, sadly for you I'm not one of them. Though the fact that you don't recognize that I do is odd...

Give me public key what ever you whant and give me start private key with whom I can find public key for 1 day with speed 1Ph/s

This is exactly the same as what you offered above-- you just offset the starting position of the interior step.

In what you describe, I choose x and y so that their difference is 60-ish bits. Then I give you y and xG.    You would compute yG - xG and begin adding steps of the 2 x table_size * G to it and looking up the result in the table.  Once you find a hit, you add the table position, the loop offset, and the y value to yield x.

What I described to you -- finding a private key whos pubkey begins with a long fixed string is an actual test of performance. To make it a better test, instead of zeros (which you could have precomputed over weeks or months) it would be better to use the hash of a recent block hash to bound the starting time. But zeros would be good enough for the discussion here.

I'm sure if you got anywhere near a 68 bit chosen prefix in two days you'd be setting a world record in "purebasic" computation for sure.

Seems you realy do not understand))
I talk about brutforce (you know what is this?) and you are trying to impose a search for an incomprehensible pubkey that I can look for years.
look at fist post, i talk about brutforce speed, i am not talking that i can found ANY public key for 1hour or 1day

and what does 60 bit have to do with it?
1 day with speed 1ph it is 10^15*86400 points total = 86400000000000000000
2^60 it is 1152921504606846976 you see difference between numbers?
86400000000000000000  79 times bigger than 2^60

[MrFreeDragon]

1Ph/s speed is roughly 2^66 per 24 hours.
There is a bitcoin address with 0.64BTC and 64bit private key. You need 2^63 operations to bruteforce it.

If you have real speed 2^66 per 24 hours, so you can perform 2^63 operations juts for 24/(2^3)=3 hours.

So, welcome to prove your speed: just take 0.64BTC from this address: https://www.blockchain.com/btc/address/16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

The private key for this address is in the range: 0x8000000000000000 - 0xffffffffffffffff (64bit key, i.e. with 192 leading zeros)

[gmaxwell]

1Ph/s speed is roughly 2^66 per 24 hours.
There is a bitcoin address with 0.64BTC and 64bit private key. You need 2^63 operations to bruteforce it.

Man, why you gotta tell me this at 5am when I'm too tired to go actually attempt collect it. I'm going to guess the pubkey isn't available, or otherwise this would have already been solved.

[Etar]

1Ph/s speed is roughly 2^66 per 24 hours.
There is a bitcoin address with 0.64BTC and 64bit private key. You need 2^63 operations to bruteforce it.

If you have real speed 2^66 per 24 hours, so you can perform 2^63 operations juts for 24/(2^3)=3 hours.

So, welcome to prove your speed: just take 0.64BTC from this address: https://www.blockchain.com/btc/address/16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

The private key for this address is in the range: 0x8000000000000000 - 0xffffffffffffffff (64bit key, i.e. with 192 leading zeros)

Give me public key of this address (64bytes)

[gmaxwell]

Seems you realy do not understand))
I talk about brutforce (you know what is this?) and you are trying to impose a search for an incomprehensible pubkey that I can look for years.

No I am talking about finding the private key for ANY pubkey which matches a particular criteria: one where the first 60 bits are zero, so that it will take on average 2^60 operations to find it.

look at fist post, i talk about brutforce speed, i am not talking that i can found ANY public key for 1hour or 1day

Your first post said a speed of 2.2 PH/s.

and what does 60 bit have to do with it?
1 day with speed 1ph it is 10^15*86400 points total = 86400000000000000000
2^60 it is 1152921504606846976 you see difference between numbers?
86400000000000000000  79 times bigger than 2^60

And I suggested two days.

You should be able to find a key matching the property I described in about 2 days at 2.2PH/s.

[Jean_Luc]

1Ph/s speed is roughly 2^66 per 24 hours.
There is a bitcoin address with 0.64BTC and 64bit private key. You need 2^63 operations to bruteforce it.

If you have real speed 2^66 per 24 hours, so you can perform 2^63 operations juts for 24/(2^3)=3 hours.

So, welcome to prove your speed: just take 0.64BTC from this address: https://www.blockchain.com/btc/address/16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

The private key for this address is in the range: 0x8000000000000000 - 0xffffffffffffffff (64bit key, i.e. with 192 leading zeros)

Funny challenge but the public key is not exposed there ? If no, you need to hash...