Search content
Sort by
Showing 20 of 33 results by Robert_BIT
I'd throw in "Quantum computers" into the discussion but considering that commercial versions are 20+ years away from reality, it's more likely that people will be alerted by some Google Project Zero researcher who finds and discloses a flaw in ECDSA, than by any brute forcing a bunch of crackers are doing 
However, we'd make a good benchmark on how practical the exploits are for random people to pull off.
However, we'd make a good benchmark on how practical the exploits are for random people to pull off.
Yes, I was thinking about QCs as well. In fact, it is quite likely that some undisclosed powerful machine managed to find the #120 after searching for smaller ranges on the blockchain. Quite possibly without being aware of this forum.
I would say that a science lab team would not actually send the BTC - they normally follow good ethical standards.
I see it exactly the opposite way. There are numerous reasons why the true and happy finder would never want to disclose this information here in the forum, if this person is active here in the forum at all. I even claim that there are more logical reasons to hide it than to hang it on the big bell and supposedly brag about it.
This assumption can also be reflected analogously to a block find where a solo miner collects the reward but wants to remain anonymous. There are dozens of reasons for that.
This assumption can also be reflected analogously to a block find where a solo miner collects the reward but wants to remain anonymous. There are dozens of reasons for that.
I tend to agree. For quite some time I've been coming here every now and then to check on any progress and play around with Kangaroos and BitCracks
In the event that I could come up with a solution, I would prefer to keep a low profile. For a while, at least as I devote my attention to resolving the next problem in line - in this case, #125.
But more importantly than 'who did it?', let's not forget, are the fundamentals of this challenge (incorrectly referred to as a puzzle).
These principles should be the basis for all of our efforts, and for all of our discussions here. As stated in the creator's post: "It is simply a crude measuring instrument, of the cracking strength of the community. "
The reference to "community" was interesting in that it could be interpreted as an invitation for more minds to collaborate in order to solve whatever can be solved. This is also hinted at in this line:
"Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology."
We could argue that this "community" spirit hinted at by the creator has faded. Not disappeared, but faded.
Almost everyone seems to be in it for their own benefit. This includes the undersigned...
Moreover, the recent resolution of #120 without sharing the good news only heightens a feeling of individualism instead of a sense of community.
Sorry if I offended anyone. This post is intended solely as a reminder of the importance of returning to the basics. For all of us to remember, why was this challenge even started in the first place?
I personally do not believe it was intended to test the overall strength of the blockchain or bitcoin encryption. There are scientists who use very powerful hardware in very advanced laboratories who have been testing encryption challenges for years. And they do not usually visit forums in order to share their findings, primarily due to security concerns.
Just my two cents...
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
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?
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.
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!!
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? -----
Hello,
Does anyone know how to best search for multiple addresses at once? Do we just add them line by line in a .txt file? What if we want to search for a large number of addresses, can we use a database / bloom of some sorts?
I am not sure of the limitations of searching a large number of addresses at once...I guess even for a small range like 2^40 it will make the search harder as you use more addresses. But haven't found any data on this on GitHub...
Does anyone know how to best search for multiple addresses at once? Do we just add them line by line in a .txt file? What if we want to search for a large number of addresses, can we use a database / bloom of some sorts?
I am not sure of the limitations of searching a large number of addresses at once...I guess even for a small range like 2^40 it will make the search harder as you use more addresses. But haven't found any data on this on GitHub...
GeForce RTX 3060 Laptop GPU
cuBitCrack.exe
-b 82 -t 256 -p 2096
704.18 MKey/s [00:00:25]
cuBitCrack.exe
-b 82 -t 256 -p 2096
704.18 MKey/s [00:00:25]
Do you mean build-in card or eGPU?
I have eGPU RTX 3060 and with these settings I have 800Mkey in peak, stable 780-790:
https://i.ibb.co/ZmtPwgd/image-2022-04-26-200921906.png
I use https://github.com/PawelGorny/BitCrack-3000 (forked from NotATether)
Hi, is this version any better than the original one for newer cards?
https://github.com/PawelGorny/BitCrack-3000 (forked from NotATether)
Sadly I can't compile this on my windows machine...can anyone share a guide for compiling or the latest .exe release? Thanks
Quote
I'm not going to pretend I know about endomorphisms (besides them being results from projection functions on the and can generate equivalent results), but before any work related to that can be started we have to fully understand how secp256k1 benefits from using them.
I found a copy of the Effective Cryptography book hosted here: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.394.3037&rep=rep1&type=pdf
So... I'm going to study that and try to see what secp256k1 does with endomorphisms.
I also set up my VScode workspace with Github integration the other day so I'm really excited about actually overhauling the codebase
Professor Lubin noted this here:
https://math.stackexchange.com/questions/3697090/endomorphism-rings-of-elliptic-curves-over-finite-fields
Perhaps this will be of some help to understand more about endomorphism, rings and EC. His example uses a diff formula than what's used by secp256k1 but for me it was helpful.
I forked now BitCrack and improved it a little.
https://github.com/Uzlopak/BitCrackOpenCL/
In this Fork I concentrate on the OpenCL implementation. So no CUDA-stuff.
I already could improve the performance about 30 %. I assume I can get it better, when I start vectorizing the operations.
Already wrote on stackoverflow for help to get atleast the multiply256 function improved:
https://stackoverflow.com/questions/67667314/transform-native-c-matrix-multiplication-to-opencl-simd-matrix-multiplication
Already posted in various chats and on fiverr with a bounty of 25 € to get it done by somebody else... Probably will ending solving it by myself. Some dude on fiverr was first promising to implement it, but I guess it was more like a dud.
I assume a performance improvement of 200-300% when this function is using SIMD-Operation.
https://github.com/Uzlopak/BitCrackOpenCL/
In this Fork I concentrate on the OpenCL implementation. So no CUDA-stuff.
I already could improve the performance about 30 %. I assume I can get it better, when I start vectorizing the operations.
Already wrote on stackoverflow for help to get atleast the multiply256 function improved:
https://stackoverflow.com/questions/67667314/transform-native-c-matrix-multiplication-to-opencl-simd-matrix-multiplication
Already posted in various chats and on fiverr with a bounty of 25 € to get it done by somebody else... Probably will ending solving it by myself. Some dude on fiverr was first promising to implement it, but I guess it was more like a dud.
I assume a performance improvement of 200-300% when this function is using SIMD-Operation.
When you have time could you compile an .exe release please? Would like to test it vs. the original. Thanks.
Well it seems that each A100 is about 2.5 - 3 times faster than V100 so I won't even try for now. I have to ask my professor and it's going to be a pain accessing it anyway.
But it's interesting how computing power is basically the only thing required. I guess is just a matter of time until someone with access to a supercomputer might give it a try...
But it's interesting how computing power is basically the only thing required. I guess is just a matter of time until someone with access to a supercomputer might give it a try...
...and then get arrested like this guy? https://www.itnews.com.au/news/csiro-it-contractor-spared-jail-for-mining-monero-on-supercomputer-553535
On a more serious note, the software will have to improve to a level where it's not experimental before people start investing their resources into it.
Agree 100%. All sorts of people are resorting to crime, using resources without authorization, simply for profit. The reality is that it may very well work for a while but chances are statistically high that they will get a visit from the authorities. Anything related to crypto is by design built to leave 'some' traces. It's not a good business to steal computing power - whether that's for mining, things like this puzzle or anything related to crypto, really. They're just too many variables involved in terms of security and I'm not really sure who's dumb enough to think they will get away with it.
Well it seems that each A100 is about 2.5 - 3 times faster than V100 so I won't even try for now. I have to ask my professor and it's going to be a pain accessing it anyway.
But it's interesting how computing power is basically the only thing required. I guess is just a matter of time until someone with access to a supercomputer might give it a try...
But it's interesting how computing power is basically the only thing required. I guess is just a matter of time until someone with access to a supercomputer might give it a try...
Several years? Wow.
On GitHub here https://github.com/JeanLucPons/Kangaroo it says 2 months with 256 V100's. Must be wrong then - someone ought to correct that.
On GitHub here https://github.com/JeanLucPons/Kangaroo it says 2 months with 256 V100's. Must be wrong then - someone ought to correct that.
I am not too sure how to calculate this, if someone can help me.
We have at the Uni one NVIDIA DGX A100
It packs 5 petaFLOPS, eight A100 GPUs with 320GB of GPU memory.
Realistically, if we get permission to run it 24/7 (which I doubt lol) for the 120 key, how long would it take? Is it feasible? And more important, would the Kangaroo even work on it?
We have at the Uni one NVIDIA DGX A100
It packs 5 petaFLOPS, eight A100 GPUs with 320GB of GPU memory.
Realistically, if we get permission to run it 24/7 (which I doubt lol) for the 120 key, how long would it take? Is it feasible? And more important, would the Kangaroo even work on it?
The .exe from a.a works fine on a modest GPU, haven't tested yet on higher specs. Thanks again for compiling!
One question:
Any particular reason why the CPU usage jumps and stays to 100% as it runs further and further? This happens with Jean Luc's version too. The temp is normal btw. Maybe is just my machine but I was curious if it's something in the code that makes use of the CPU as well as GPU.
One question:
Any particular reason why the CPU usage jumps and stays to 100% as it runs further and further? This happens with Jean Luc's version too. The temp is normal btw. Maybe is just my machine but I was curious if it's something in the code that makes use of the CPU as well as GPU.
There are various compile versions.
Cuda 10
CUDA 10.2
CUDA 8
and CUDA 10.2 has targets for x32, x64 and x64 for SM 30 (which is actually targetting SM61)
So I will compile once for x64 with CUDA 10.2
EDIT:
here
https://github.com/ZenulAbidin/Kangaroo-256/issues/6
Cuda 10
CUDA 10.2
CUDA 8
and CUDA 10.2 has targets for x32, x64 and x64 for SM 30 (which is actually targetting SM61)
So I will compile once for x64 with CUDA 10.2
EDIT:
here
https://github.com/ZenulAbidin/Kangaroo-256/issues/6
Thank you! I will test it on a V100 and let you know of any issues.
Which project do you actually need to be compiled? I could compile all variations, but would like to just compile the specific one you want...
Yup, the latest code here if you could compile would be great.
https://github.com/ZenulAbidin/Kangaroo-256