WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1078
Merit: 219
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2023, 09:29:32 PM |
|
I modified slightly the OP's 'create_database' script (1 bit for key, 128 kB, distance between 2 keys = 1) it takes about 111 minutes (less than 2 hours) to generate 2**32 keys (4 billions), size of the DB = 512 MBThe script search takes less than 1 second to retrieve a key in this space. create_database.py #@mcdouglasx modified by arulbero import secp256k1 as ice from bitstring import BitArray
#########################DATABASE PARAMETERS######################### prefix = '28_0' data_base_name = 'data-base'+prefix+'.bin'
num_public_keys = 2**28 # 4 billions of keys num_bytes_db = num_public_keys//8 # 1 bit for each key sustract= 2**0 #amount to subtract each time, If you modify this, use the same amount to scan. sustract_pub= ice.scalar_multiplication(sustract) space_covered = num_public_keys*sustract #2**32 = 4 billions, space covered
#pk = 32 294 923 307 823 = 0x1d5f3f6e8b2f between 2**44 and 2**45 target_public_key = "03f760d768600e639758836fda5da546c10b1d84886165a5a1a4586192518aaf77" target = ice.pub2upub(target_public_key)
Low_m= 2**8 #to save ram lm= num_public_keys // Low_m ###################################################################
print("Making Binary Data-Base") print()
res= ice.point_loop_subtraction(lm, target, sustract_pub) my_str= BitArray(res[t*65+64]%2 for t in range(lm)) #0 if even, 1 if odd
with open(data_base_name, 'ab') as binary_file: my_str.tofile(binary_file)
for i in range (1,Low_m): lm_upub=ice.scalar_multiplication((lm*i)*sustract)
A1= ice.point_subtraction(target, lm_upub)
res=ice.point_loop_subtraction(lm, A1, sustract_pub) my_str=BitArray(res[t*65+64]%2 for t in range(lm))
with open(data_base_name, 'ab') as binary_file: my_str.tofile(binary_file)
print("Keys generated: " + str(num_public_keys)) print("Space covered by the keys spread with distance " + str(sustract) + " in the database : " + str(space_covered))
search_pk.py #@mcdouglasx modified by arulbero import secp256k1 as ice from bitstring import BitArray import random import sys
#########################DATABASE PARAMETERS######################### prefix = '32_0' data_base_name = 'data-base'+prefix+'.bin'
num_public_keys = 2**32 # 4 billions of keys num_bytes_db = num_public_keys//8 # 1 bit for each key sustract= 2**0 #amount to subtract each time, If you modify this, use the same amount to scan. sustract_pub= ice.scalar_multiplication(sustract) space_covered = num_public_keys*sustract #2**32 = 4 billions, space covered
#pk = 32 294 923 307 823 = 0x1d5f3f6e8b2f between 2**44 and 2**45 target_public_key = "03f760d768600e639758836fda5da546c10b1d84886165a5a1a4586192518aaf77" target = ice.pub2upub(target_public_key) ###################################################################
########################SEARCH PARAMATERS########################## num = 1024+512# collision margin in bits total_search_keys_to_generate = sustract split_total_keys = 2**0 #> 1 only if sustract > 1 multiple_search_keys_at_once = total_search_keys_to_generate//split_total_keys bytes_for_key = num//8
split_database = 2**3 #read only a fraction of the database to speedup the finding of the string and save RAM size_partial_db = num_bytes_db//split_database
pk_orig = 32294923307823 #pk = 32 294 923 307 823 = 0x1d5f3f6e8b2f between 2**44 and 2**45 space_search_start = pk_orig - space_covered #I'm assuming that all the space search is covered by keys in DB, space_search_end = pk_orig #otherwise we have to generate more than 'total_search_keys_to_generate = sustract' search_keys
##################################################################### print("Keys generated in DB: " + str(num_public_keys)) print("Space covered by the keys in DB (the keys are distributed in this space with distance " + str(sustract) + ") : " + str(space_covered)) print() print("This is the public key: " + target_public_key[2:]) print("I need to find this private key: " + str(pk_orig)) print() print("Scanning Binary Sequence") print("Looking in the range: "+str(space_search_start)+" " +str(space_search_end)) print()
while True: for t in range(split_total_keys): pk0=random.randint(space_search_start, space_search_end) b=BitArray() for r in range(multiple_search_keys_at_once): #how many different consecutive keys are generated at once against the keys in DB
target2 = ice.scalar_multiplication(pk0-t*multiple_search_keys_at_once-r) res=ice.point_loop_subtraction(2*num, target2, sustract_pub) b = b + (res[t*65+64]%2 for t in range(2*num)) #0 if even, 1 if odd #2*num -> means we utilize double size of collision margin for each key, in this way we can shift and obtain num windows of num bits b2 = () for r in range(multiple_search_keys_at_once): for j in range(num): b2 = b2 + b[(r*2*num)+j:(r*2*num)+j+num] #64 strings of 64 bits b3 = bytes(b2) b2_i = [ b3[j*bytes_for_key:j*bytes_for_key+bytes_for_key] for j in range(len(b3)//bytes_for_key)] set_search_keys = set(b2_i) with open(data_base_name, 'r+b') as f: for k in range(split_database): f.seek(0,1) partial_db = f.read(size_partial_db) dat_i = [partial_db[j*bytes_for_key:j*bytes_for_key+bytes_for_key] for j in range(size_partial_db//bytes_for_key)] set_database = set(dat_i) a = list(set_database & set_search_keys)
if(len(a) > 0): s = b2_i f = dat_i inx = f.index(a[0]) r_ind = s.index(a[0]) Pk = (pk0 - r_ind//num - (r_ind%num)*sustract - t*multiple_search_keys_at_once) + (k*size_partial_db*8 +(inx*num))*sustract print("Found!") if(Pk == pk_orig): print("The private key " + str(Pk)+ " was recovered successfully!") data = open("win.txt","a") data.write("Pk:"+" "+str(Pk)+"\n") data.close() sys.exit()
I like the creativity, but it seems like you already have to know the original pk. A lot of variables you have to sync up between the 2 scripts. I've been running a small 2^32 bit search and it's been running for 5 minutes with nothing found. That is with 2^21 keys generated with subtract of 2^4. This search should only take a few seconds. I should be able to give the DB script a pubkey, number of keys to generate and a subtract number, and then merely make sure the keys to generate and subtract number match up in the search script. Ok; your script is geared towards knowing the pk and searching from that pk - downwards. After changing these 2 lines: space_search_start = 0x80000000 #pk_orig - space_covered space_search_end = 0x100000000 #pk_orig
I was able to find the key. Running a search for the 2^36 key and it's been about 6 minutes with no key found. That is with 2^23 keys generated with subtraction of 2^4. This search takes way too long. Should be found within 10 seconds. Maybe I'm missing something.
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1078
Merit: 219
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 09, 2023, 10:02:17 PM |
|
When I run a 2^36 key test with my modified OP script, the results: This is the public key: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
Building the Binary Database
Targeting PubKey: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6 Number of PubKeys: 9,000,000 Writing to file every: 900,000 keys Subtract Value: 9
Scanning Randomly
Current Random Key: 0x9dafa302d Jumps Made: 983 PK Found: 42387769980 PK Found: 0x9de820a7c
Total Time: 0:00:19.863232
Under 20 seconds to create DB and find the key. Maybe I am missing something in your script arulbero.
|
|
|
|
arulbero
Legendary
Offline
Activity: 1915
Merit: 2074
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 10:56:52 AM Last edit: December 10, 2023, 03:20:48 PM by arulbero |
|
Running a search for the 2^36 key and it's been about 6 minutes with no key found. That is with 2^23 keys generated with subtraction of 2^4. This search takes way too long. Should be found within 10 seconds. Maybe I'm missing something.
There was a bug in the create_database script, now it is fixed (copy again that script) When I run a 2^36 key test with my modified OP script, the results: This is the public key: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
Building the Binary Database
Targeting PubKey: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6 [b] Number of PubKeys: 9,000,000 Writing to file every: 900,000 keys Subtract Value: 9[/b]
Scanning Randomly
Current Random Key: 0x9dafa302d Jumps Made: 983 PK Found: 42387769980 PK Found: 0x9de820a7c
Total Time: 0:00:19.863232
Under 20 seconds to create DB and find the key.Maybe I am missing something in your script arulbero. And maybe I don't understand your script ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 9,000,000 keys with subtract value = 9 means that (in my language) you are covering a 9M * 9 = 81M = 2**27 range, then you want to find a key (42387769980, that is in 2**36 range) in a database that cover a 2**27 range, is it correct? Why you made: Jumps Made: 983? In which range you generate your random private keys? In my 2 scripts: space_covered in the DB = number of key stored in db * subtract value and search_space = [priv_key - size_of_space_covered_by_DB, priv_key + size_of_space_covered_by_DB] I generate: 1) in DB: only keys equally spaced 2) in the search script: consecutive keys (and for each of these keys, 128 subtractions); in your example, 16 * 128 subtractions In search script only 1 key is random generated, then I generate consecutive keys_search with number of consecutive keys_search = sustract value, in this way the random key has 50% to produce a sequence of 64 bits that falls in the DB. For each of these keys I perform 2*64 subtractions. You have to set the parameters in this way: ###DATABASE##### prefix = '23_4' data_base_name = 'data-base'+prefix+'.bin' num_public_keys = 2**23 # 8 millions of keys num_bytes_db = num_public_keys//8 # 1 bit for each key sustract= 2**4 #amount to subtract each time, If you modify this, use the same amount to scan. space_covered = num_public_keys*sustract #2**27 = 128 millions, space covered Low_m= 2**3 # writing to file every: 2**23/2**3 = 2**20 keys = 1M target_public_key = "02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6" target = ice.pub2upub(target_public_key) > time python3 create_database.py Making Binary Data-Base
Keys generated: 8388608 Space covered by the keys spread with distance 16 in the database : 134217728
real 0m12,831s (but with Low_m = 2**7 it takes about 12s) user 0m12,030s sys 0m0,800s
> du -sh data-base23_4.bin 1,0M data-base23_4.bin
########################SEARCH PARAMATERS########################## num = 64# collision margin in bits (multiple of 64 bits) pk_orig = 42387769980 space_search_start = pk_orig - space_covered #in this way you know for sure that the space search contains the space covered space_search_end = pk_orig + space_covered > time python3 search_pk.py Keys generated in DB: 8388608 Space covered by the keys in DB (the keys are distributed in this space with distance 16) : 134217728
This is the public key: b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6 I need to find this private key: 42387769980
Scanning Binary Sequence Looking in the range: 42253552252 42521987708
Found! The private key 42387769980 was recovered successfully!
real 0m0,145s user 0m0,136s sys 0m0,009s
Then it takes about 13s to create the database and to retrieve the key. With: prefix = '28_4' num_public_keys = 2**28 #256 millions of keys num_bytes_db = num_public_keys//8 #1 bit for each key sustract= 2**4 #amount to subtract each time, If you modify this, use the same amount to scan. space_covered = num_public_keys*sustract #2**32 = 4 billions, space covered Low_m = 2**8 num = 256 #collision margin in bits (multiple of 64 bits) pk_orig = 42387769980 space_search_start = pk_orig - space_covered #in this way you know for sure that the space search contains the space covered space_search_end = pk_orig + space_covered it takes (on average) less than 1 second only to retrieve the key.
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1078
Merit: 219
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 03:38:03 PM |
|
Why you made: Jumps Made: 983?
In which range you generate your random private keys?
In my 2 scripts: space_covered in the DB = number of key stored in db * subtract value and search_space = [priv_key - size_of_space_covered_by_DB, priv_key + size_of_space_covered_by_DB] Correct. My subtract value + keys generated only need to stay less than the search range; or more than 0x0. The difference is, my script doesn't need to know the private key to find a key, but yours does/did. I can't go from, priv key - search space, because I do not know the priv key. So in my example, my search was limited to 0x800000000 - 0x1000000000; because I do not know the private key, I have to run random checks all through the range. If my script used a known private key and I could narrow the range down to priv key - search space, I am sure it would find the key much faster. I may took a look and test your script(s) again and modify it so the priv key is not known and test results. DB creation will always be close to the same speed since we basically use the same coding; search time should also be close.
|
|
|
|
arulbero
Legendary
Offline
Activity: 1915
Merit: 2074
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 04:24:40 PM |
|
Why you made: Jumps Made: 983?
In which range you generate your random private keys?
In my 2 scripts: space_covered in the DB = number of key stored in db * subtract value and search_space = [priv_key - size_of_space_covered_by_DB, priv_key + size_of_space_covered_by_DB] Correct. My subtract value + keys generated only need to stay less than the search range; or more than 0x0. The difference is, my script doesn't need to know the private key to find a key, but yours does/did. I can't go from, priv key - search space, because I do not know the priv key. So in my example, my search was limited to 0x800000000 - 0x1000000000; because I do not know the private key, I have to run random checks all through the range. If my script used a known private key and I could narrow the range down to priv key - search space, I am sure it would find the key much faster. I may took a look and test your script(s) again and modify it so the priv key is not known and test results. DB creation will always be close to the same speed since we basically use the same coding; search time should also be close. space_search_start = 0x800000000 space_search_stop = 0x1000000000 on average less than 2 seconds.
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1078
Merit: 219
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 04:28:48 PM |
|
Why you made: Jumps Made: 983?
In which range you generate your random private keys?
In my 2 scripts: space_covered in the DB = number of key stored in db * subtract value and search_space = [priv_key - size_of_space_covered_by_DB, priv_key + size_of_space_covered_by_DB] Correct. My subtract value + keys generated only need to stay less than the search range; or more than 0x0. The difference is, my script doesn't need to know the private key to find a key, but yours does/did. I can't go from, priv key - search space, because I do not know the priv key. So in my example, my search was limited to 0x800000000 - 0x1000000000; because I do not know the private key, I have to run random checks all through the range. If my script used a known private key and I could narrow the range down to priv key - search space, I am sure it would find the key much faster. I may took a look and test your script(s) again and modify it so the priv key is not known and test results. DB creation will always be close to the same speed since we basically use the same coding; search time should also be close. space_search_start = 0x800000000 space_search_stop = 0x1000000000 on average less than 2 seconds. Yeah I don't get less than 2 seconds when I run the range with your script. It's been running for 2 minutes now with no key found. Maybe you changed up all the other parameters?
|
|
|
|
arulbero
Legendary
Offline
Activity: 1915
Merit: 2074
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 04:38:12 PM |
|
Why you made: Jumps Made: 983?
In which range you generate your random private keys?
In my 2 scripts: space_covered in the DB = number of key stored in db * subtract value and search_space = [priv_key - size_of_space_covered_by_DB, priv_key + size_of_space_covered_by_DB] Correct. My subtract value + keys generated only need to stay less than the search range; or more than 0x0. The difference is, my script doesn't need to know the private key to find a key, but yours does/did. I can't go from, priv key - search space, because I do not know the priv key. So in my example, my search was limited to 0x800000000 - 0x1000000000; because I do not know the private key, I have to run random checks all through the range. If my script used a known private key and I could narrow the range down to priv key - search space, I am sure it would find the key much faster. I may took a look and test your script(s) again and modify it so the priv key is not known and test results. DB creation will always be close to the same speed since we basically use the same coding; search time should also be close. space_search_start = 0x800000000 space_search_stop = 0x1000000000 on average less than 2 seconds. Yeah I don't get less than 2 seconds when I run the range with your script. It's been running for 2 minutes now with no key found. Maybe you changed up all the other parameters? Did you copy again the create_database.py ? There was a bug. These are my parameters: prefix = '23_4' data_base_name = 'data-base'+prefix+'.bin' num_public_keys = 2**23 # 8 millions of keys num_bytes_db = num_public_keys//8 # 1 bit for each key sustract= 2**4 num = 128 # collision margin in bits (multiple of 64 bits) split_total_keys = 1 total_search_keys_to_generate = sustract multiple_search_keys_at_once = total_search_keys_to_generate//split_total_keys bytes_for_key = num//8 split_database = 2**0 #read only a fraction of the database to speedup the finding of the string and save RAM size_partial_db = num_bytes_db//split_database pk_orig = 42387769980 space_search_start = 0x800000000 space_search_stop = 0x1000000000
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1078
Merit: 219
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 04:41:03 PM |
|
Why you made: Jumps Made: 983?
In which range you generate your random private keys?
In my 2 scripts: space_covered in the DB = number of key stored in db * subtract value and search_space = [priv_key - size_of_space_covered_by_DB, priv_key + size_of_space_covered_by_DB] Correct. My subtract value + keys generated only need to stay less than the search range; or more than 0x0. The difference is, my script doesn't need to know the private key to find a key, but yours does/did. I can't go from, priv key - search space, because I do not know the priv key. So in my example, my search was limited to 0x800000000 - 0x1000000000; because I do not know the private key, I have to run random checks all through the range. If my script used a known private key and I could narrow the range down to priv key - search space, I am sure it would find the key much faster. I may took a look and test your script(s) again and modify it so the priv key is not known and test results. DB creation will always be close to the same speed since we basically use the same coding; search time should also be close. space_search_start = 0x800000000 space_search_stop = 0x1000000000 on average less than 2 seconds. Yeah I don't get less than 2 seconds when I run the range with your script. It's been running for 2 minutes now with no key found. Maybe you changed up all the other parameters? Did you copy again the create_database.py ? There was a bug. Yes, I did. I am running 2^23 keys with a spread of 2^4. That shouldn't matter, just wanted to let you know my params.
|
|
|
|
arulbero
Legendary
Offline
Activity: 1915
Merit: 2074
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 04:44:28 PM |
|
Did you copy again the create_database.py ? There was a bug.
Yes, I did.
I am running 2^23 keys with a spread of 2^4. That shouldn't matter, just wanted to let you know my params.
Are you sure to have set prefix = '23_4' in both scripts? In the script I posted, there was '32_0' do this check: du -sh data-base23_4.bin
1,0M data-base23_4.bin
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1078
Merit: 219
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 04:49:22 PM |
|
Did you copy again the create_database.py ? There was a bug.
Yes, I did.
I am running 2^23 keys with a spread of 2^4. That shouldn't matter, just wanted to let you know my params.
Are you sure to have set prefix = '23_4' in both scripts? In the script I posted, there was '32_0' Lol, yes. I am sure. It eventually found the key around the 4 minute mark running randomly in the 2^36 range. Two tests one took 4 minutes the other 3 min 30 sec. Running a 3rd now. Ok, I stopped the 3rd test and changed this line: num = 1024+512# collision margin in bits to num = 128 #1024+512# collision margin in bits Maybe that is the difference lol. Ok, 3rd test with 128 = 52 seconds search time. Changing it to 64 (why 128? that is crazy high, collisions shouldn't happen with 64) and rerunning test. Changing it to 64 = 44 seconds search time.
|
|
|
|
arulbero
Legendary
Offline
Activity: 1915
Merit: 2074
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 04:53:20 PM |
|
Did you copy again the create_database.py ? There was a bug.
Yes, I did.
I am running 2^23 keys with a spread of 2^4. That shouldn't matter, just wanted to let you know my params.
Are you sure to have set prefix = '23_4' in both scripts? In the script I posted, there was '32_0' Lol, yes. I am sure. It eventually found the key around the 4 minute mark running randomly in the 2^36 range. Two tests one took 4 minutes the other 3 min 30 sec. Running a 3rd now. I'm pretty sure you are using parameters for 2^28 or for 2^32 search space. These are my parameters: prefix = '23_4' data_base_name = 'data-base'+prefix+'.bin' num_public_keys = 2**23 # 8 millions of keys num_bytes_db = num_public_keys//8 # 1 bit for each key sustract= 2**4 num = 128 # collision margin in bits (multiple of 64 bits) split_total_keys = 1 total_search_keys_to_generate = sustract multiple_search_keys_at_once = total_search_keys_to_generate//split_total_keys bytes_for_key = num//8 split_database = 2**0 #read only a fraction of the database to speedup the finding of the string and save RAM size_partial_db = num_bytes_db//split_database pk_orig = 42387769980 space_search_start = 0x800000000 space_search_stop = 0x1000000000
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1078
Merit: 219
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 04:58:49 PM |
|
Ok, I changed this back to 1: split_total_keys = 1 #2**4 #> 1 only if sustract > 1 I had it at split_total_keys = 2**4 #> 1 only if sustract > 1 based on your note of greater than 1 if sustract is greater than 1. Now it's taking anywhere from 4 seconds to 15 seconds to find key. Your code is good. Just not easy to follow at times. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
arulbero
Legendary
Offline
Activity: 1915
Merit: 2074
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 05:02:37 PM |
|
Ok, I changed this back to 1: split_total_keys = 1 #2**4 #> 1 only if sustract > 1 I had it at split_total_keys = 2**4 #> 1 only if sustract > 1 based on your note of greater than 1 if sustract is greater than 1. Now it's taking anywhere from 4 seconds to 15 seconds to find key. Your code is good. Just not easy to follow at times. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 'Only' doesn't mean you have to set > 1, it is useful only if the db size is 2^28 keys or more, 2^23 is small. Now I run 40 times in a row: time for i in {1..40}; do python3 search_pk.py; done
and I got 91s, then 2.28 s for each key. Worst result: 8.5 s, but many other under 1 second. My script is not optimized to random search, but to 'consecutive' search.
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1078
Merit: 219
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 05:23:21 PM |
|
'Only' doesn't mean you have to set > 1, it is useful only if the db size is 2^28 keys or more, 2^23 is small. Difference in language maybe. But when I see something that says, split_total_keys = 1 #> 1 only if sustract > 1, it means if sustract is greater than 1, adjust, if not greater than 1, leave alone. Whereas if it said, split_total_keys = 1 #> 1 is useful only if the db size is 2^28 keys or more, then I would know it's an optimized option if keys are more than 2^x. All good. Your script works; very creative. I am currently working on trying to create the "wilds" in the DB and then run "tames" for the search. Keep your ideas and scripts coming arulbero. Many thanks for all of your insights over the last few years. You are Way smarter than me with python and ecc math, 100%!
|
|
|
|
arulbero
Legendary
Offline
Activity: 1915
Merit: 2074
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 05:44:01 PM |
|
I am currently working on trying to create the "wilds" in the DB and then run "tames" for the search.
Keep your ideas and scripts coming arulbero. Many thanks for all of your insights over the last few years. You are Way smarter than me with python and ecc math, 100%!
The ideas in my script are: - put 2^23 keys in 2^23 bits (mcdouglasx's idea) - then produce a random key P and from P get 128 (not 64) subtractions : P - sustract*G, P - 2*sustract*G, ..., P - 128*sustract*G - I get in this way a large string of 128 bits; from this large string I extract 64 strings of consecutive 64 bits (from 1 to 64, from 2 to 65, from 3 to 66, ..., from 65 to 128) - I do the same thing for: P-1G, P-2G, P-3G, ..., P -(sustract-1)*G - now each key is represented not by 1 but by 64 strings of 64 bits each. In this way I can mantain low the size of the database. - I compare all these strings (4 bytes each) against the database where the databases is divided in groups of 4 bytes each (in this case, the database is a set of 2^23/2^6 = 2^17 elements of 4 bytes each) - to see if an element of 4 byte is in database, i intersect the set of the 4 bytes elements of the databases with the set of the 4 bytes elements generated in the search; this step is pretty fast, because python automatically creates an hashtable.
|
|
|
|
mcdouglasx (OP)
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 240
Merit: 53
New ideas will be criticized and then admired.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 10, 2023, 06:15:39 PM Last edit: December 10, 2023, 06:44:55 PM by mcdouglasx |
|
@macduglasx hi, how you provide working with mulpubs, about ram it’s clear and what about threads ? 1pub=1th? Tnx
I don't understand what you mean, but I will still upload a basic BSGS version for those in the know to explore with that. since I'm busy. edit: basic BSGS version https://bitcointalk.org/index.php?topic=5477342
|
I'm not dead, long story... BTC bc1qxs47ttydl8tmdv8vtygp7dy76lvayz3r6rdahu
|
|
|
ecdsa123
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 211
Merit: 105
Dr WHO on disney+
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 11, 2023, 09:05:54 PM Last edit: December 11, 2023, 09:59:43 PM by ecdsa123 |
|
Edited: Test 1: without pucked res= 1011011010010000111100101010100010100101111101011010101101111111 len= 64 with pucked once res= b690f2a8a5f5ab7f len= 16 maximum pucked res= ¶ò¨¥õ« len= 8
Test2: without pucked res= 1011011010010000111100101010100010100101111101011010101101111111101101101001000011110010101010001010010111110101101010110111111110110110100100001111001010101000101001011111010110101011011111111011011010010000111100101010100010100101111101011010101101111111 len= 256 with pucked once res= b690f2a8a5f5ab7fb690f2a8a5f5ab7fb690f2a8a5f5ab7fb690f2a8a5f5ab7f len= 64 maximum pucked res= ¶ò¨¥õ«¶ò¨¥õ«¶ò¨¥õ«¶ò¨¥õ« len= 32
directory={} def make_combination(directory): result=0 for i in range(2**4): comb = bin(i)[2:].zfill(4) #print(kombinacja) directory[comb]=str(hex(result)[2:]) result+=1 def get_comb(data,directory): my_str="" for i in range(0, len(data), 4): fragment = data[i:i+4] my_str+=directory[fragment] return my_str make_combination(directory)
def change(binary,data): len_bin=len(binary) gum=str(binary[len_bin-4:len_bin]) data+=get_comb(gum,directory) return "",data
def maximum_pack(data): result="" if len(data)%2!=0: print("it must be divided by 2") else: for i in range(0, len(data), 2): value=data[i:i+2] dec_value = int(value, 16) result+=chr(dec_value) return result res="1011011010010000111100101010100010100101111101011010101101111111"
result="" res_help ="" for i in range(0,len(res)): val=res[i] res_help+=val if len(res_help)%4==0: res_help,result=change(res_help,result)
result_maximum=maximum_pack(result)
print("without pucked res=",res,"len=",len(res)) print("with pucked once res=",result,"len=",len(result)) print("maximum pucked res=",result_maximum,"len=",len(result_maximum))
If you database with 64 MB -> after maximum pucked -> you have 8 MB (eight time less) if you have 256 MB - database is 32 MM if you Have 2 GB ->256 MB ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) better don;'t you? Edit : 8 TB in 1 TB database... ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1078
Merit: 219
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 11, 2023, 11:17:08 PM Last edit: December 11, 2023, 11:49:37 PM by WanderingPhilospher |
|
After more script tweaking, I can generate a 20,000,000 key database in less than 10 seconds. Search time less than 2 seconds. 36 Bit Result: This is the public key: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
Building the Binary Database
Targeting PubKey: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6 Number of PubKeys: 20,000,000 Writing to file every: 20,000,000 keys Subtract Value: 1 Space Covered: 20,000,000 / 0x1312d00
DB Generation Time: 0:00:09.604563
Scanning Randomly
Current Random Key: 0x9dd926219 Jumps Made: 291 PK Found: 42387769980 PK Found: 0x9de820a7c
Search Time: 0:00:01.815859
Total Time: 0:00:11.420422
EDIT: If I use the BitArray option, as in original code, 20,000,000 keys generated into DB takes right at 4 seconds.
|
|
|
|
WanderingPhilospher
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 1078
Merit: 219
Shooters Shoot...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 11, 2023, 11:19:42 PM |
|
Edited: Test 1: without pucked res= 1011011010010000111100101010100010100101111101011010101101111111 len= 64 with pucked once res= b690f2a8a5f5ab7f len= 16 maximum pucked res= ¶ò¨¥õ« len= 8
Test2: without pucked res= 1011011010010000111100101010100010100101111101011010101101111111101101101001000011110010101010001010010111110101101010110111111110110110100100001111001010101000101001011111010110101011011111111011011010010000111100101010100010100101111101011010101101111111 len= 256 with pucked once res= b690f2a8a5f5ab7fb690f2a8a5f5ab7fb690f2a8a5f5ab7fb690f2a8a5f5ab7f len= 64 maximum pucked res= ¶ò¨¥õ«¶ò¨¥õ«¶ò¨¥õ«¶ò¨¥õ« len= 32
directory={} def make_combination(directory): result=0 for i in range(2**4): comb = bin(i)[2:].zfill(4) #print(kombinacja) directory[comb]=str(hex(result)[2:]) result+=1 def get_comb(data,directory): my_str="" for i in range(0, len(data), 4): fragment = data[i:i+4] my_str+=directory[fragment] return my_str make_combination(directory)
def change(binary,data): len_bin=len(binary) gum=str(binary[len_bin-4:len_bin]) data+=get_comb(gum,directory) return "",data
def maximum_pack(data): result="" if len(data)%2!=0: print("it must be divided by 2") else: for i in range(0, len(data), 2): value=data[i:i+2] dec_value = int(value, 16) result+=chr(dec_value) return result res="1011011010010000111100101010100010100101111101011010101101111111"
result="" res_help ="" for i in range(0,len(res)): val=res[i] res_help+=val if len(res_help)%4==0: res_help,result=change(res_help,result)
result_maximum=maximum_pack(result)
print("without pucked res=",res,"len=",len(res)) print("with pucked once res=",result,"len=",len(result)) print("maximum pucked res=",result_maximum,"len=",len(result_maximum))
If you database with 64 MB -> after maximum pucked -> you have 8 MB (eight time less) if you have 256 MB - database is 32 MM if you Have 2 GB ->256 MB ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) better don;'t you? Edit : 8 TB in 1 TB database... ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) The only question/problem I can ask/see, how do you implement it on the fly and check the DB for a collision/found key? You would create the DB, then "puck" it; then how do you run a search against the pucked DB?
|
|
|
|
ecdsa123
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 211
Merit: 105
Dr WHO on disney+
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 11, 2023, 11:33:54 PM |
|
Yes i know not puck but pack:-) sorry
everything is going on fly and database and search.
|
|
|
|
|