explorer?

• processing 19495846/214Can't read the file seen you have less items that the amount needed
• processing 19964144/2147483648 bP points : 0%

What recommend when I run on Linux Subsystem on Windows 10?
and limited with low memory

OP, what is the tool in the screenshots you're using to calculate the curve points? Did you make it or is it some open source java program from Github?

I have a program that find the key in 1ms. It is written in sql. Local database. Here is the sourcecode. It is OpenSource:

select privatekey from compressed_bitcoinadresses where adress="122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8";

I have a program that find the key in 1ms. It is written in sql. Local database. Here is the sourcecode. It is OpenSource:

select privatekey from compressed_bitcoinadresses where adress="122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8";



I just showed you my 1ms opensource program (puzzle #39). You can show me yours and we can compare them.

I have no idea either...no way to write 15 billion in one minute, IMO, at least not on my hardware. Best I could do was about 200K a minute. Let me better explain. Normally when I do a search/look for keys, whether random or sequential, one of my GPUs will get 200MKey/s, but when I try to write the results, it drops to 0.1MKey/s because of the writing to file/RAM. So the bottleneck to me, is all in the CPU writing to file.

Are you looking for uncompressed or compressed?
Since I do not know your purpose in this, I can't help you to shorten the pubs.
Regardless, 20 million priv keys and corresponding pubkeys should only take up about 2.5Gb in storage space.

Hi everyone, i will update the code today with a new version, this new version is a little more faster and use less RAM, using less RAM meaning tha you can load a bigger bP Table with a bigger K value.


Thanks

bP points are G values, G, 2G, 3G, etc...

aMP points vary with the the values -n value or -k value

check this link to see a good explanation of the BSGS algo: https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/


My program dont generate that file by default, i really dont want to sature the HDD of the users of my program.

If you want to generate the bPfile by your own use the bPfile program is already compilied in the last version of keyhunt.

https://github.com/albertobsd/keyhunt/blob/main/bPfile.c




aMP Points change if you change your -n value or -k value. I can publish the tool to generate that file, but i need to add some "self-test" in the main program just to avoid that some user load a different or wrong files.


The program only do one math operation to check if one publickey is in a especific Range

https://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/

So only one publickey is generated from sustractions and additions and that is compared agains all the bloom filter (bPTable)

If you read the link you will see that if we have a Range N we get an M value getting the squaredroot of N, the K factor was an Iceland recomendation, we can load in the bloom filter kM elements from G to kM, and we only are going to need M/k operaions instead of the orginal M operations sugested in the link.

for fast speed I think write to memory first and save one may be better but it require high memory ram, my experience write data to memory still slows same write file
if you want to save file why not use python code generate and save
I guess result is slow same, but try modify one for know from real
one warning you storage will be full very fast
if testing just 100GB and delete
if want to keep recommend to buy minimum 2 TB external storage to keep it
bitcrack generate fast
make sure you computer not working anything may be write to disk like program freeze no respond (work 100% DISK)

So you are merely wanting to store private keys and their corresponding public keys, correct? In the same file or separate files?
combined file:
combined.txt
private key   public key

separate files:
privfile1.txt
private key
pubfile 1.txt
public key

Instead of trying to store all the k*G numbers (which is clearly impossible with current commodity storage sizes) why don't you just store all keypairs 2^n and 2^n * G [n is an integer], in other words powers of two?

They are extremely easy to generate since you just have to use successive point doubling, and any private key between G and 2^256*G can be generated fairly quickly by adding points that are powers of two (by looking at the integer multiplier). This is what VanitySearch does when it computes public keys, it makes a jump table with all of these powers of 2 Gs and then looks up the point in a hashtable using the factor as an index.

it is normal.
I think it is too fast.

1086000828893888512 keys in 30 seconds

• Added 0 points from file
• Setting N up to 17592186044416.
• Init bloom filter for 4194304 elements : 11.00 MB
• Allocating 128.00 MB for aMP Points
• Precalculating 4194304 aMP points
• Allocating 64.00 MB for bP Points
• precalculating 4194304 bP points
• Sorting 4194304 elements

Total 1086000828893888512 keys in 30 seconds: 36200027629796283 keys/s
Total 2176681179275591680 keys in 60 seconds: 36278019654593194 keys/s
Total 3263473656541478912 keys in 90 seconds: 36260818406016432 keys/s
Total 4346941210644971520 keys in 120 seconds: 36224510088708096 keys/s

Generation/compare is easy at 15 billion in under a minute; it's the writing to disk that is unachievable at that speed, unless you have a high core count CPU. And even then, I don't know if you could write 15 billion keypairs in under a minute.

If I understand you correctly, you are saying that Bitcrack should write the address of each private key it finds to a file?

How would that speed up key searching? Bitcrack doesn't even encode addresses anyway (it only decodes them to RIPEMD160 hash at the beginning of a search) so modifying it to make an address out of every address it finds will slow it down.