Topic: BitCrack - A tool for brute-forcing private keys - page 20. (Read 76850 times)

You misunderstand, We are here talk about bitcoin puzzle address which have rules and hints.

The new address create by new wallet is 90% in range 250-bit to 256-bit which is impossible to crack it even for big bitcoin pool.

All you see in this forum is just "hypothesis" to try to recover lost bitcoin(2.5-4.5 Million lost bitcoin).
For bitcoin puzzle addresses, people found one or two in the year. For lost coins, no one did find it yet. but we are all work on it.
You can think it as hobby like play chess but in reality is playing THE hopelessness game.

The sign of bitcoin is no longer safe is when you see suddenly 2-4 million bitcoin move to new address that a red flag.

Is Bitcoin no longer safe? Have you hacked other addresses as well?

Download https://code.visualstudio.com/
open it, and then create new file addresses_to_hash160.py and copy its content from here https://github.com/secp8x32/KeyHunt-Cuda/blob/main/addresses_to_hash160.py ( OR you can download the file and copy it to your folder)

then create new file called it 64puzzle.txt and save the address "16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN"(the address not the rmd160)

lastly, type on terminal at the bottom "python addresses_to_hash160.py 64puzzle.txt 64puzzle.bin"(python OR python3 it depend on your system)
And your are have it, 64 rmd160 binary file.

About linux i will think about your suggestion, thanks.

Run the addresses_to_hash160.py on your file to convert it to binary(.bin)
How can i do it?  

No here is require BINARY data not text data so you need to run the addresses_to_hash160.py on your file to convert it to binary(.bin).

In Windows its a pain.
But in Linux its just few command line(no programming)

1- sudo apt install build-essential git libgmp-dev python3-pip nano  -y
2- git clone https://github.com/kanhavishva/KeyHunt-Cuda
3- cd KeyHunt-Cuda/KeyHunt-Cuda/
4- nano Makefile (go to line "CUDA       = /usr/local/cuda-11.0" and change it to your cuda version for example "CUDA       = /usr/local/cuda-11.2"
5- make gpu=1 CCAP=21 all

And you ready to go ./KeyHunt....

I really know its look like too difficult but you should do it and take your time, week month its OK.
You can use https://vast.ai/console/ to rent cheap one for few hours and start to learn more about Linux and KeyHunt-Cuda (choose docker image "nvidia/cuda:11.2.0-devel-ubuntu18.04")

I simply copied the rmd160 from here : https://privatekeys.pw/address/bitcoin/16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN
It works fine with keyhunt, it should work with keyhunt-cuda too.

change CCAP to 21? unfortunately i'm not a programmer..  

Did you convert the 64 address to rmd160 using addresses_to_hash160.py?

It possible work but you need to build new execution file and change CCAP to 21(see build section for more details)

Thanks again 7isce!  

I've just tried keyhunt-cuda in cpu only mode, same keyrange/address of last keyhunt tests, but it doesn't find the privkey, it simply tells me "BYE".  

What am I doing wrong?

C:\Keyhunt>KeyHunt-Cuda.exe -t 4 --gpui 0 -m address --coin BTC --range f7051f279dcf0000:f7051f27d969c800 -i 64rmd160.txt

KeyHunt-Cuda v1.08

COMP MODE    : COMPRESSED
COIN TYPE    : BITCOIN
SEARCH MODE  : Single Address
DEVICE       : CPU
CPU THREAD   : 4
SSE          : YES
RKEY         : 0 Mkeys
MAX FOUND    : 65536
BTC ADDRESS  :
OUTPUT FILE  : Found.txt


Bloom at 0000021232587F70
  Version    : 2.1
  Entries    : 4
  Error      : 0.0000010000
  Bits       : 115
  Bits/Elem  : 28.755175
  Bytes      : 15 (0 MB)
  Hash funcs : 20

Start Time   : Fri Sep 30 16:31:17 2022
Global start : F7051F279DCF0000 (64 bit)
Global end   : F7051F27D969C800 (64 bit)
Global range : 3B9AC800 (30 bit)


[00:04:07] [CPU+GPU: 4.07 Mk/s] [GPU: 0.00 Mk/s] [C: 100.938189 %] [R: 0] [T: 1,009,381,376 (30 bit)] [F: 0]

BYE

C:\

I tried the GPU mode but it asks me for anotrer Cuda driver version..

C:\Keyhunt>KeyHunt-Cuda.exe -t 0 -g --gpui 0 --gpux 256,256 -m address --coin BTC --range f7051f279dcf0000:f7051f27d969c800 -i 64rmd160.txt

KeyHunt-Cuda v1.08

COMP MODE    : COMPRESSED
COIN TYPE    : BITCOIN
SEARCH MODE  : Single Address
DEVICE       : GPU
CPU THREAD   : 0
GPU IDS      : 0
GPU GRIDSIZE : 256x256
SSE          : YES
RKEY         : 0 Mkeys
MAX FOUND    : 65536
BTC ADDRESS  :
OUTPUT FILE  : Found.txt


Bloom at 00000264DD553A50
  Version    : 2.1
  Entries    : 4
  Error      : 0.0000010000
  Bits       : 115
  Bits/Elem  : 28.755175
  Bytes      : 15 (0 MB)
  Hash funcs : 20

Start Time   : Fri Sep 30 16:59:59 2022
Global start : F7051F279DCF0000 (64 bit)
Global end   : F7051F27D969C800 (64 bit)
Global range : 3B9AC800 (30 bit)

cudaSafeCall() failed at D:/PROGRAMMING/VisualStudioProjects/KeyHunt-Cuda-GIT-2017/KeyHunt-Cuda/KeyHunt-Cuda/GPU/GPUEngine.cu:283 : CUDA driver version is insufficient for CUDA runtime version

C:\Keyhunt>

I have a Nvidia Geforce 820M 2Gb, with the latest driver available.
Do you think keyhunt-cuda cannot work on these old gpus?

In your case go with 4.
But if you want my advice, then you should quit keyhunt(CPU) and go with https://github.com/secp8x32/KeyHunt-Cuda which is GPU.
I run keyhunt(CPU) for many months and I also get many rented dedicated servers to run it.
I try random/sequential rmd160, bsgs with about ~16 Ekeys/s  and 1TB RAM, I also try xpoint of 120-bit with billions of subtraction points from the public key, ...etc

Keyhunt(CPU) rmd160 give you 10-80MKey/s in best server but in low GPU tier like GTX 1080 ti, you can easily get 200-300MKey/s and for medium tire (like RTX 3070) 1100-1300MKey/s and for high end(like RTX 3090 ti) you get up to 2400MKey/s.

If you want to learn and do some testing then its OK to go with keyhunt(CPU) but if you want really to find any address then you should go the KeyHunt-Cuda(GPU)

Thanks for explanation!  

My laptop has windows 10, no other softwares are running and internet is offline (i read the forum with another computer), is it better if i consider 3 threads for keyhunt (-t 3) saving 1 thread for windows, or 4 (-t 4) is ok too?
Or is it better to use 1 thread only (-t 1)?
With linux it will be more powerful to use keyhunt? 20% faster? do you suggest Ubuntu?

No, 2 core 4 threads mean each core have 2 thread (Thread/Core give you number of thread per core).
OS can have as many threads needed, its just software. There are no limit(Theoretically).


But we are here talking about thread of same program(Keyhunt). Core can hand one thread at time("IN CPU TIME").
Because the CPU core is too fast like in nanosecond and the program could need to access RAM or other resources, let say for example accessing the RAM will require 300 nanosecond which is too fast but for CPU core is too slow.
What CPU core doing in this case is one of three chooses:
1- keep this program aside for let say 300 nanosecond and take next program in same thread.
2- pause a whole thread for 300 nanosecond and go complete to new thread in waiting list.
3- if that only program running on PC then the CPU core will be idle state waiting for information from RAM.

Hashing process is CPU process intensive which not have that much waiting time.
And you also forget about you OS(windows, Linux) which have a lot of services ruining in background. Everything you see in you laptop like internet, monitor, antivirus...etc are need some background service to hand it all the time.
So if these services not have enough time to run on CPU then you system will be lagging or the worst will be crush.

Intel on italian website (not in the english version) declares:
A thread, or thread of execution, is a software term for the basic ordered sequence of instructions that can be transmitted by a single CPU core.
https://www.intel.it/content/www/it/it/products/sku/134599/intel-core-i912900k-processor-30m-cache-up-to-5-20-ghz/specifications.html

2 cores 4 threads, if i understand well Intel definition, each cores can manage 4 threads, so 2 cores can manage 8 threads? or not?

Intel i9-12900K maybe the fastest processor has 16 cores and 24 threads, so if i have understand well it can manage 384 threads. Correct?

I think you're right about the false keys/s output. I've just done the statistic with -t 4 and -t 8 too:

-t 4 = 1.118.000 keys/s (found privkey in less than 4 minutes after 285 million keys examined)
-t 8 = 1.227.000 keys/s (found privkey in less than 9 minutes after 662 million keys examined)

All statistics done say that the privkey with a keyrange of 1.000.000.000 keys can be found in less than 10 minutes.
The time spent seems the only real value. Threads (range 4-256) seems to give quite the same result in terms of time waited.

I think you misunderstand.
The maximum number for threads is the maximum CPU threads( In your laptop is 4 thread). More than that is just reducing the speed and it could give you false output(like 40.5Mkeys/s but in reality is just 0.1Mkeys/s)

The pub2rmd is in experimental modes so it could have many bugs.
Its better if you go with rmd160 mode and have as many address as your RAM can have.
Here you can download all address in bitcoin: http://addresses.loyce.club/?C=M;O=D
And then you can pickup as many address you want that start with 1

Thanks again 7isce!  

Before buying a faster cpu i want to understand well how keyhunt works (i use version 0.2.211012 chocholate beta) and how to obtain the best performance.
I did several random tests to identify which is the better thread value (-t).

My cpu is an Intel Core i7-4500U 1,80-3,00Ghz (2 cores 4 threads)
Is it possible to calculate the best -t value from the cpu specifications?
I could ipotize 4 but it's not correct.

Let's see my tests statistic with a keyspace of 1.000.000.000 keys on puzzle 64 in rmd106 mode (consider that the highest keys/s value takes 3-6 minutes):

-t 16 = 1.360.000 keys/s
-t 96 = 2.270.000.000 keys/s
-t 160 = 2.800.000-3.000.000 keys/s (found privkey in less than 6 minutes after 1020 million keys examined)
-t 192 = 3.000.000-3.300.000 keys/s (found privkey in less than 4 minutes after 804 million keys examined)
-t 208 = 3.300.000-3.600.000 keys/s (found privkey in less than 10.5 minutes after 2300 million keys examined)
-t 216 = 3.300.000-3.700.000 keys/s (found privkey in less than 7 minutes after 1585 million keys examined)
-t 220 = 3.300.000-3.500.000 keys/s (found privkey in less than 3.5 minutes after 692 million keys examined)
-t 224 = 3.600.000-3.900.000 keys/s (found privkey in less than 4 minutes after 872 million keys examined)
-t 228 = 3.500.000 keys/s (found privkey in less than 1 minute after 95 million keys examined)
-t 230 = 3.200.000 keys/s (found privkey in less than 1 minute after 74 million keys examined)
-t 256 = 3.500.000-3.800.000 keys/s  (found privkey in less than 3.5 minute after 805 million keys examined)
-t 512 = 500.000 keys/s (found privkey in less than 3 minutes after 96 million keys examined)
-t 1024 = 700.000 keys/s (found privkey in less than 13 minutes after 515 million keys examined)
Sometime happened that that the key has been found in less than a minute, of course i skipped these tests results because the keys/s number was not readable.
 
Was it possible to get the 224 with a calculation considering the cpu specs?
Do you think that with a larger keyspace (for ex. 1.000.000.000.000 keys) the - t value statistic could be different for the keys/s?

Another question: to use bsgs mode with keyhunt we need to write in the .txt file the pubkey in the long format.
In puzzle 64 the long format is : 03100611c54dfef604163b8358f7b7fac13ce478e02cb224ae16d45526b25d9d4d
But we haven't it for puzzle 66!!!
So to get it with keyhunt there is the pub2rmd mode.
But why should i spend time to use the pub2rmd and only after (IF i get the pubkey) use the bsgs mode to get the privkey?
It seems faster to use the rmd160 mode and wait the privkey directly. Am i wrong?
Have you found the pubkey of puzzle 66???

That's right, if you search for only for puzzle addresses which are compress public key then compress mode is where to go!

Thanks 7isce i've understood.  

About the puzzle #66 are we sure that the public address 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so and its corrispondent hash 160 20d45a6a762535700ce9e0b216e31994335db8a5 is compressed?
https://privatekeys.pw/address/bitcoin/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so

If you look at #64 the public key is considered compressed
https://privatekeys.pw/address/bitcoin/16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

the question is to reduce the cpu work setting on keyhunt only: -l compress

In the compress mode in rmd160 mode i can calculate 2,34 Mkey/s
In the both (compress and uncompress mode) only 1,11 Mkey/s (the half)

Anyway the rmd160 mode is much better than the address mode (only 375000 keys/s), it calculates 6.24 times more keys!  
The rmd160 mode needs the file.txt with the hash 160 address only.

Don't mention it

You can thing the CPU as a factory that have workers(which are the Cores) and production lines(which are the threads).
So the thread is just giving the core more room to handle many things at same time.
In other word, core is making the processing part and the thread is waiting line for the core.

You can keep 1 thread for you OS(Windows,Linux) and the remaining for keyhunt if you not working on it. otherwise, you should keep more thread to OS as much work you have it.

As I know, N is having default value 0x100000000000 44-bits. It will be the same until you change it.

Thanks for help!  

i found the discussion: https://github.com/albertobsd/keyhunt/issues/72

I divided the keyrange of puzzle 66 in 4 parts, each one of 9223372036854776750 keys
In random mode (-R) what's the best thread (-t) number?

My laptop cpu ( i7-4500U) has 2 cores and 4 threads.
Better if i write: keyhunt -m address -f addresses.txt -r 20000000000000000:27fffffffffff2000 -l compress -c btc -R -t 4 ??

I don't understand well the "thread" concept.
Is it a division of the keyrange in parts that are calculated separately? so if i write 4 i have 4 different random count for each part?
and each part use 0x100000000000 as base key? or the base key is proportional automatically according to the keyrange?  

I think the problem come from N value.
As quote from albertobsd:
"ever thread set his own base key, N = 17592186044416 this is 0x100000000000 (hexadecimal) (2^25)"

I think for small range using random is useless, just use sequential.

Thanks, i was starting thinking it when there wasn't any gpu detected during keyhunt running.
The laptop heat reduction is less under stress too than with clbitcrack.

So, the cpu statistic with keyhunt is:
i7 4500U 1,80 - 2,40 Ghz = 370000 keys/s (my old 2015 laptop)
i7 6700K quad core 4.0 Ghz = 745040 keys/s
i10 (i don't exactly which one) = 3410368 keys/s

By the way i don't understand why keyunt in random mode calculates keys outside the keyspace.
I've done the following test from 1 to 5 (= 5 keys):

C:\Keyhunt>keyhunt -m address -f addresses.txt -r 1:5 -l compress -c btc -R -t 96 -M -s 2

• Version 0.2.211012 Chocolate ┬íBeta!, developed by AlbertoBSD(Win64 build by KV)
• Mode address
• Search compress only
• Setting search for BTC adddress.
• Random mode
• Threads : 96
• Matrix screen
• Stats output every 2 seconds
• Opening file addresses.txt
• Allocating memory for 1 elements: 0.00 MB
• Bloom filter for 1 elements.
• Loading data to the bloomfilter total: 0.00 MB
• Bloomfilter completed
• Sorting data ... done! 1 values were loaded and sorted

Base key: 4
Base key: 4
Base key: 4
Base key: 4
Base key: 3
Base key: 404
Base key: 404
Base key: 1
Base key: 403
Base key: 804
Base key: 401
Base key: 804
Base key: 803
Base key: 2
Base key: 4
Base key: 1
Base key: 2
Base key: 2
Base key: 404
Base key: 804
Base key: 2
Base key: 402
Base key: 402
Base key: c04
Base key: 402
Base key: 802
Base key: 802
Base key: 801
Base key: 4
Base key: c03
Base key: 402

I quitted keyhunt after the first results.
WHY does keyhunt consider keys outside the keyspace???
I tried with keyspaces bigger than 5. Same result, a lot of keys counted are outside the keyspace! WHY???