trying BSGS on addresses above 80 bits

Hey everyone, I’ve got a wild idea. I want to go for BSGS on those old 50 BTC addresses (pubkeys) covering the entire 2^256 range. There’s like over 34k of them out there. Is there any software right now that can handle this? I’m talking about a program that works with more than 80 bits and goes all the way up to 256.

Visit this thread BSGS solver for cuda by Etar (It has all you are looking for if you take your time to read through) I think he also wrote the fraction on GitHub - https://github.com/Etayson/fraction-bsgs.git

Great! Thanks! However I have problems running these two programs. I've got PureBasic full-version but after fixing one code error the programs just start and immediately stop without any info. Strange.

Try running the program in a terminal or command prompt so you can see any error messages before the window closes If programs you're trying to run in PureBasic start and then stop right away without any error or output, it's probably because essential input was missing, the configuration was incorrect, or an unhandled exception occurred make sure you're providing all necessary parameters (such as target pubkeys or key ranges) in the command line or input files examine the code's logic, paying particular attention to initialisation and file handling, and try adding debug prints or logging to see where it goes wrong

Yes, I've runned the compiled .exe with arguments and without. No error messages or anything in both cases. It just does nothing. Cannot do anything about it, tried many times.

To track runtime events, use a debugger such as x64dbg. A silent crash or an inability to load a GPU kernel could be detected   U can also Test with Minimal Command  And if  this doesn’t even write the file or show progress, something is wrong at the binary level or with GPU compatibility

It is not bitcrack. These are PureBasic programs compiled with original program for that, with GUI. No errors at compile time and no messages when running these .exe files with or without params.

Hello, While attempting to crack 256-bit private keys for Bitcoin addresses using the Baby-step Giant-step (BSGS) algorithm might sound like an exciting endeavor, it's crucial to understand the practical limitations and the current state of technology. Practicality of BSGS for 256-bit Keys Computational Infeasibility: The keyspace for Bitcoin private keys is 2 256  . The BSGS algorithm has a time and space complexity of approximately   N ​  , where N is the order of the group. In the case of ECDSA over the secp256k1 curve used by Bitcoin, N is roughly 2 256  . Therefore, a full BSGS attack would require approximately 2 128   operations and storage, which is computationally infeasible with current and foreseeable technology. To put this into perspective, 2 80   operations are considered at the very edge of what might be achievable with immense resources and time. 2 128   is astronomically larger. Bitcoin Key Space: Bitcoin addresses are derived from public keys, which in turn are derived from private keys. The private keys are 256-bit numbers. Trying to find a private key corresponding to a given public key (or address) is an instance of the Elliptic Curve Discrete Logarithm Problem (ECDLP). BSGS is one algorithm for solving this, but its square root complexity makes it impractical for the scale of Bitcoin's key space. Software for Large Keyspaces Current Limitations: As of my last update in May 2025, there isn't any publicly known software capable of performing a full BSGS attack on key sizes anywhere close to 256 bits. The memory and computational resources required are simply too vast. Research Focus: Research in cryptanalysis does explore algorithms for solving the ECDLP, and there are variations and optimizations of BSGS. However, these are generally theoretical or applicable to much smaller key sizes than 256 bits. Specialized Hardware: While specialized hardware can accelerate cryptographic computations, even custom-designed ASICs would likely be unable to overcome the fundamental limitations posed by the   2 256   ​  =2 128   complexity of BSGS. Alternative Attack Vectors It's worth noting that instead of trying to brute-force the entire 256-bit keyspace, attackers often look for vulnerabilities in: Random Number Generation: If the private key generation process was flawed and didn't produce truly random numbers, the effective keyspace might be much smaller and potentially exploitable. However, Bitcoin's secp256k1 curve and standard practices aim to avoid such weaknesses. Wallet Software: Vulnerabilities in wallet software could expose private keys through exploits, malware, or phishing attacks. These are often more practical attack vectors than trying to break the underlying cryptography. Side-Channel Attacks: These attacks exploit physical characteristics of the devices performing cryptographic operations (e.g., power consumption, electromagnetic emissions) to try and extract secret information.

You didn't understood the question and you are writing spam here.

Hello I run Collider BSGS. The program is super optimized, without errors. I managed to adapt the program for RX5090 cards and I obtained scanning speeds of 60-64 Exakey/sec (when scanning a single address). In tests, the program does not miss any address at this speed. I am interested in collaborating with people who achieve higher speeds. I bought the PureBasic program. I was unable to make this program functional in random mode, the program scans correctly, sees the addresses (Pub key...) but does not notify me of the results. The test is done on valid addresses.

I like your experiment. But BSGS hardly works on 256 range. I'm currently working on a hybrid, I'm combining BSGS with pollard kangaroo. I'm hoping it could be a many times faster than kangaroo.

Hello I don't understand you. Collider bsgs cuda adapted by me for RTX5090, scans in any space you give it and the speed is the same ~64 Exa key/ sec Here are examples below: C:\Users\NN\Desktop\COLLIDER>bsgscudaHT_1_9_7file -t 256 -b 256 -p 914 -w 32 -htsz 31 -pk 6cf4feb12b75e8e00fffffffffffffffff -pke 6cf4feb12b75e8eFFFFFFFFFFFFFFFFFFF -infile Puzle135 Number of GPU threads set to #256 Number of GPU blocks set to #256 Number of pparam set to #914 Items number set to 2^32=4294967296 HT size set to 2^31 Range begin: 0x6cf4feb12b75e8e00fffffffffffffffff Range end: 0x6cf4feb12b75e8efffffffffffffffffff Will be used file: Puzle135 Found 1 Cuda device. Cuda device:NVIDIA GeForce RTX 5090 (30840.000/32606MB) Current config hash[] GiantSUBvalue:0000000000000000000000000000000000000000000000000000000200000000 GiantSUBpubkey: 038c0989f2ceb5c771a8415dff2b4c4199d8d9c8f9237d08084b05284f1e4df706 ******************************* Total GPU Memory Need: 30060.000MB ******************************* Both HT files exist Load BIN file:256_256_914_4294967296_g2.BIN chunk:1073741824b[1] chunk:1073741824b [2] chunk:1073741824b Last chunk:612368384b [3] chunk:612368384b Done in 00:00:00s Gstep: e48000000000000 GPU count #1 GPU #0 launched GPU #0 Free/Total/Need memory: 30838/32606/30060.002MB _A size:120 GPU #0 copied giant array Remove Giant array, freed memory: 3656.000 MB Load BIN file:79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_4294967296_214 7483648_htGPUv0.BIN chunk:1073741824b[1] chunk:1073741824b [2] chunk:1073741824b ....................................... [23] chunk:1073741824b Last chunk:4b [24] chunk:4b Done in 00:00:03s GPU #0 copied hash table Remove HT for GPU, freed memory: 24576.000 MB Random verify packed HTCPU items in file...ok START RANGE= 0000000000000000000000000000006cf4feb12b75e8e00fffffffffffffffff   END RANGE= 0000000000000000000000000000006cf4feb12b75e8efffffffffffffffffff WIDTH RANGE= 000000000000000000000000000000000000000000000ff00000000000000000 = 2^76 SUBpoint= (afaacd852045a0e036d93ee350283936b312b379f0f1e04bf35565897ecaa282, 8a334cf89c64444f69049c40d563f435209697a9a7b92b38bd59a02b44db2556) Save work every 180 seconds Checker thread started Findpubkey  : 02145d2611c823a396ef6712ce0f712f09b9b4f3135e3e0aa3230fb9b6d08d1e16 Searchpubkey: 03235dada82c3477f7b249b6c7660b84b664d490465f98afd5efcc2b8c5c074c97 Cnt:fea5718000000000001 [1][ 7161 ] = 7161 MKeys/s x2^33.0=2^65.81 Jt:00:19:27 Reached end of space GPU#0 job finished GPU#0 thread finished cuda finished ok Press Enter to exit Speed ​​calculation: Total RANGE =  ff00000000000000000 (hex) => 75262715820734970593280 (decimal) Working time = 00:19:27 = 1167 sec Average working speed = 75262715820734970593280 : 1167 = 64,492,472,854,100,231,870 => ~ 64.49 Exa key/sec ORI ... GPU #0 copied hash table Remove HT for GPU, freed memory: 24576.000 MB Random verify packed HTCPU items in file...ok START RANGE= 0000000000000000000000000000006cf4feb12b75e8e00fffffffffffffffff   END RANGE= 8c37ab83ae6429b684e4fe6cf1d9dab9cf421366e80f7ba90000000000000000 WIDTH RANGE= 8c37ab83ae6429b684e4fe6cf1d9da4cda43623b72269b990000000000000001 = 2^256 SUBpoint= (afaacd852045a0e036d93ee350283936b312b379f0f1e04bf35565897ecaa282, 8a334cf89c64444f69049c40d563f435209697a9a7b92b38bd59a02b44db2556) Save work every 180 seconds Checker thread started Findpubkey  : 02145d2611c823a396ef6712ce0f712f09b9b4f3135e3e0aa3230fb9b6d08d1e16 Searchpubkey: 03235dada82c3477f7b249b6c7660b84b664d490465f98afd5efcc2b8c5c074c97 Cnt:ef0b28000000000001 [1][ 7147 ] = 7147 MKeys/s x2^33.0=2^65.80 Jt:00:01:09  STOP

You need to understand how the BSGS algorithm works. In your example, you create a 2^33 key database and search through them. BSGS is more memory-intensive than the number of device threads. I made a program (keyhuntBSGS GPU) faster than bsgscudaHT for GPUs, but I haven't made it open-source yet. The CPU version is https://github.com/Slait/Keyhuntbsgs It's still faster than GPUs due to proper optimization. On a CPU, I achieved a speed of 44 ekeys/s. If you increase the memory, you can increase it to 120 ekeys/s. But this is still not enough.

SlaitX You say that BSGS consumes a lot of memory. Can you explain please, what kind of memory are you referring to? To RAM memory or video memory? What processor did you use, how many cores, and what RAM did you allocate to get 44 Exa key/sec. Please..

CPU 180gb ram, 192 processor threads

There’s no software that’ll take 50 pubkeys and brute-force private keys anywhere close to the full 2²⁵⁶ keyspace. That range is literally astronomically huge. There’s no program that will do that and trying to brute-force Bitcoin private keys is basically impossible with current tech ano 2026.

Whole 2^256 space no, but with pubkeys and BSGS/Kangaroo it should be sanely possible.

Hello Sorry but you missed something, keyhuntBSGS generates HTable at each launch, which takes a long time. The duration depends on the power of the system and the size of the space to be scanned (it can take between 1/2 - 4 hours). ColliderBSGS generates its HTable only once. For video memory of 32Gb and above, it takes 2 - 4 hours even longer for cards with 48 - 96 GB and ++. After you have generated HT, loading the program will take a few seconds. You have a speed of 100++ Eza key/sec in vain if launching (loading) the program takes X hours. For a correct calculation, divide the scanned space by the total time since you started the program (not the speed displayed by the program). ColliderBSGS does not depend on RAM during scanning. Many people are wrong when they say that ColliderBSGS needs as much RAM as the planet Terra to scan intervals of 80 - 200 bits. It will be a long time before people give up their pride and study ColliderBSGS more carefully in Windows. In ColliderBSGS, it is not the size of the space to be scanned that matters, but the time it takes to scan. Of course, if you live as long as the universe, you can scan 200 bits ++ .....