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

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.

The correct result should have been = 0xB862A62E

Can you tell me how you created the database?
Apparently you have a different method for creating a database.

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.

how long its take?
3 hours nothing changed? no file *.bin created... what can be wrong& @mcdouglasx

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 have generated a DB with 2**32 Keys in it.

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

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?

- Can this script be useful for puzzles that don't have public key revealed?

- I wish someone can implement mcdouglasx script in C, it will be faster and more efficient in term of speed and RAM usage.

EDIT: I don't know how this script can be useful against the massive monster #130.

Lol, Sorry.
Added the new script, which solves it.

Lol, say what?

I was asking this:
If I want to generate 2^27 keys, but I am limited on RAM, how can I write say 2^20 keys to file, then the next 2^20 keys to file, until all 2^27 keys have been written to file?
Using the suggestion or your own, like NotATether was suggesting... i = (i + 1) % 8

Make sense?

I just tested and works, apparently that mistakes occurs when you try to put an additional line if you have an previous script, update.



The script works like this:

You have a database like this

1010100010110101000101101010001010101000101101000101101010101010001011010100010 1101010001010101000101101010001011011010100010000

target is =
1101010001011010100010101010001

The target is in:

10101000101101010001011010100010101010001011010001011010101010100010110101000101101010001010101000101101010001011011010100010000

If we separate in bits:

10101000 1011010 10001011 01010001 01010100 01011010 00101101 01010101 00010110 10100010 11010100 01010101 00010110 10100010 11011010 10001000

No coincidences were found.

edit:
I update.
- Script aggregate that solves the memory limit
​

Hi! get this error

num = 128000000

Traceback (most recent call last):
  File "D:\BTC\lightweight-database\lightweight-database\binary_Db.py", line 20, in
    hc= int(h[2:], 16)
        ^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 16: ''

How would you break it up as NotA was saying:

"|= 0 [or 1] << i; i = (i + 1) % 8"

for those with smaller RAM.

This script speeds up the creation of the database.


but as @WanderingPhilospher says

This will depend on the amount of RAM you have, of course.
However, That's what I did, I wrote 2^26 keys at once. Ate up at highest point, 14GB of RAM. If limited RAM you could do the counter as you suggested.

I have found a key in the 44 bit range in about 3-4 minutes, 5 or 6 times. It's an interesting script.

It's interesting in the way it can store massive amounts of "keys" in such a little file. For 2^26 keys, it only uses a file size of 8,192 kb. That is impressive.

The searching method is not great in terms of speed.

Also, you do not/should not use a start range of 1 (unless you are subtracting from original key and shrinking the key).

When I generated 2^26 keys with a num = 64 option, I set the start range to 8796093022208-(2^26-64) = 8796025913408. I do not know where the key is but I know it's max (17592186044415) and it's minimum (8796093022208) and since my subtraction was set at 1 (sequential with no steps such as using a subtraction as 7 or 10, etc) I know the target priv/pubkey will only be from Target down to - 2^26 (keys generated) - 64 (num option).

start (min) =   8796025913408
end  (max) = 17592186044415

That's how I approached this script when running tests.

You could also speed the script up using an upfront pub subtraction to cut the range in half. Example, if we know the key is in the 44 bit range, we can do an upfront subtraction of 0x80000000000, and then use that newly generated pub in this script and then search in a max 43 bit range.

Now to ponder how to add this script's storage size function to an existing GPU script...

I think you are writing the ones and zeros as bytes, when you should be writing them out as bits.

Here's what you should do to make your program faster. set a counter like i to 0, and then each time you perform a subtraction, do byte_value |= 0 [or 1] << i; i = (i + 1) % 8. Then only do a write after every 8 iterations. Although, you can make the writing process even faster by waiting until you fill thousands of bytes like this, and then just write them all at once in one batch.

you mean this range? 549755813887 :1099511627775
take into account:
pubkey is in range?
if you make jumps in database
subtract= 10, in scan set it the same.
Use 64 collision margin as long as you do not receive false positives, otherwise increasing it too much decreases your search speed.
At high ranges use multiple objectives to cover more space in the range.

I checked that the script is working correctly now.
But in the high ranges of 40 and above, there are no coincidences yet.
In principle, up to 40 bits and simple random can cope with the same success.

I'm sorry, I deleted the message because I'm not very sure of the solution, try this.

inx = f.find(s)
replace
inx = f.find(s)*sustract

Let me know if it gives you the correct pk at collision margin 64.

my apologies.
edit
apparently it has to do with the jump of 10 in subtraction, not with the collision margin
edit2:
fixed

---

To change N directly to secp256k1.dll you can do it with a hex editor.

The script works, the problem lies when it makes subtraction jumps other than 1, I hope it is solved.


This is a good option, the FUDs say that it is of no use, they do not see further, nor do they deign to try (blah blah), they only limit themselves to criticizing