Hello everybody. I have a problem with launching the program.
I downloaded the latest version https://github.com/brichard19/BitCrack/releases
Installed CUDA Toolkit 12.0 Update 1
also installed Visual Studio 2015, 2017, 2019, 2022
PC characteristics
Windows OS11
AMD Ryzen 9 7950X 16-Core Processor 4.50 GHz
64 Gb RAM
GeForce RTX 4090 - NVIDIA
Startup error: cudart64_101.dll not found windows
Topic: BitCrack - A tool for brute-forcing private keys - page 8. (Read 76850 times)
Yes, that is an older version of VBC. However, I did not use it when testing address limits.
I have another VS version that will take binary to bloom.
Keyhunt, by albert, will also accept 200M keys, but it is CPU only but random function is great. You can also do sequential.
I have another VS version that will take binary to bloom.
Keyhunt, by albert, will also accept 200M keys, but it is CPU only but random function is great. You can also do sequential.
Great, thanks a lot!
I have been testing on my own modified versions of VS and KeyHunt.
Yeah, Bitcrack just froze with 10mil addresses loaded...
Is this your version?
https://github.com/WanderingPhilosopher/VanBitCrakcenS
I have another VS version that will take binary to bloom.
Keyhunt, by albert, will also accept 200M keys, but it is CPU only but random function is great. You can also do sequential.
I have been testing on my own modified versions of VS and KeyHunt.
Yeah, Bitcrack just froze with 10mil addresses loaded...
Is this your version?
https://github.com/WanderingPhilosopher/VanBitCrakcenS
It eats up 4300MB, 4.3GB of RAM. Binary to Bloom; I am sure if it was loaded via text file, it would eat up a lot more. Also, I doubt this will work with Bitcrack or any VanitySearch forks.
Why wouldn't it work? Because those are set to use .txt files instead? What would you recommend using instead of Bitcrack &co?
I have been testing on my own modified versions of VS and KeyHunt.
It eats up 4300MB, 4.3GB of RAM. Binary to Bloom; I am sure if it was loaded via text file, it would eat up a lot more. Also, I doubt this will work with Bitcrack or any VanitySearch forks.
Why wouldn't it work? Because those are set to use .txt files instead? What would you recommend using instead of Bitcrack &co?
How does the GPU memory play a part?
If you want to load 1 billion addresses and work on them at the same time (in parallel), there isn't enough device memory to for everything on current GPUs according to my above calculations. So you'd have to break it into parts and place more copy calls which will affect performance.
Every time NVIDIA increases GPU memory this brings two kinds of speed benefits - one is you can process more stuff on the GPU at the same time, and it will be faster (as CUDA cores usually become faster at the same time) and the other is that as a direct consequence, there's less latency delay from excessive CopyHostToDevice calls and vice versa.
200 Million addresses loaded and working with CPU; GPU untested
It eats up 4300MB, 4.3GB of RAM. Binary to Bloom; I am sure if it was loaded via text file, it would eat up a lot more. Also, I doubt this will work with Bitcrack or any VanitySearch forks.
It eats up 4300MB, 4.3GB of RAM. Binary to Bloom; I am sure if it was loaded via text file, it would eat up a lot more. Also, I doubt this will work with Bitcrack or any VanitySearch forks.
Very impressive stats you found but I highly doubt you will get any higher than this if you test on GPU, this is because of its architecture where it's memory is separated from all the rest of the system RAM.
So you could have a 96GB system (eg. A very very recent MacBook Pro with an external nvidia GPU (does that even exist??) but the GPU will only have only 8 or 16 gigs total which puts a ceiling on the number of addresses. That's kinda sad as these suckers can easily do 500x the search performance of a single CPU socket.
200 Million addresses loaded and working with CPU; GPU untested
It eats up 4300MB, 4.3GB of RAM. Binary to Bloom; I am sure if it was loaded via text file, it would eat up a lot more. Also, I doubt this will work with Bitcrack or any VanitySearch forks.
It eats up 4300MB, 4.3GB of RAM. Binary to Bloom; I am sure if it was loaded via text file, it would eat up a lot more. Also, I doubt this will work with Bitcrack or any VanitySearch forks.
Very impressive stats you found but I highly doubt you will get any higher than this if you test on GPU, this is because of its architecture where it's memory is separated from all the rest of the system RAM.
So you could have a 96GB system (eg. A very very recent MacBook Pro with an external nvidia GPU (does that even exist??) but the GPU will only have only 8 or 16 gigs total which puts a ceiling on the number of addresses. That's kinda sad as these suckers can easily do 500x the search performance of a single CPU socket.
Bitcoin addresses are about 52 characters long so if you're dealing with 1 billion of them you are looking at 53-54 GB text file (including the new line, and if you're using Windows there's also a carriage return before the new line). As long as you are not opening that thing using Notepad and you got 64GB of RAM to spare, then you should not have any problems with memory.
Thanks, will give it a try in a few days.
Code:
Loading : 100 %
Loaded : 100,000,001 Bitcoin addresses
Loaded : 100,000,001 Bitcoin addresses
Edit: It would work and run with CPU only, but not with GPU...
Edit 2: It works with 100 million addresses on CPU and GPU...
Edit 3:
Code:
Loading : 100 %
Loaded : 200,000,001 Bitcoin addresses
200 Million addresses loaded and working with CPU; Tested on GPU, loads and runs with 200 million addresses.Loaded : 200,000,001 Bitcoin addresses
It eats up 4300MB, 4.3GB of RAM. Binary to Bloom; I am sure if it was loaded via text file, it would eat up a lot more. Also, I doubt this will work with Bitcrack or any VanitySearch forks.
Bitcoin addresses are about 52 characters long so if you're dealing with 1 billion of them you are looking at 53-54 GB text file (including the new line, and if you're using Windows there's also a carriage return before the new line). As long as you are not opening that thing using Notepad and you got 64GB of RAM to spare, then you should not have any problems with memory.
Thanks, will give it a try in a few days.
I want to test maybe 10-15x more close to 1B addresses. Machine specs 50TB SSDs, 128 RAM. How should I proceed, just generate a large .txt file and see if it works? I doubt .txt files can handle that much data...
yes, small key sizes as in 20^35 - 2^40 keysize. How much of an impact has the size of the key? As in the smaller the key, the larger the amount of xpoints or addresses the tool can work with? Or even if the key is really small like 123*G it's still going to search forever within a large dataset of addresses...
yes, small key sizes as in 20^35 - 2^40 keysize. How much of an impact has the size of the key? As in the smaller the key, the larger the amount of xpoints or addresses the tool can work with? Or even if the key is really small like 123*G it's still going to search forever within a large dataset of addresses...
Bitcoin addresses are about 52 characters long so if you're dealing with 1 billion of them you are looking at 53-54 GB text file (including the new line, and if you're using Windows there's also a carriage return before the new line). As long as you are not opening that thing using Notepad and you got 64GB of RAM to spare, then you should not have any problems with memory.
You would have to give me concrete examples.
work with = I've tested with 60 million xpoints, so I know it can do that many, how many are you wanting to run/test?
small key sizes = what do you mean? search in a 40 bit range, 48 bit range, etc. are you talking about ranges or small key sizes as in, private key sizes?
addresses/xpoints=addresses would be converted to hash160 which would be smaller than xpoints, so I would imagine, ran on the same systems, with same amount of RAM, you could run more addresses/hash160s versus xpoints.
I want to test maybe 10-15x more close to 1B addresses. Machine specs 50TB SSDs, 128 RAM. How should I proceed, just generate a large .txt file and see if it works? I doubt .txt files can handle that much data...
yes, small key sizes as in 20^35 - 2^40 keysize. How much of an impact has the size of the key? As in the smaller the key, the larger the amount of xpoints or addresses the tool can work with? Or even if the key is really small like 123*G it's still going to search forever within a large dataset of addresses...
Understood...I posted a quite unrealistic scenario. Let's dial it down back to earth and try again.
1. How many x points could bitCrack / keyHunt, etc work with, saved in a dataset, to find small size keys within a reasonable amount of time (less than 24 hours). We can assume that the application is running on a high-end computer with a large amount of RAM and disk space. Does anyone have any experience with this? Would you be able to provide the results and the specifications of the machine used?
2. Same question for using addresses instead of points.
Thank you!!
1. How many x points could bitCrack / keyHunt, etc work with, saved in a dataset, to find small size keys within a reasonable amount of time (less than 24 hours). We can assume that the application is running on a high-end computer with a large amount of RAM and disk space. Does anyone have any experience with this? Would you be able to provide the results and the specifications of the machine used?
2. Same question for using addresses instead of points.
Thank you!!
You would have to give me concrete examples.
work with = I've tested with 60 million xpoints, so I know it can do that many, how many are you wanting to run/test?
small key sizes = what do you mean? search in a 40 bit range, 48 bit range, etc. are you talking about ranges or small key sizes as in, private key sizes?
addresses/xpoints=addresses would be converted to hash160 which would be smaller than xpoints, so I would imagine, ran on the same systems, with same amount of RAM, you could run more addresses/hash160s versus xpoints.
Understood...I posted a quite unrealistic scenario. Let's dial it down back to earth and try again.
1. How many x points could bitCrack / keyHunt, etc work with, saved in a dataset, to find small size keys within a reasonable amount of time (less than 24 hours). We can assume that the application is running on a high-end computer with a large amount of RAM and disk space. Does anyone have any experience with this? Would you be able to provide the results and the specifications of the machine used?
2. Same question for using addresses instead of points.
Thank you!!
1. How many x points could bitCrack / keyHunt, etc work with, saved in a dataset, to find small size keys within a reasonable amount of time (less than 24 hours). We can assume that the application is running on a high-end computer with a large amount of RAM and disk space. Does anyone have any experience with this? Would you be able to provide the results and the specifications of the machine used?
2. Same question for using addresses instead of points.
Thank you!!
But for the example above: 2^69 / 55,246,870 = 10,684,692,370,060; now take that and multiply by 1.72GB = 18,377,670,876,503GB, double all numbers for 2^70. That's a lot of GBs 
Right, it's 18 ZB, roughly the same as 24 ZB (using 20 bytes per address, i.e. just HASH160, no prefix, checksum or private key).In other words, about twice as much as all the world's storage capacity (HDD, flash, tape, optical) in 2023, and would cost something like $1000 billion1.
1 Using data from IDC and their "Worldwide Global StorageSphere" metric (not to be confused with the "DataSphere", which is the amount created and some 10x bigger).
It is a random dataset of around 2^70 addresses
Wait until April 1, then by all meansjust add them line by line in a .txt file
Edit:
Because of
The files are not yet created due to the lack of knowledge on how to create a dataset that would work with tools such as bitCrack, etc...
...is this even possible?
I just realised that maybe you're actually serious, in which case I'm sorry to predict that the answer is no, most likely for several years....is this even possible?
You'll not even be able to "create the files":
- Even if you somehow could create and store addresses as fast as the combined mining community can try hashes 2023 you'd have to wait 10000+ years.
- Then there's the matter of storage. Luckily, Seagate expects to start selling 50TB hard drives in 2026, but you'd still need around 500 million of them.
For Robert_BIT
But to help further the example and to give you concrete evidence:
Code:
Loading : 100 %
Loaded : 55,246,870 Bitcoin xpoints
Now, the other thing to consider if one is creating addresses, you will have to save, at the minimum, the private key and the address, or else one would not know how to map back to the address. You can create a starting point and do sequential keys which then you would only need to keep your starting point (private key).
But for the example above: 2^69 / 55,246,870 = 10,684,692,370,060; now take that and multiply by 1.72GB = 18,377,670,876,503GB, double all numbers for 2^70. That's a lot of GBs
You could probably trim some data and add in a hash table, maybe save some GB needed, but then you would need to create or mod an existing program to search via a hashtable. Doing that is doable, but then you would have to chunk the addresses in order to search for them. No way you could store 2^69 addresses in memory or hash table, and search for them. The 55,246,870 eats up around 1200MB of RAM in my program.
It is a random dataset of around 2^70 addresses
Wait until April 1, then by all meansjust add them line by line in a .txt file
Edit:
Because of
The files are not yet created due to the lack of knowledge on how to create a dataset that would work with tools such as bitCrack, etc...
...is this even possible?
I just realised that maybe you're actually serious, in which case I'm sorry to predict that the answer is no, most likely for several years....is this even possible?
You'll not even be able to "create the files":
- Even if you somehow could create and store addresses as fast as the combined mining community can try hashes 2023 you'd have to wait 10000+ years.
- Then there's the matter of storage. Luckily, Seagate expects to start selling 50TB hard drives in 2026, but you'd still need around 500 million of them.
Does anyone know how to best search for multiple addresses at once?
As is often the case, the problem as stated is massively underspecified. -----I know, sorry...-----For instance:
- Are your target addresses are correlated, perhaps even strictly sequential (in which case the solution is trivial)? -----no link between the addresses -----
- How large is the dataset; -----2^69 - 2^70 addresses----- is it feasible to transfer it to several kernels for parallellisation? -----no idea, perhaps.-----
- Is the dataset mutable, or is it feasible to perform an initial, heavy transformation (in which case perfect hashing might outperform probabilistic/Bloom)? -----It is a random dataset of around 2^70 addresses specifically created so that only a few of them have small keys in range 2^40-2^41. The files are not yet created due to the lack of knowledge on how to create a dataset that would work with tools such as bitCrack, etc...But essentially the task at hand will be to find those small range keys while searching the huge dataset mentioned... -----
Et cetera. A general database engine is almost certainly not optimal in either case.----- rather than optimal my question hints at ...is this even possible? -----
Does anyone know how to best search for multiple addresses at once?
As is often the case, the problem as stated is massively underspecified.For instance:
- Are your target addresses correlated, perhaps even strictly sequential (in which case the solution is trivial)?
- How large is the dataset; is it feasible to transfer it to several kernels for parallellisation?
- Is the dataset mutable, or is it feasible to perform an initial, heavy transformation (in which case perfect hashing might outperform probabilistic/Bloom)?
Et cetera. A general database engine is almost certainly not optimal in either case.
Jump to: