Pages:
Author

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

full member
Activity: 1162
Merit: 237
Shooters Shoot...
Quote
fixed, please delete previous db.
So when using num and Low_m, we should use numbers that leave no remainder, correct?
Such as 2^32 / 2^26 = 64; this would be ok, right?
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
Something strange is definitely happening.
I have to calmly review the error.
-definitely not the collision margin.
-python expresses results wrong sometimes (I don't think so)
-the script gives good results but in certain cases it doesn't.
-Does the "bitstring" module sometimes fail?
- At a certain point in the database, bits are skipped and the calculations are not correct?
-does the script misinterpret some bytes?

Pk: 1033162084
Pk: 1033162084
Pk: 1033379684
Pk: 1033162084
Pk: 1033162084
Pk: 1033597284
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033379684
Pk: 1033488484
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033597284
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033488484
Pk: 1033597284
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033597284
Pk: 1033162084

edit:
These lines are definitely interfering.

Code:
Low_m= 16

lm= num // Low_m
Can you not rewrite lowmem script to something easier (less code)
And without bringing in the Bitcoin library?

Something like NotATether was mentioning?

fixed, please delete previous db.
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Something strange is definitely happening.
I have to calmly review the error.
-definitely not the collision margin.
-python expresses results wrong sometimes (I don't think so)
-the script gives good results but in certain cases it doesn't.
-Does the "bitstring" module sometimes fail?
- At a certain point in the database, bits are skipped and the calculations are not correct?
-does the script misinterpret some bytes?

Pk: 1033162084
Pk: 1033162084
Pk: 1033379684
Pk: 1033162084
Pk: 1033162084
Pk: 1033597284
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033379684
Pk: 1033488484
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033597284
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033488484
Pk: 1033597284
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033597284
Pk: 1033162084

edit:
These lines are definitely interfering.

Code:
Low_m= 16

lm= num // Low_m
Can you not rewrite lowmem script to something easier (less code)
And without bringing in the Bitcoin library?

Something like NotATether was mentioning?
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
Something strange is definitely happening.
I have to calmly review the error.
-definitely not the collision margin.
-python expresses results wrong sometimes (I don't think so)
-the script gives good results but in certain cases it doesn't.
-Does the "bitstring" module sometimes fail?
- At a certain point in the database, bits are skipped and the calculations are not correct?
-does the script misinterpret some bytes?

Pk: 1033162084
Pk: 1033162084
Pk: 1033379684
Pk: 1033162084
Pk: 1033162084
Pk: 1033597284
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033379684
Pk: 1033488484
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033597284
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033488484
Pk: 1033597284
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033162084
Pk: 1033597284
Pk: 1033162084

edit:
These lines are definitely interfering.

Code:
Low_m= 16

lm= num // Low_m
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
Quote
I'll check the script, maybe there's something I'm missing, do you use the "single key"?

Yes, the single key.

I am pretty sure I was getting the bad results when using the low memory script to generate the database.

I can run tests later, but maybe something is throwing it off when using the low memory script and writing to database file every x amount of keys?

I just created a db with low memory and all the results were correct.
share your script

Maybe you are not putting this part the same as when you created the db.

Code:
sustract= 16 #amount to subtract each time.

If you create a db with subtract= 16 in scan it should be the same.
If everything is correct and you continue to receive different pk, raise the collision margin a little from 64 to 80 (the higher the range you scan, the more likely a false positive is).
full member
Activity: 1162
Merit: 237
Shooters Shoot...
How many keys are you trying to generate?!
For me to make a 2^32 DB, it took over 5 hours. I used the low memory script and wrote to file 2^26 keys, roughly every 5 minutes. 64 (2^32 / 2^26) x 5 minutes = 320 minutes
Also, just for info, a DB with 2^32 values = 524 MB (incredible!)

Can you share your script to create the database file?
I want to create a file of size 2000000000 keys to test on puzzle 65.

I have it prefilled out for you:

Code:
#@mcdouglasx
import secp256k1 as ice
from bitstring import BitArray
import bitcoin


print("Making Binary Data-Base")


target_public_key = "0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b"

target = ice.pub2upub(target_public_key)


num = 2000000000 # number of keys.

sustract = 1 #amount to subtract each time.

Low_m= 200

#2^28 / 2^ 26 = 4
#2^29 / 2^26 = 8
#2^30 / 2^26 = 16
#2^32 / 2^26 = 64

lm= num // Low_m
   

sustract_pub= ice.scalar_multiplication(sustract)

res= ice.point_loop_subtraction(lm, target, sustract_pub)
binary = ''
for t in range (lm):

    h= (res[t*65:t*65+65]).hex()
    hc= int(h[2:], 16)
       
       
    if str(hc).endswith(('0','2','4','6','8')):
        A="0"
        binary+= ''.join(str(A))
           
    if str(hc).endswith(('1','3','5','7','9')):
        A="1"
        binary+= ''.join(str(A))
       

my_str = bytes(BitArray(bin=binary))

binary_file = open('130Bit.bin', 'wb')
binary_file.write(my_str)
binary_file.close()

for i in range (1,Low_m):
   
    mem= ice.to_cpub(ice.scalar_multiplication(lm).hex())
   
    Apk= bitcoin.multiply(mem, i)
   
    Apk_upu= ice.pub2upub(Apk)

    A1= ice.point_addition(target, Apk_upu)

    sustract_pub= ice.scalar_multiplication(sustract)

    res= ice.point_loop_subtraction(lm, A1, sustract_pub)
   
    binary = ''
    for t in range (lm):

        h= (res[t*65:t*65+65]).hex()
        hc= int(h[2:], 16)
           
           
        if str(hc).endswith(('0','2','4','6','8')):
            A="0"
            binary+= ''.join(str(A))
               
        if str(hc).endswith(('1','3','5','7','9')):
            A="1"
            binary+= ''.join(str(A))
           

    my_str = bytes(BitArray(bin=binary))

    binary_file = open('65Bit.bin', 'ab')
    binary_file.write(my_str)
    binary_file.close()

It will write to file, every 10,000,000 keys.

Let me know if it works for you.

binary_file = open('130Bit.bin', 'wb')
----------------------------------------
binary_file = open('65Bit.bin', 'ab')

I understand the meaning, only the names of the files need to be changed)


Correct, good catch. Change the one to 65Bit as well.
copper member
Activity: 205
Merit: 1
How many keys are you trying to generate?!
For me to make a 2^32 DB, it took over 5 hours. I used the low memory script and wrote to file 2^26 keys, roughly every 5 minutes. 64 (2^32 / 2^26) x 5 minutes = 320 minutes
Also, just for info, a DB with 2^32 values = 524 MB (incredible!)

Can you share your script to create the database file?
I want to create a file of size 2000000000 keys to test on puzzle 65.

I have it prefilled out for you:

Code:
#@mcdouglasx
import secp256k1 as ice
from bitstring import BitArray
import bitcoin


print("Making Binary Data-Base")


target_public_key = "0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b"

target = ice.pub2upub(target_public_key)


num = 2000000000 # number of keys.

sustract = 1 #amount to subtract each time.

Low_m= 200

#2^28 / 2^ 26 = 4
#2^29 / 2^26 = 8
#2^30 / 2^26 = 16
#2^32 / 2^26 = 64

lm= num // Low_m
   

sustract_pub= ice.scalar_multiplication(sustract)

res= ice.point_loop_subtraction(lm, target, sustract_pub)
binary = ''
for t in range (lm):

    h= (res[t*65:t*65+65]).hex()
    hc= int(h[2:], 16)
       
       
    if str(hc).endswith(('0','2','4','6','8')):
        A="0"
        binary+= ''.join(str(A))
           
    if str(hc).endswith(('1','3','5','7','9')):
        A="1"
        binary+= ''.join(str(A))
       

my_str = bytes(BitArray(bin=binary))

binary_file = open('130Bit.bin', 'wb')
binary_file.write(my_str)
binary_file.close()

for i in range (1,Low_m):
   
    mem= ice.to_cpub(ice.scalar_multiplication(lm).hex())
   
    Apk= bitcoin.multiply(mem, i)
   
    Apk_upu= ice.pub2upub(Apk)

    A1= ice.point_addition(target, Apk_upu)

    sustract_pub= ice.scalar_multiplication(sustract)

    res= ice.point_loop_subtraction(lm, A1, sustract_pub)
   
    binary = ''
    for t in range (lm):

        h= (res[t*65:t*65+65]).hex()
        hc= int(h[2:], 16)
           
           
        if str(hc).endswith(('0','2','4','6','8')):
            A="0"
            binary+= ''.join(str(A))
               
        if str(hc).endswith(('1','3','5','7','9')):
            A="1"
            binary+= ''.join(str(A))
           

    my_str = bytes(BitArray(bin=binary))

    binary_file = open('65Bit.bin', 'ab')
    binary_file.write(my_str)
    binary_file.close()

It will write to file, every 10,000,000 keys.

Let me know if it works for you.

binary_file = open('130Bit.bin', 'wb')
----------------------------------------
binary_file = open('65Bit.bin', 'ab')

I understand the meaning, only the names of the files need to be changed)

copper member
Activity: 1330
Merit: 899
🖤😏
@WP, do you notice anything in these keys?
Code:
Pk: 11739509615
Pk: 0x2bbbab36f = with subtraction value of 16384
Pk: 3102179535
Pk: 0xb8e780cf = with subtraction value of 32
Pk: 3119592975
Pk: 0xb9f1360f = with subtraction value of 32
As to why they all end in 5? With subtraction values all end in even numbers. Maybe you could try to test a few things with small size databases and with different values, to check their ending digits.
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Quote
I'll check the script, maybe there's something I'm missing, do you use the "single key"?

Yes, the single key.

I am pretty sure I was getting the bad results when using the low memory script to generate the database.

I can run tests later, but maybe something is throwing it off when using the low memory script and writing to database file every x amount of keys?
full member
Activity: 1162
Merit: 237
Shooters Shoot...
How many keys are you trying to generate?!
For me to make a 2^32 DB, it took over 5 hours. I used the low memory script and wrote to file 2^26 keys, roughly every 5 minutes. 64 (2^32 / 2^26) x 5 minutes = 320 minutes
Also, just for info, a DB with 2^32 values = 524 MB (incredible!)

Can you share your script to create the database file?
I want to create a file of size 2000000000 keys to test on puzzle 65.

I have it prefilled out for you:

Code:
#@mcdouglasx
import secp256k1 as ice
from bitstring import BitArray
import bitcoin


print("Making Binary Data-Base")


target_public_key = "0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b"

target = ice.pub2upub(target_public_key)


num = 2000000000 # number of keys.

sustract = 1 #amount to subtract each time.

Low_m= 200

#2^28 / 2^ 26 = 4
#2^29 / 2^26 = 8
#2^30 / 2^26 = 16
#2^32 / 2^26 = 64

lm= num // Low_m
   

sustract_pub= ice.scalar_multiplication(sustract)

res= ice.point_loop_subtraction(lm, target, sustract_pub)
binary = ''
for t in range (lm):

    h= (res[t*65:t*65+65]).hex()
    hc= int(h[2:], 16)
       
       
    if str(hc).endswith(('0','2','4','6','8')):
        A="0"
        binary+= ''.join(str(A))
           
    if str(hc).endswith(('1','3','5','7','9')):
        A="1"
        binary+= ''.join(str(A))
       

my_str = bytes(BitArray(bin=binary))

binary_file = open('130Bit.bin', 'wb')
binary_file.write(my_str)
binary_file.close()

for i in range (1,Low_m):
   
    mem= ice.to_cpub(ice.scalar_multiplication(lm).hex())
   
    Apk= bitcoin.multiply(mem, i)
   
    Apk_upu= ice.pub2upub(Apk)

    A1= ice.point_addition(target, Apk_upu)

    sustract_pub= ice.scalar_multiplication(sustract)

    res= ice.point_loop_subtraction(lm, A1, sustract_pub)
   
    binary = ''
    for t in range (lm):

        h= (res[t*65:t*65+65]).hex()
        hc= int(h[2:], 16)
           
           
        if str(hc).endswith(('0','2','4','6','8')):
            A="0"
            binary+= ''.join(str(A))
               
        if str(hc).endswith(('1','3','5','7','9')):
            A="1"
            binary+= ''.join(str(A))
           

    my_str = bytes(BitArray(bin=binary))

    binary_file = open('65Bit.bin', 'ab')
    binary_file.write(my_str)
    binary_file.close()

It will write to file, every 10,000,000 keys.

Let me know if it works for you.
copper member
Activity: 205
Merit: 1
How many keys are you trying to generate?!
For me to make a 2^32 DB, it took over 5 hours. I used the low memory script and wrote to file 2^26 keys, roughly every 5 minutes. 64 (2^32 / 2^26) x 5 minutes = 320 minutes
Also, just for info, a DB with 2^32 values = 524 MB (incredible!)

Can you share your script to create the database file?
I want to create a file of size 2000000000 keys to test on puzzle 65.
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
Regarding the scan script; if I use any subtract other than one, it always gets a false positive.

I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).

If you use a large subtraction number, the result shows up way out of the upper limit range.

Can you shed any wisdom as to why?


If in subtraction you used 16 to create the db in the search script you should do the same, it is not that they are false positives, it is that the pk calculation is deconfigured if it does not have the correct values.
I used the same subtraction values for the DB and the Scan scripts; and when I used values other than 1, I would get the incorrect values/false positives.

A few of what I am talking about.
Code:
Pk: 11739509615
Pk: 0x2bbbab36f = with subtraction value of 16384
Pk: 3102179535
Pk: 0xb8e780cf = with subtraction value of 32
Pk: 3119592975
Pk: 0xb9f1360f = with subtraction value of 32

The correct result should have been = 0xB862A62E

I'll check the script, maybe there's something I'm missing, do you use the "single key"?
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Regarding the scan script; if I use any subtract other than one, it always gets a false positive.

I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).

If you use a large subtraction number, the result shows up way out of the upper limit range.

Can you shed any wisdom as to why?


have you possible to generate DB more than 2**28?
I have generated a DB with 2**32 Keys in it.
how long its take?
3 hours nothing changed? no file *.bin created... what can be wrong& @mcdouglasx


Quote
Can you tell me how you created the database?
Apparently you have a different method for creating a database.
How many keys are you trying to generate?!
For me to make a 2^32 DB, it took over 5 hours. I used the low memory script and wrote to file 2^26 keys, roughly every 5 minutes. 64 (2^32 / 2^26) x 5 minutes = 320 minutes

Also, just for info, a DB with 2^32 values = 524 MB (incredible!)
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Regarding the scan script; if I use any subtract other than one, it always gets a false positive.

I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).

If you use a large subtraction number, the result shows up way out of the upper limit range.

Can you shed any wisdom as to why?


If in subtraction you used 16 to create the db in the search script you should do the same, it is not that they are false positives, it is that the pk calculation is deconfigured if it does not have the correct values.
I used the same subtraction values for the DB and the Scan scripts; and when I used values other than 1, I would get the incorrect values/false positives.

A few of what I am talking about.
Code:
Pk: 11739509615
Pk: 0x2bbbab36f = with subtraction value of 16384
Pk: 3102179535
Pk: 0xb8e780cf = with subtraction value of 32
Pk: 3119592975
Pk: 0xb9f1360f = with subtraction value of 32

The correct result should have been = 0xB862A62E
copper member
Activity: 205
Merit: 1
I have generated a DB with 2**32 Keys in it.

Can you tell me how you created the database?
Apparently you have a different method for creating a database.
copper member
Activity: 205
Merit: 1
Regarding the scan script; if I use any subtract other than one, it always gets a false positive.

I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).

If you use a large subtraction number, the result shows up way out of the upper limit range.

Can you shed any wisdom as to why?


have you possible to generate DB more than 2**28?
I have generated a DB with 2**32 Keys in it.
how long its take?
3 hours nothing changed? no file *.bin created... what can be wrong& @mcdouglasx


I have the same.
Range 45 bits, 100000000 keys. More than 12 hours of work, but still no database file...
The old version of the database creation script worked, the one that first saved it to a text file.
jr. member
Activity: 43
Merit: 1
Regarding the scan script; if I use any subtract other than one, it always gets a false positive.

I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).

If you use a large subtraction number, the result shows up way out of the upper limit range.

Can you shed any wisdom as to why?


have you possible to generate DB more than 2**28?
I have generated a DB with 2**32 Keys in it.
how long its take?
3 hours nothing changed? no file *.bin created... what can be wrong& @mcdouglasx
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
Regarding the scan script; if I use any subtract other than one, it always gets a false positive.

I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).

If you use a large subtraction number, the result shows up way out of the upper limit range.

Can you shed any wisdom as to why?


If in subtraction you used 16 to create the db in the search script you should do the same, it is not that they are false positives, it is that the pk calculation is deconfigured if it does not have the correct values.
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Regarding the scan script; if I use any subtract other than one, it always gets a false positive.

I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).

If you use a large subtraction number, the result shows up way out of the upper limit range.

Can you shed any wisdom as to why?


have you possible to generate DB more than 2**28?
I have generated a DB with 2**32 Keys in it.
jr. member
Activity: 43
Merit: 1
Regarding the scan script; if I use any subtract other than one, it always gets a false positive.

I've used subtract values from 16 up to in the thousands and always get a wrong result (false positive).

If you use a large subtraction number, the result shows up way out of the upper limit range.

Can you shed any wisdom as to why?


have you possible to generate DB more than 2**28?
Pages:
Jump to: