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.
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).
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!