Lightweight Key Database for BTC Puzzles

Check out this project on GitHub: https://github.com/Mcdouglas-X/Private-Key-Search-and-Ultra-Lightweight-Database-with-Public-Keys So, this setup is all about creating a database that holds interleaved bit patterns (like 010101...) with lengths of 15 bits or more. These bit patterns (let's call them Pp) are saved along with the count of public keys in between those patterns (Bi) and the total bits traversed to reach the end of each pattern (Tb). You need to have secp256k1 for this to work, which you can find here: https://github.com/iceland2k14/secp256k1 Database Layout The data is stored in a neat format that lets you pack thousands of public keys into just a few lines, making it super lightweight and easy to handle. In my previous version, 120 million keys took up 14 MB, but now, those same keys are crammed into just a 165 KB file. That's a massive drop of about 98.82% in size. Searching for Keys When searching for matches, the script runs through anywhere from 10,000 to 250,000 public keys in a single go (that's low_m). You can tweak that number to whatever you prefer, but I suggest sticking with 100,000 since that's the usual amount of keys between patterns. So, if you’ve got, say, 50,000 public keys between pattern A and pattern B, starting somewhere in the middle will help you quickly zero in on the next pattern, and the script will figure out your private key from there. Speed The search speed really hinges on how big your database is. For example, if you have a database with 100 million keys and your computer can handle 1 million keys per second, you’re looking at processing around 1 billion keys every second.

Are you sure it's a lightweight database? More like a Bloom filter, but secp256k1 is used instead of xxhash/murmurhash/etc.

yes, A Bloom filter is a probabilistic data structure used to test whether an element is present in a set. However, it does not store the elements themselves, but instead uses a series of hash functions to determine the presence of an element. Because of this, it is not possible to extract specific data, such as numbers, directly from a Bloom filter. That's why I say this is a database, you can access and reuse the data.

Great,Im also try use bit patterns. why only this patters Bi: 13806, Pp: 010101010101010, Tb: 13821 Bi: 10889, Pp: 101010101010101, Tb: 24725 Bi: 10637, Pp: 101010101010101, Tb: 35377 Bi: 186843, Pp: 010101010101010, Tb: 222235 were is 011011011 1001001  ? bro, how you calc from so little examples of bits (only 4 patterns)  fool privkey range ? thx

Have you considered using XOR filters?

The patterns I choose them like this to guarantee a balance between the weight of the DB and the search speed, but you can experiment with it. Whenever the same changes in both scripts are made, there will be no problems with PK calculations. Here:pk = (Rand - total_bits + Tb_in_t)-len(pattern) Then, a check is made, to avoid false positives. I really publish my ideas at your most basic point, so it is better understood.

Bro, you talk about first bits of pubkeys in your patterns, or patterns in privkeys ?

It is a bit by pairs and odd public keys, that is, the patterns are pubkeys sequences, in the code this can be seen.

I am implementing this datababase ( 1 bit per publickey ) i am grouping those in a 64 bits item and storing those 64bit integers in a Bloom filter for fast search, those need 29 bits per each 64 keys i think this will give more speed to the BSGS algorithm. If the speed is boosted by this method i am going to change the bloom filter for a XOR filter becuae i believe that it may need only 16 bits per each item of 64 bits ( This mean that each group of 64 publickeys can be stored in a 16 bits) The idea behind this database 1 item per bit might be some dubious because you need to some extra process to perform a search in the database, for example in my case, before this approach you only need to do a single subtraction (public key subtraction) and the compate it to the database, but now you need to do the original subtraction and then with that keys you need to contruct a item to compare in your database (bloom filter / short filter/ list / whatever) so you need to calculate other set of keys in order to be able to compare against your current database this mean thay you need more process. And not only 64 times more process you need more items to compare because you don't know if your target public keys is aligned with your current groups of keys. So i am testing this just to validate what speed i am going to have, I am working a the very low bit level with bit shift operations and I think that my current approach is the most efficient from the CPU point ot view. I am not using any string conversion so i think there should be a point where this database will be useful

I hope for good results! In the case of this specific database, I would create a custom XOR filter. Since I only need the total bits (Tb) value of each line in the database, I would configure XOR to return the necessary value according to the line found. However, since I don’t think this PC will ever handle a 10MB database, I haven’t given it much thought.

I am storing up to 1 TB of binary data: 8.7 trillions of keys: 8796093022208. This amout of bits grouped and stored in a bloom filter may need only 480 GB. But stored in a Xor filter it will use only near 256 GB so i am trying everything to compact it more and try to use better methods to the search of collisions and search of the offset of the keys.

@albertobsd how many pubkeys you archives 2^64 ? 2^64 is anoth for find 2^130 bit priv ? i find answers you archive 2^43 pubkeys. this is not anith for get privkey, need brute  2^87 range. I thin you know this, yes ?

Well, I do what I can with what I have at my disposal.

Then we are on the "search way", we do work what not get result asap, but , maybe  something was finded, for ex , my result 2^30 for 12191606 operations  but, this is mach slover then BSGS, probably  you find something similar too..... have a good day.

tell me that you who get the 130 puzzle "tell me "

Sadly no, I wan't that lucky person. By the way guys please keep this in topic for "Ultra-Lightweight Database with Public Keys" I am finishing my code for this database with my own approach  (64 keys grouped in a 64 bits integer and each 64bit integer stored in a bloom filter using only 29 bits per item), since BSGS Speed depends on the total items stored in the database first tests looks promising. Since i am not implementing the same approach/code of mcdouglasx i thing that I am going to open a new Topic for this, but all the credits of the bit database (1 bit per public keys) goes to him. Also I am donating to him.

Great

I truly believe that you are on the right track, managing more keys in BSGS keyhunt is, without a doubt, the path to important progress on this topic.

i`m realy sad for that you not the one  and i keep my eye on this topic "Ultra-Lightweight Database with Public Keys" and waiting for the new implementation

Can this script be used in any puzzler that has the pubkey revealed or does it only work in a specific bit wallet?