Topic: lightweight database, for brute force using publickeys-32Mk =3.81MB(secp256k1) - page 5. (Read 2625 times)

About an hour and a half ago, I copied both scripts, created a database and launched the search script. I didn't change anything in the parameters.

On my PC, 100 keys found out of 100, ....  

Did you set the same parameters in both scripts?

The first version of the script worked, the second does not find matches.
There may be an error in the code.

Less than 20%? Did you try with the last version? Maybe the first version was not correct, I fixed some stuff.

I don't understand why:

1 bit for 2^32 keys is better than 64bits for 2^32/2^20 = 2^12 keys.

Less size, less search time, 100% keys found.


To speed up the serch, I need to store more information per byte, more density of information/work per byte stored.

For example, If I generated all 2^44 keys and I stored only the keys with the first 20 bit = 0, I would get a database with the same size of a databse created with 1 key each 1 million.

But the search time would be faster, cause I would need to check only 1 key against the database instead of 1 million.

Ok, when I ran your original script, it was less than 20% of the time the key was found.

Keep working on the database size. I know you will get it down!

If you can get it down to 1 bit per key like the OPs, then you're onto something. His DB is unmatched so far.

publick you scrypts pls ?

1) my original script (create_database) is not changed

2) not with the same amount of keys,  range is not equal to number of keys

number of keys stored = range / 2^20 in one case, and number_of_keys = range / 2^24 in other case

3) my script is basically BSGS:

big steps -> database : 1*G, 1*G+2^20*G, 1*G+2*2^20*G, 1*G+3*2^20*G, ...., range*G

small steps --> search:  P=k*G, k*G-G, k*G-2*G, k*G-3*G, ...., k*G-2^20*G

the only difference is: I'm triyng to reduce the size of database, storing only 64 bits for each key and other improvements.

4) my script finds the key every time? So far, yes.

Impressive!

How did you manage to make your database smaller compared to your original script? And why does it go up in size with the same amount of keys? Edit: I read it wrong as if you were storing 1 Mil keys every time lol.

Also, does your search script find the key every time?

I managed to get another improvement, using the symmetrie.

Instead of generating a interval [1 -> 2^40], if we shift the interval to [-2^39,2^39] then the 'positive' part has the same x-coordinates of the 'negative' part, so I can store only half keys (and have the same information).

Now these are my results:

-------------------------------------------------------------------------------
2^32 range

1 key each 2^20 (1 million)

time to generate the DB: 0.055 s
size of DB: 16kB

max time to find the private key : less than 2 seconds.
-------------------------------------------------------------------------------
2^36 range

1 key each 2^20 (1 million)

time to generate the DB: 0.26 s
size of DB: 256kB

max time to find the private key : less than 2 seconds.
-------------------------------------------------------------------------------
2^40 range

1 key each 2^20 (1 million)

time to generate the DB: 3.65 s
size of DB: 4 MB

max time to find the private key : 2 seconds.
-------------------------------------------------------------------------------
2^44 range

1 key each 2^20 (1 million)

time to generate the DB: 59 s
size of DB: 65 MB

max time to find the private key :  3 seconds.
-------------------------------------------------------------------------------
2^44 range

1 key each 2^24 (16 millions)

time to generate the DB: 3.65 s
size of DB: 4 MB

max time to find the private key : 31 seconds.
-------------------------------------------------------------------------------



I didn't upload the script yet.

Next step could be find a way to speed up the search, probably storing the keys in a different order.


Faster than BSGS ? No.

Could this script be faster than BSGS (Baby Step Giant Step)?

Or Are they similar to each other?

My results:

-------------------------------------------------------------------------------
2^32 range

1 key each 2^20 (1 million)

time to generate the DB: 0.060 s
size of DB: 32kB

max time to find the private key : less than 2 seconds.
-------------------------------------------------------------------------------
2^36 range

1 key each 2^20 (1 million)

time to generate the DB: 0.5 s
size of DB: 512kB

max time to find the private key : less than 2 seconds.
-------------------------------------------------------------------------------
2^40 range

1 key each 2^20 (1 million)

time to generate the DB: 7.3 s
size of DB: 8 MB

max time to find the private key : less than 2 seconds.
-------------------------------------------------------------------------------
2^44 interval

1 key each 2^20 (1 million)

time to generate the DB: 2 m
size of DB: 129 MB

max time to find the private key : less than 4 seconds.
-------------------------------------------------------------------------------
2^44 range

1 key each 2^24 (16 millions)

time to generate the DB: 7.3 s
size of DB: 8 MB

max time to find the private key : 30 seconds.
-------------------------------------------------------------------------------

The problem with my implementation is that the time search goes up with the size of DB and with the number of the keys I skip in the database creation.

The goal is to have a faster implementation for large intervals, not for small intervals

I updated my search_key script. Now it is a little faster.



Are you sure you have changed the parameters in both scripts (same parameters in both): create_database and seach_pk ?
Anyway I updated the search_pk (it is in the same post)

And were is your code ?

I modified the script to match what arulbero did; create a random priv/pubkey and find it.

Results for a key in the 32 bit range:


and


From start to finish. But it's not the speed, it's the size of the DB, only 121kb
Well I mean the speed is good for a single core. DB creation and search for the key and find it in under 9 seconds, 100% of the time.

The signal with copper pairs is deteriorated and obsolete, therefore they have recently changed to fiber that is why the price of installation + moden + ROUTER, the ADSL lines have a lot of noise, it is to be expected that they are more than 40 years old. antiquity.
and as for CUDA cores, it is not worth having a high-end GPU to program, although the high-ends have interesting technologies, which perhaps can be extrapolated to brute force.

So $120 for fiber, why not adsl? And how much would you say is enough to get a PC,  to work on CUDA? I have no doubts about your ingenuity and perseverance and I'm sure you will have a bright future.@OP.

Understood.

My search script is faster and only uses 0s and 1 like yours, but my binary files are about 4 times larger than yours because I’m not using the bitarray.

With all that said, this is a brilliant way to store large amounts of keys. And yes, I am also thinking on how to implement it with different programs.

Keep up the imagination; best breakthrough I’ve used/tested in awhile!

Yes I know it's slower, I apologize for that.

I did it this way to work with bits, because that's the way I think it should be done. While working with bits you are certain that you will find the key, without these keys being masked within the bytes.
My intention was not to do this to brute force directly with Python, as I said from the beginning, I am demonstrating an idea, C is better for this, unfortunately everything is against me.

- I don't have fiber optics, you can imagine what it would take me with 100kb/s to download what I need.
-my pc is an intel i5 4gb ddr 3 laptop.
- I live in an underdeveloped country where installing fiber costs $120 and is very difficult to find, not to mention a new PC.

I would love to do it in C, as soon as I have how I will do it, while I read about cuda, I learn things, I take notes on how games and software use the GPU in an efficient way.

I have other ideas how to apply this to bsgs, but while I write them in python as a draft.

Thank you so much. I found the code

Yoooo OP.

This is crazy lol.

Your revised search script you posted above, is over 7 times slower now.
I implemented a different way to search when your original search script didn't find the key using an increment, and when I run it compared to your revised version, mine is 7 times faster.
Now I have to unpeel it all and see what's going on.

I think this is what slows down your search script:

dat= BitArray(file.read())
versus
dat = bytes(file.read())

Look at my previous posts, I'm sure you'll find what you need.