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

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

Told you not to share anything public, no actually working script. ☠

---

So it only takes 1 bit to store a key? I can't imagine what would that be like with 100TB space to store, and with enough fire power + bsgs or keyhunt it should be easy to solve large keys.

Can you also change n to secp256k1 n - leading f's? To check if you can figure something out of it. I'd say there will be no floats if you do that.

You already deleted the message, but I saw it in the mail.
Here are other options.
But I don't see any difference.


Although knowing the first digit and 50% of the second, this greatly facilitates further work)
Thanks for the work done, I will continue testing.

By the way, for the 40-bit range there are no collisions at all.
What database size is required for higher ranges? How can one calculate the size for a specific range?
Is it possible to parallelize work across physical processor cores?

What is that? I don't understand, are they false positives?
If so, you must increase the collision margin from 64 to 128 or higher and problem solved.
It is still random+ scalar so you can increase the margin of precision thanks to scalar multiplication.

Edit:

Although I tested it with a collision margin of 64 and I did not get false positives. Maybe you are doing something wrong if you modified the code, share details and we will find a solution.

Tested for 35 bit range, 50 million keys.
You write that the probability of false collisions is small, but I see something else.

You only store binary sequences in large spaces, if you want to spread your database over the entire range, and not in the same consecutive range.
Using jump addition and subtraction to your target.