Pages:
Author

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

jr. member
Activity: 35
Merit: 2
Thanks for your comments.
 I understand that it goes upto hash160 function only but public keys are generated at very starting stages so writing private keys and public keys is possible.
Is there any implementation of same in python or c or any low level language like brainflayer had. So it can be modified accordingly. Brainflayer speed for incremental private keys is less than 500k/s . Or if anyone knows any such private key public key database already built for some keyspace .

Hi guys ,

Can this tool or any modification of this be modified to write all private keys and respective uncompressed private keys and addresses) in range 1 to 56BC75E2D630FFFFF as a csv file . Since it generates 700 to xxxx million keys /s in some of its versions , so it will take many years on a single machine. But still looking for solutions. Writing regular outputs will consume too much time
So better it will save several millions or billions in some sort of memory operation and then write them once ,  till then next batch will find its space in memory to be written again.

If I understand you correctly, you are saying that Bitcrack should write the address of each private key it finds to a file?

How would that speed up key searching? Bitcrack doesn't even encode addresses anyway (it only decodes them to RIPEMD160 hash at the beginning of a search) so modifying it to make an address out of every address it finds will slow it down.

I agree with write to file make bitcrack slowly
both technic open file and write file each key or collector on memory and write one same work slow
(write to file use low memory and write one use large memory too)

if you need write to file on this case it no need to use bitcrack just use any python script write to file it fast same your want both random and running number
I try already like python write file private key 1 million per 4 minute (up to harddisk or SSD storage)

if you want to collect private key is use a log of storage to keep it too. plan text file is very small but when have billions trillion line use some space
64 billion private key data use 4TB disk, how many you need to keep

most decide to scan and let it go
member
Activity: 406
Merit: 47
Hi guys ,

Can this tool or any modification of this be modified to write all private keys and respective uncompressed private keys and addresses) in range 1 to 56BC75E2D630FFFFF as a csv file . Since it generates 700 to xxxx million keys /s in some of its versions , so it will take many years on a single machine. But still looking for solutions. Writing regular outputs will consume too much time
So better it will save several millions or billions in some sort of memory operation and then write them once ,  till then next batch will find its space in memory to be written again.

If I understand you correctly, you are saying that Bitcrack should write the address of each private key it finds to a file?

How would that speed up key searching? Bitcrack doesn't even encode addresses anyway (it only decodes them to RIPEMD160 hash at the beginning of a search) so modifying it to make an address out of every address it finds will slow it down.

I agree with write to file make bitcrack slowly
both technic open file and write file each key or collector on memory and write one same work slow
(write to file use low memory and write one use large memory too)

if you need write to file on this case it no need to use bitcrack just use any python script write to file it fast same your want both random and running number
I try already like python write file private key 1 million per 4 minute (up to harddisk or SSD storage)

if you want to collect private key is use a log of storage to keep it too. plan text file is very small but when have billions trillion line use some space
64 billion private key data use 4TB disk, how many you need to keep

most decide to scan and let it go
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
Hi guys ,

Can this tool or any modification of this be modified to write all private keys and respective uncompressed private keys and addresses) in range 1 to 56BC75E2D630FFFFF as a csv file . Since it generates 700 to xxxx million keys /s in some of its versions , so it will take many years on a single machine. But still looking for solutions. Writing regular outputs will consume too much time
So better it will save several millions or billions in some sort of memory operation and then write them once ,  till then next batch will find its space in memory to be written again.

If I understand you correctly, you are saying that Bitcrack should write the address of each private key it finds to a file?

How would that speed up key searching? Bitcrack doesn't even encode addresses anyway (it only decodes them to RIPEMD160 hash at the beginning of a search) so modifying it to make an address out of every address it finds will slow it down.
jr. member
Activity: 35
Merit: 2
Hi guys ,

Can this tool or any modification of this be modified to write all private keys and respective uncompressed private keys and addresses) in range 1 to 56BC75E2D630FFFFF as a csv file . Since it generates 700 to xxxx million keys /s in some of its versions , so it will take many years on a single machine. But still looking for solutions. Writing regular outputs will consume too much time
So better it will save several millions or billions in some sort of memory operation and then write them once ,  till then next batch will find its space in memory to be written again.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
Stack trace of the instructions before (or after?) the misaligned access error instruction:

Code:
(cuda-gdb) x/10i $pc
=> 0x5555564d08e0 <_Z25keyFinderKernelWithDoubleii+58848>:������LD.E.SYS R0, [R22]
   0x5555564d08f0 <_Z25keyFinderKernelWithDoubleii+58864>:
    SHF.L.W.U32.HI R2, R3.reuse, 0x1a, R3.reuse
   0x5555564d0900 <_Z25keyFinderKernelWithDoubleii+58880>:
    ULOP3.LUT UR5, UR4, UR7, URZ, 0x3c, !UPT
   0x5555564d0910 <_Z25keyFinderKernelWithDoubleii+58896>:
    SHF.L.W.U32.HI R5, R3.reuse, 0x15, R3.reuse
   0x5555564d0920 <_Z25keyFinderKernelWithDoubleii+58912>:
    IMAD.MOV.U32 R28, RZ, RZ, c[0x3][0x35c]
   0x5555564d0930 <_Z25keyFinderKernelWithDoubleii+58928>:
    SHF.L.W.U32.HI R4, R3.reuse, 0x7, R3
   0x5555564d0940 <_Z25keyFinderKernelWithDoubleii+58944>:
    IMAD.MOV.U32 R14, RZ, RZ, c[0x3][0x3a4]
   0x5555564d0950 <_Z25keyFinderKernelWithDoubleii+58960>:
    LOP3.LUT R6, R3, c[0x3][0x374], RZ, 0xc, !PT
   0x5555564d0960 <_Z25keyFinderKernelWithDoubleii+58976>:
    ULOP3.LUT UR5, UR5, UR6, URZ, 0xc0, !UPT
   0x5555564d0970 <_Z25keyFinderKernelWithDoubleii+58992>:
    LOP3.LUT R5, R4, R2, R5, 0x96, !PT

I have no idea what sense to make out of the resulting CUDA disassembly (the error cannot be reproduced in debug mode forcing me to rely on the instruction pointer $pc (program counter))



Ok here's a better disassembly:

Code:
(cuda-gdb) x/20i $pc-256
   0x5555567b75e0 <_Z25keyFinderKernelWithDoubleii+58592>:������STL [R1+0x5c], R10
   0x5555567b75f0 <_Z25keyFinderKernelWithDoubleii+58608>:������STL [R1+0x60], R12
   0x5555567b7600 <_Z25keyFinderKernelWithDoubleii+58624>:
    IMAD.MOV.U32 R4, RZ, RZ, R55
   0x5555567b7610 <_Z25keyFinderKernelWithDoubleii+58640>:
    IMAD.MOV.U32 R5, RZ, RZ, R54
   0x5555567b7620 <_Z25keyFinderKernelWithDoubleii+58656>:������CALL.ABS.NOINC 0x0
   0x5555567b7630 <_Z25keyFinderKernelWithDoubleii+58672>:������BSYNC B6
   0x5555567b7640 <_Z25keyFinderKernelWithDoubleii+58688>:
    IMAD.MOV.U32 R0, RZ, RZ, 0x2
   0x5555567b7650 <_Z25keyFinderKernelWithDoubleii+58704>:
    LOP3.LUT R0, R0, c[0x0][0x164], RZ, 0xfc, !PT
   0x5555567b7660 <_Z25keyFinderKernelWithDoubleii+58720>:
    ISETP.NE.AND P0, PT, R0, 0x2, PT
   0x5555567b7670 <_Z25keyFinderKernelWithDoubleii+58736>:������@P0 BRA 0x17250
   0x5555567b7680 <_Z25keyFinderKernelWithDoubleii+58752>:
    IMAD R23, R60, 0x7, R53
   0x5555567b7690 <_Z25keyFinderKernelWithDoubleii+58768>:
    IMAD.MOV.U32 R3, RZ, RZ, c[0x3][0x36c]
   0x5555567b76a0 <_Z25keyFinderKernelWithDoubleii+58784>:
    IMAD.MOV.U32 R9, RZ, RZ, c[0x3][0x3a0]
   0x5555567b76b0 <_Z25keyFinderKernelWithDoubleii+58800>:
    ULDC UR4, c[0x3][0x364]
   0x5555567b76c0 <_Z25keyFinderKernelWithDoubleii+58816>:
    IMAD.WIDE R22, R23, 0x4, R78
   0x5555567b76d0 <_Z25keyFinderKernelWithDoubleii+58832>:
    ULDC.64 UR6, c[0x3][0x35c]
=> 0x5555567b76e0 <_Z25keyFinderKernelWithDoubleii+58848>:������LD.E.SYS R0, [R22]
   0x5555567b76f0 <_Z25keyFinderKernelWithDoubleii+58864>:
    SHF.L.W.U32.HI R2, R3.reuse, 0x1a, R3.reuse
   0x5555567b7700 <_Z25keyFinderKernelWithDoubleii+58880>:
    ULOP3.LUT UR5, UR4, UR7, URZ, 0x3c, !UPT
   0x5555567b7710 <_Z25keyFinderKernelWithDoubleii+58896>:
    SHF.L.W.U32.HI R5, R3.reuse, 0x15, R3.reuse

Now the faulty instruction is the one with the arrow on the left, and the last 20 or so instructions are the ones accessing bad memory.

We already know that the problem function is "doIterationWithDouble" so all searching should be done there

We just need to see how this CUDA Pseudo-C code translates into PTX assembly  Lips sealed



Take three

Full disassembly of the CUDA function "_Z25keyFinderKernelWithDoubleii" (whatever that means! Huh) is available at https://files.notatether.com/public/temp/bitcrack/gdblog.txt for anyone who's interested. It stands at 685KB large.

Matching the statements to their disassembled instructions may be our only chance of identifying the problematic regions of memory (the faulty statement has already been found but we don't yet know where the misalignment is coming from).

This disassembly might also include functions other than doIterationWithDouble, because the entire kernel was dumped (so that means that anything compiled in the same nvcc command is potentially in there).



Most interesting is this line:

   0x00005555567b76d0 <+58832>: ULDC.64 UR6, c[0x3][0x35c] <-- Crash location

It seems to be doing some 64 bit operation on an array in memory located at... 0x35c (bingo: 0xc is not a multiple of 64 bits = 0x8: there is our misaligned access error).

Now the question is which array does this correspond to.

small edit: fix broken link
legendary
Activity: 959
Merit: 1037
Anyone can compile for latest CUDA? So we can use with new RTX cards. Thanks!

If you meant putting something like this in the Makefile:

Code:
-arch=sm_35 \
 -gencode=arch=compute_35,code=sm_35 \
 -gencode=arch=compute_50,code=sm_50 \
 -gencode=arch=compute_52,code=sm_52 \
 -gencode=arch=compute_60,code=sm_60 \
 -gencode=arch=compute_61,code=sm_61 \
 -gencode=arch=compute_70,code=sm_70 \
 -gencode=arch=compute_75,code=sm_75 \
 -gencode=arch=compute_80,code=sm_80 \
 -gencode=arch=compute_86,code=sm_86 \

Which compiles for all GPUs supported by CUDA 11.2, it turns out that it's taking a long time to build cuBitCrack - It's already been 20 minutes.

Edit: scratch that, the compile job finished the second I posted this  Shocked It stands at 7.5MB large, not bad for a fatbinary with nine different arch versions in it. However this also gives me the misaligned address error on my T4, but now that I have it here I can finally diagnose it.

Great!  Grin Waiting your results with excitement  Cool
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
Anyone can compile for latest CUDA? So we can use with new RTX cards. Thanks!

If you meant putting something like this in the Makefile:

Code:
-arch=sm_35 \
 -gencode=arch=compute_35,code=sm_35 \
 -gencode=arch=compute_50,code=sm_50 \
 -gencode=arch=compute_52,code=sm_52 \
 -gencode=arch=compute_60,code=sm_60 \
 -gencode=arch=compute_61,code=sm_61 \
 -gencode=arch=compute_70,code=sm_70 \
 -gencode=arch=compute_75,code=sm_75 \
 -gencode=arch=compute_80,code=sm_80 \
 -gencode=arch=compute_86,code=sm_86 \

Which compiles for all GPUs supported by CUDA 11.2, it turns out that it's taking a long time to build cuBitCrack - It's already been 20 minutes.

Edit: scratch that, the compile job finished the second I posted this  Shocked It stands at 7.5MB large, not bad for a fatbinary with nine different arch versions in it. However this also gives me the misaligned address error on my T4, but now that I have it here I can finally diagnose it.
legendary
Activity: 959
Merit: 1037
Anyone can compile for latest CUDA? So we can use with new RTX cards. Thanks!
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
It's working perfectly, 0 bugs for me, I see a lot of people in this thread never heard of command prompt or hex or binary before they heard about bitcrack so that might be the case.
It's relatively simple software I don't see how it could be so full of errors.

What is your GPU model and driver version?

(The OpenCL version is still beta)
newbie
Activity: 62
Merit: 0
It's working perfectly, 0 bugs for me, I see a lot of people in this thread never heard of command prompt or hex or binary before they heard about bitcrack so that might be the case.
It's relatively simple software I don't see how it could be so full of errors.

Stride error is also probably on my side, not btcrack, but I can't figure it out
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Quote
idk buddy I never found a single bug, it never skipped a key without stride...
You never found one bug with the newest CL (not CU) bitcrack version?  This thread is full of people reporting bugs.
newbie
Activity: 62
Merit: 0
Normally Bitcrack finds all the keys, it never skips any, but --stride option is not working for me. I put 20 keys randomly where there should be a collision, bitcrack finds the first ones but as it goes through the whole range it skips keys.
Also it finishes the scan way too fast, so I know it doesn't scan the whole range as instructed.


Example:
clBitCrack.exe -i addresses.txt -o keys.txt  --stride 4C4B40 --keyspace 0000000000000000000000000000000000000000000000008000000000000000:0000000000000000000000000000000000000000000000010000000000000000

Stride is 5mil and range is 2**63 - 2**64

What am I doing wrong?


If you are using the cl version, it is known to be riddled with bugs...who knows what it could be.
idk buddy I never found a single bug, it never skipped a key without stride...
newbie
Activity: 62
Merit: 0
Normally Bitcrack finds all the keys, it never skips any, but --stride option is not working for me. I put 20 keys randomly where there should be a collision, bitcrack finds the first ones but as it goes through the whole range it skips keys.
Also it finishes the scan way too fast, so I know it doesn't scan the whole range as instructed.


Example:
clBitCrack.exe -i addresses.txt -o keys.txt  --stride 4C4B40 --keyspace 0000000000000000000000000000000000000000000000008000000000000000:0000000000000000000000000000000000000000000000010000000000000000

Stride is 5mil and range is 2**63 - 2**64

What am I doing wrong?



Alright this means roughly every 2^22 keys or so are skipped. Do your input addresses have hex private keys that are exactly on a 0x4C4B40 interval between 2^63 and 2^64? I mean are your keys something like 2^63 + (0x4C4B40 * 1 2 3 4 5 6 etc)?

It may have something to do with the stride being multiplied by the number of points (pointsPerThread * Threads * Blocks) so the PointsPerThread (-p/--points) value is definitely something to look at.
Thanks!
Of course, for example I start from 0, stride is 1000 I put addresses with pk 1000, 10000, 15000,150000,1000000 ... btcrack saves first few later it finds nothing.
Idk anything about points, how does it work exactly?
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Normally Bitcrack finds all the keys, it never skips any, but --stride option is not working for me. I put 20 keys randomly where there should be a collision, bitcrack finds the first ones but as it goes through the whole range it skips keys.
Also it finishes the scan way too fast, so I know it doesn't scan the whole range as instructed.


Example:
clBitCrack.exe -i addresses.txt -o keys.txt  --stride 4C4B40 --keyspace 0000000000000000000000000000000000000000000000008000000000000000:0000000000000000000000000000000000000000000000010000000000000000

Stride is 5mil and range is 2**63 - 2**64

What am I doing wrong?


If you are using the cl version, it is known to be riddled with bugs...who knows what it could be.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
Normally Bitcrack finds all the keys, it never skips any, but --stride option is not working for me. I put 20 keys randomly where there should be a collision, bitcrack finds the first ones but as it goes through the whole range it skips keys.
Also it finishes the scan way too fast, so I know it doesn't scan the whole range as instructed.


Example:
clBitCrack.exe -i addresses.txt -o keys.txt  --stride 4C4B40 --keyspace 0000000000000000000000000000000000000000000000008000000000000000:0000000000000000000000000000000000000000000000010000000000000000

Stride is 5mil and range is 2**63 - 2**64

What am I doing wrong?



Alright this means roughly every 2^22 keys or so are skipped. Do your input addresses have hex private keys that are exactly on a 0x4C4B40 interval between 2^63 and 2^64? I mean are your keys something like 2^63 + (0x4C4B40 * 1 2 3 4 5 6 etc)?

It may have something to do with the stride being multiplied by the number of points (pointsPerThread * Threads * Blocks) so the PointsPerThread (-p/--points) value is definitely something to look at.
newbie
Activity: 62
Merit: 0
Normally Bitcrack finds all the keys, it never skips any, but --stride option is not working for me. I put 20 keys randomly where there should be a collision, bitcrack finds the first ones but as it goes through the whole range it skips keys.
Also it finishes the scan way too fast, so I know it doesn't scan the whole range as instructed.


Example:
clBitCrack.exe -i addresses.txt -o keys.txt  --stride 4C4B40 --keyspace 0000000000000000000000000000000000000000000000008000000000000000:0000000000000000000000000000000000000000000000010000000000000000

Stride is 5mil and range is 2**63 - 2**64

What am I doing wrong?

newbie
Activity: 11
Merit: 0
I am looking for random version, so every key is is generated random, is there any version.

@escobol told me off-forum that he had someone make such a version for him so you might want to PM him for access to that.

How do I contact him facebook, twitter, telegram
Go to messages. Select New Messages, Select Find Members. Enter escobol. Select his name when it pops up. Or enter "escobol" into To block.

Wait - sorry, I got names mixed up  Undecided it was elisacat who told me that he has the program, not escobol, and it was on Telegram - I never even talked to escobol on TG.

I may have a copy of it myself, but I have to search my chats for it (it's a python script wrapper around Bitcrack).


Yes, not me.

BTW
„This code also incorporates the popular but now removed pikachunakapika fork containing random mode along with the other tweaks.”
https://github.com/djarumlights/BitCrack




I am looking for random version so every key is random , pikachunakapika only give random point
member
Activity: 158
Merit: 39
I am looking for random version, so every key is is generated random, is there any version.

@escobol told me off-forum that he had someone make such a version for him so you might want to PM him for access to that.

How do I contact him facebook, twitter, telegram
Go to messages. Select New Messages, Select Find Members. Enter escobol. Select his name when it pops up. Or enter "escobol" into To block.

Wait - sorry, I got names mixed up  Undecided it was elisacat who told me that he has the program, not escobol, and it was on Telegram - I never even talked to escobol on TG.

I may have a copy of it myself, but I have to search my chats for it (it's a python script wrapper around Bitcrack).


Yes, not me.

BTW
„This code also incorporates the popular but now removed pikachunakapika fork containing random mode along with the other tweaks.”
https://github.com/djarumlights/BitCrack

legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
I am looking for random version, so every key is is generated random, is there any version.

@escobol told me off-forum that he had someone make such a version for him so you might want to PM him for access to that.

How do I contact him facebook, twitter, telegram
Go to messages. Select New Messages, Select Find Members. Enter escobol. Select his name when it pops up. Or enter "escobol" into To block.

Wait - sorry, I got names mixed up  Undecided it was elisacat who told me that he has the program, not escobol, and it was on Telegram - I never even talked to escobol on TG.

I may have a copy of it myself, but I have to search my chats for it (it's a python script wrapper around Bitcrack).

EDIT: yeah, it's not in my chats  Sad
full member
Activity: 1162
Merit: 237
Shooters Shoot...
I am looking for random version, so every key is is generated random, is there any version.

@escobol told me off-forum that he had someone make such a version for him so you might want to PM him for access to that.

How do I contact him facebook, twitter, telegram
Go to messages. Select New Messages, Select Find Members. Enter escobol. Select his name when it pops up. Or enter "escobol" into To block.
Pages:
Jump to: