Hi,
How can I modify bitcrack (CLbitCrack.exe) to search vanity?
https://github.com/Telariust/VanitySearch-bitcrack/releases/tag/1.15.4
You use this program if you want to search for vanity:
https://github.com/JeanLucPons/VanitySearch
Topic: BitCrack - A tool for brute-forcing private keys - page 47. (Read 74618 times)
Hi,
How can I modify bitcrack (CLbitCrack.exe) to search vanity?
https://github.com/Telariust/VanitySearch-bitcrack/releases/tag/1.15.4
You use this program if you want to search for vanity:
https://github.com/JeanLucPons/VanitySearch
Hi,
How can I modify bitcrack (CLbitCrack.exe) to search vanity?
https://github.com/Telariust/VanitySearch-bitcrack/releases/tag/1.15.4
my strategy scan is random slot for scan ( split to small keyspace to search)
because I have very small GPU on laptop and I works use for solve puzzle only free time)
First time I use batch file call BitCrack it work fine
and I try to use C# create small utility make bitcrack lurcher
create launcher work better bath file
but I have problem with use variable private key is very long
I am not programmer I don't understand about byte
now I try python call cubitcrack.exe to work , python very easy
try to use subprocess function, it is work on windows 10
subprocess it work on windows 10
because I have very small GPU on laptop and I works use for solve puzzle only free time)
First time I use batch file call BitCrack it work fine
and I try to use C# create small utility make bitcrack lurcher
create launcher work better bath file
but I have problem with use variable private key is very long
I am not programmer I don't understand about byte
now I try python call cubitcrack.exe to work , python very easy
try to use subprocess function, it is work on windows 10
subprocess it work on windows 10
Code:
import subprocess
import os
#p=subprocess.Popen("notepad",shell=False)
#p=subprocess.Popen("kangaroo in.txt",shell=False)
p=subprocess.Popen("cubitcrack.exe -i in.txt",shell=False)
import os
#p=subprocess.Popen("notepad",shell=False)
#p=subprocess.Popen("kangaroo in.txt",shell=False)
p=subprocess.Popen("cubitcrack.exe -i in.txt",shell=False)
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";
Quote
SP_ LINK IS MISSING to your opensource sql search tool. Cant find in your repositries also.
The annoying part is that the offending region of memory is 32-bit aligned
Vector instructions need 16byte alignment.
In bitcrack sp-mod #5 ~66% of the time is used to multuply numbers. Pretty stupid algorithm. With tensor cores enabled, might push the hashrate abit.
So dynamically allocating all the blasted local variables should solve it then since those are returned on 256-bit boundaries.
The annoying part is that the offending region of memory is 32-bit aligned
Vector instructions need 16byte alignment.
In bitcrack sp-mod #5 ~66% of the time is used to multuply numbers. Pretty stupid algorithm. With tensor cores enabled, might push the hashrate abit.
I discovered that it's actually the Link Time Optimization (-dlto switch) that nvcc is doing to the object code that's the culprit and messing with CUDA API functions, which is also the reason why linking takes so long, and that this feature is turned off while using the debugging switch -G. Unfortunately there is no switch that turns it off, but it shouldn't be too bad because I can successfully reproduce the bug with -b 1 -t 32 -p 1 (the threads absolutely have to be a multiple of 32 or else the program will complain).
Isn't this the same thing as for Legacy Mode execution? Would at least explain why legacy was running (just horribly slow).
Legacy mode is really just no-frills CUDA compilation without fancy optimizations behind your back.
The optimizations are what's killing the program this is why it can only be reproduced in PTX and not in source code. Think about it, even a T4 running Bitcrack compiled with compute 5.2 is crashing. It means that something has changed in the way newer GPUs get their code compiled that makes bad PTX.
The annoying part is that the offending region of memory is 32-bit aligned (so maybe older cards had no problem with that), and there's unsigned int arrays everywhere. Also today's debugging efforts have come to nothing so I think I'll try arming BSGS/Kangaroo/VanitySearch with Bitcrack-like searches instead.
I discovered that it's actually the Link Time Optimization (-dlto switch) that nvcc is doing to the object code that's the culprit and messing with CUDA API functions, which is also the reason why linking takes so long, and that this feature is turned off while using the debugging switch -G. Unfortunately there is no switch that turns it off, but it shouldn't be too bad because I can successfully reproduce the bug with -b 1 -t 32 -p 1 (the threads absolutely have to be a multiple of 32 or else the program will complain).
Isn't this the same thing as for Legacy Mode execution? Would at least explain why legacy was running (just horribly slow).
Didn't know about this one tho:
Quote
With a new code target, lto_70, you can get fine-grained control to indicate which target architecture should store the LTO intermediary instead of SASS or PTX. For example, to store Volta LTO and Ampere PTX, you would compile with the following code example:
nvcc -gencode arch=compute_70,code=lto_70
-gencode arch=compute_80,code=compute_80
nvcc -gencode arch=compute_70,code=lto_70
-gencode arch=compute_80,code=compute_80
Hang on, I'm zoning in on the error. It appears to be returned from a CUDA API function so that's some good news
This issue is also reproducible on RTX 20 cards.
I'm currently busy strapping all the API calls with printf's after the error checks are triggered to see which one it is.
Cool! Hopefully your printfs do not slow it down too much causing it to work. That was our biggest pain in the .........
I've been checking our discord, but there is really nothing you didn't already know/ran into it.
I discovered that it's actually the Link Time Optimization (-dlto switch) that nvcc is doing to the object code that's the culprit and messing with CUDA API functions, which is also the reason why linking takes so long, and that this feature is turned off while using the debugging switch -G. Unfortunately there is no switch that turns it off, but it shouldn't be too bad because I can successfully reproduce the bug with -b 1 -t 32 -p 1 (the threads absolutely have to be a multiple of 32 or else the program will complain).
Hang on, I'm zoning in on the error. It appears to be returned from a CUDA API function so that's some good news
This issue is also reproducible on RTX 20 cards.
I'm currently busy strapping all the API calls with printf's after the error checks are triggered to see which one it is.
Cool! Hopefully your printfs do not slow it down too much causing it to work. That was our biggest pain in the .........
I've been checking our discord, but there is really nothing you didn't already know/ran into it.
Doesn't work. The 30 series problem is code related, not a PTX compile issue.
I will receive my first 30 series card in a week or so. Will fix then.
Awesome, would you mind sharing what the fix if you get it fixed? As we noobs been trying for a while
Would love to know what've been overlooking.Hang on, I'm zoning in on the error. It appears to be returned from a CUDA API function so that's some good news
This issue is also reproducible on RTX 20 cards.
I'm currently busy strapping all the API calls with printf's after the error checks are triggered to see which one it is.
Doesn't work. The 30 series problem is code related, not a PTX compile issue.
I will receive my first 30 series card in a week or so. Will fix then.
Awesome, would you mind sharing what the fix if you get it fixed? As we noobs been trying for a while
Would love to know what've been overlooking. Doesn't work. The 30 series problem is code related, not a PTX compile issue.
I will receive my first 30 series card in a week or so. Will fix then.
All four mods are not working in 30 series GPUs 
waiting for your 5th mod
waiting for your 5th mod Can you try #5? Does it work?
Doesn't work. The 30 series problem is code related, not a PTX compile issue.
All four mods are not working in 30 series GPUs waiting for your 5th mod
waiting for your 5th mod Can you try #5? Does it work?
Code:
C:\Users\Admin\Desktop\Bitcrack-spmod5>cuBitCrack.exe --keyspace 8000000000000000:ffffffffffffffff 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN
Bitcrack sp-mod #5 (https://github.com/sp-hash)
[2021-03-26.15:07:12] [Info] Compression: compressed
[2021-03-26.15:07:12] [Info] Starting at: 0000000000000000000000000000000000000000000000008000000000000000
[2021-03-26.15:07:12] [Info] Ending at: 000000000000000000000000000000000000000000000000FFFFFFFFFFFFFFFF
[2021-03-26.15:07:12] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2021-03-26.15:07:12] [Info] Initializing GeForce RTX 3090
[2021-03-26.15:07:12] [Info] Generating 48,617,472 starting points (1854.6MB)
[2021-03-26.15:07:20] [Info] 10.0%
[2021-03-26.15:07:20] [Info] 20.0%
[2021-03-26.15:07:20] [Info] 30.0%
[2021-03-26.15:07:20] [Info] 40.0%
[2021-03-26.15:07:21] [Info] 50.0%
[2021-03-26.15:07:21] [Info] 60.0%
[2021-03-26.15:07:21] [Info] 70.0%
[2021-03-26.15:07:21] [Info] 80.0%
[2021-03-26.15:07:21] [Info] 90.0%
[2021-03-26.15:07:21] [Info] 100.0%
[2021-03-26.15:07:21] [Info] Done
[2021-03-26.15:07:21] [Info] Error: misaligned address
Execution time = 9 seconds
For me #4 and #5 finished the same search in the exact same amount of time, so no difference on #4 vs #5 on my side 
Try to let the program choose the launchconfig automaticly. And solve a harder puzzle. The program is optimized to solve 2^64 - 2^160 keys
Yup, with no arguments for -b -t -d #5 found the same above key 12 secs faster. While #4 gave me memory error...so #5 is improved
I'll try with an A100 as well soon and post the results. https://i.imgur.com/APBj1tU.png
All four mods are not working in 30 series GPUs waiting for your 5th mod
waiting for your 5th mod Can you try #5? Does it work?
For me #4 and #5 finished the same search in the exact same amount of time, so no difference on #4 vs #5 on my side
Try to let the program choose the launchconfig automaticly. And solve a harder puzzle. The program is optimized to solve 2^64 - 2^160 keys
For me #4 and #5 finished the same search in the exact same amount of time, so no difference on #4 vs #5 on my side
https://i.imgur.com/y0rKeXB.png
https://i.imgur.com/u30nrLk.png
https://i.imgur.com/y0rKeXB.png
https://i.imgur.com/u30nrLk.png
also during compile on VS 2017 i am getting there warnings
4>The system cannot find the file specified.
4>Error occurred while processing: ripemd160.cl.
4>The system cannot find the file specified.
4>Error occurred while processing: secp256k1.cl.
4>The system cannot find the file specified.
4>Error occurred while processing: sha256.cl.
4>
4>The system cannot find the file specified.
4>Error occurred while processing: ripemd160.cl.
4>The system cannot find the file specified.
4>Error occurred while processing: secp256k1.cl.
4>The system cannot find the file specified.
4>Error occurred while processing: sha256.cl.
4>
I have a feeling that OpenCL doesn't like the uint64_t type and wants you to use unsigned long long (?) instead. Neither does CUDA.
I guess check if the above files are missing from the filesystem too?
You're compiling from the dev branch right? It's not exactly stable, so I wouldn't be surprised if it's riddled with compiler errors too.
Jump to: