Can someone please help me. The cubitcrack hangs after loading address and does nothing.
Thank you.
Topic: BitCrack - A tool for brute-forcing private keys - page 36. (Read 77647 times)
Is there a reason why BitCrack is not under maintenance any more?
Should we create a new Fork, where we combine all the good patches?
I would be happy to take this job (and be the benevolent dictator it needs
).
Because most see it as a waste of time/next to impossible, especially since everyone is trying to attack #64 solo. #64 requires many resources to crack, and the next one, #66 will be 4 times as hard, and will get harder and harder as you go up.Should we create a new Fork, where we combine all the good patches?
I would be happy to take this job (and be the benevolent dictator it needs
).EDIT: also, because there are other programs that can run multi gpu's on one instance, bitcrack is sort of archaic. Maybe make it multi gpu and you can gain some new interest.
Is there a reason why BitCrack is not under maintenance any more?
Should we create a new Fork, where we combine all the good patches?
I would be happy to take this job (and be the benevolent dictator it needs).
Should we create a new Fork, where we combine all the good patches?
I would be happy to take this job (and be the benevolent dictator it needs
).
Well... there are "only" 16^10 permutations to check empirically if there is a correlation. Have fun
counter-evidence:
3bd3536aea8ceb2b => 1DB6to5oCUJ3mLELL7M9JsMdhHQxfVLVHK
counter-evidence:
3bd3536aea8ceb2b => 1DB6to5oCUJ3mLELL7M9JsMdhHQxfVLVHK
And what about this --
That is why I have a little hope that it might work I know hash function is totally different what I thought but for me it maybe a ray of hope in despair...
16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN -
16jY7qLJnxLQQRYPX5BLuCtcBs6tvXz8BE - 3AD3536AEA8CEB2B0
16jY7qLJnx2EZZumnYFke3GutCrRnHKs1M - 7013536A91A6441B0
That is why I have a little hope that it might work I know hash function is totally different what I thought but for me it maybe a ray of hope in despair...
Any correlation is just a coincidence as the probability of finding a private key for that address which has those green characters is astronomically small.
You what propose?
You ask "How long time for bitcrack calculate form RIPEMD-160 and double sha256 then Base58"
Answer is 0
Because bitcrack not do calculate from RIPEMD-160 and double sha256 then base58
Bitcrack convert address legacy compress address to RIPEMD-160 and calculate till step 3 of http://gobittest.appspot.com/Address
bitcrack then compare calculated RIPEMD-160 with RIPEMD-160 address in bloom filter
you understand?
You ask "How long time for bitcrack calculate form RIPEMD-160 and double sha256 then Base58"
Answer is 0
Because bitcrack not do calculate from RIPEMD-160 and double sha256 then base58
Bitcrack convert address legacy compress address to RIPEMD-160 and calculate till step 3 of http://gobittest.appspot.com/Address
bitcrack then compare calculated RIPEMD-160 with RIPEMD-160 address in bloom filter
you understand?
What you propose is already implemented in bitcrack.
propose make BitCrack scan key faster?
I know already bitcrack have all process convert key to address on bitcrack include RIPEMD-160 inside
I not sure you not yet understand
bitcrack bruteforce address right?
this idea just bruteforce to RIPEMD-160
however if this method not difference
if you bitcrack work on GPU can scan 1000Mkey/s
and if process use time to do 30% second if do this idea will help to make GPU scan at 1300 Key/s
What you propose is already implemented in bitcrack.
this idea is help to accelerate spped of bitcrack for scan to high
for use bitcrack solve puzzle #64
address still legacy address and all puzzle is compress address
refer my post with RIPEMD-160
now, we try to optimize bitcrack to can scan address faster and high number right
idea is just cut off process of bitcrack to
I not yet read bitcrack souce code, Did bitcrack convert publickey to RIPEMD-160 and double sha256 or not?
bitcrack convert key to address and check compare gen address and target address right?
reference this app
http://gobittest.appspot.com/Address
you can see we can convert address to roll back to RIPEMD-160
put address to box 9 - Base58 encoding of 8 and click send
web app will convert back to RIPEMD-160
idea it is just convert address to RIPEMD-160 and cut out work process to short
hope this method help to can scan bitcrack faster up to 30% (if 30% is process from RIPEMD-160 to address)
just idea please ignore
for use bitcrack solve puzzle #64
address still legacy address and all puzzle is compress address
refer my post with RIPEMD-160
now, we try to optimize bitcrack to can scan address faster and high number right
idea is just cut off process of bitcrack to
I not yet read bitcrack souce code, Did bitcrack convert publickey to RIPEMD-160 and double sha256 or not?
bitcrack convert key to address and check compare gen address and target address right?
reference this app
http://gobittest.appspot.com/Address
you can see we can convert address to roll back to RIPEMD-160
put address to box 9 - Base58 encoding of 8 and click send
web app will convert back to RIPEMD-160
idea it is just convert address to RIPEMD-160 and cut out work process to short
hope this method help to can scan bitcrack faster up to 30% (if 30% is process from RIPEMD-160 to address)
just idea please ignore
BitCrack is already transforming compressed and uncompressed BitCoin Addresses to RIPEMD-160 when loading the addresses. SegWit and MultiHash Addresses are not transformed and result in an invalid Argument Error in BitCrack. BitCrack is then putting the RIPEMD-160 hashes into a Bloom Filter and does not make a string based comparison. Because compressed and uncompressed RIPEMD-160 addresses are generated from the compressed or uncompressed EC-PubKey you can not optimize it at an earlier stage.
The only improvements/optimization you could do is:
- Implement SegWit and MultiHash-Addresses to RIPEMD-160 transformation.
- Implement a Public-Key only search (Write a Programm which searches the Blockchain for public-keys and modify BitCrack to use it as an input), then you could potentially speed up the process but keys without known pubKey will not be searched (tradeoff).
If you know the pubkey then just use Kangaroo program. No need to tweak anything in bitcrack. Kangaroo is much faster than a bitcrack sequential search. The only improvements/optimization you could do is:
- Implement SegWit and MultiHash-Addresses to RIPEMD-160 transformation.
- Implement a Public-Key only search (Write a Programm which searches the Blockchain for public-keys and modify BitCrack to use it as an input), then you could potentially speed up the process but keys without known pubKey will not be searched (tradeoff).
BitCrack is already transforming compressed and uncompressed BitCoin Addresses to RIPEMD-160 when loading the addresses. SegWit and MultiHash Addresses are not transformed and result in an invalid Argument Error in BitCrack. BitCrack is then putting the RIPEMD-160 hashes into a Bloom Filter and does not make a string based comparison. Because compressed and uncompressed RIPEMD-160 addresses are generated from the compressed or uncompressed EC-PubKey you can not optimize it at an earlier stage.
The only improvements/optimization you could do is:
- Implement SegWit and MultiHash-Addresses to RIPEMD-160 transformation.
- Implement a Public-Key only search (Write a Programm which searches the Blockchain for public-keys and modify BitCrack to use it as an input), then you could potentially speed up the process but keys without known pubKey will not be searched (tradeoff).
The only improvements/optimization you could do is:
- Implement SegWit and MultiHash-Addresses to RIPEMD-160 transformation.
- Implement a Public-Key only search (Write a Programm which searches the Blockchain for public-keys and modify BitCrack to use it as an input), then you could potentially speed up the process but keys without known pubKey will not be searched (tradeoff).
How long time for bitcrack calculate form RIPEMD-160 and double sha256 then Base58
if use long time
Can possible add function bitcrack to have option --ripemd for search as RIPEMD-160 replace address?
if time from private key to address using time 100%
and time from RIPEMD-160 to address using over 30%
if can search at RIPEMD-160 maybe help search key up to 30%
just idea
Anyway, there certainly is some issues with the openCL version as cuBitcrack found nearly 3 times as many keys in the same range.
I have joined the TTD pool anyway, I didn't realize there was one, better to share my hash and we all get something out of it.
I have joined the TTD pool anyway, I didn't realize there was one, better to share my hash and we all get something out of it.
openCL clBitcrack latest version 0.31 some person use have problem
try use release 0.30 it is no problem for every one
https://github.com/brichard19/BitCrack/releases/download/0.30/clBitCrack.exe
Anyway, there certainly is some issues with the openCL version as cuBitcrack found nearly 3 times as many keys in the same range.
I have joined the TTD pool anyway, I didn't realize there was one, better to share my hash and we all get something out of it.
I have joined the TTD pool anyway, I didn't realize there was one, better to share my hash and we all get something out of it.
No, the puzzle is between 2^63 and 2^64 BUT:
https://github.com/brichard19/BitCrack/issues/223
(uint64_t)_points * _threads * _blocks;
So instead of checking all keys you are basically ignoring alot of keys. If you have e.g. 512 blocks and 1024 threads (doesnt matter if those are valid inputs) you would basically jump over 512*1025 = 2^19 keys.
So thats why you are faster finished.
Yeah not sure where you get your info from. Bitcrack doesn't ignore keys. Unless you are speaking of a bug with the CL version, but the program does not skip/ignore keys unless you use the stride option, on purpose.https://github.com/brichard19/BitCrack/issues/223
(uint64_t)_points * _threads * _blocks;
So instead of checking all keys you are basically ignoring alot of keys. If you have e.g. 512 blocks and 1024 threads (doesnt matter if those are valid inputs) you would basically jump over 512*1025 = 2^19 keys.
So thats why you are faster finished.
Please reread what I wrote: The buggy line results in skipping keys.
If you assume that address has any correlation with private key (like alphabetical order or so), then you are wrong. Address is created from hash functions, which completely destroy any order or correlation. The fact that your example address comes from known private key means completely nothing and cannot be any proof or base to assume that other address is somewhere 'near'.
And what about this --16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN -
16jY7qLJnxLQQRYPX5BLuCtcBs6tvXz8BE - 3AD3536AEA8CEB2B0
16jY7qLJnx2EZZumnYFke3GutCrRnHKs1M - 7013536A91A6441B0
That is why I have a little hope that it might work I know hash function is totally different what I thought but for me it maybe a ray of hope in despair...
Maybe this fork is working for you
https://github.com/ZenulAbidin/BitCrack-3000
But you would need to compile it yourself. I am Linux-User, so I cant help you there with compiling it. THere is also a sp version precompiled for windows fork, it is somewhere linked. I did not save the link as it was uninteresting for me.
https://github.com/ZenulAbidin/BitCrack-3000
But you would need to compile it yourself. I am Linux-User, so I cant help you there with compiling it. THere is also a sp version precompiled for windows fork, it is somewhere linked. I did not save the link as it was uninteresting for me.
For faster speed on Windows use the fork by richieburns which has a compiled exe here:
https://github.com/richieburns/BitCrack_AMP/releases/download/v1.0.0_AMP/BitCrack_AMP.zip
Bitcrack CUDA 11.2 Compute 8.6 Win10
Would appreciate some benchmarks for RTX 30 series cards.....
Cheers
Bitcrack CUDA 11.2 Compute 8.6 Win10
Would appreciate some benchmarks for RTX 30 series cards.....
Cheers
sp-mod does not work with RTX 30xx as far as I know.
Already noticed a difference, similar speeds but scanned over double the number of keys in a single keyrange. It was scanning around 700,000,000,000 with clBitrack, currently on 1,481,528,836,096 and still going.id say that is now capturing the keys it was not before and makes sense that clBitCrack was not working correctly.
Tbh, If i would try to crack the puzzle I would fix the OpenCL Bug and implement the various optimizations from different forks of BitCrack. Then I would modify the code and instead of incrementing the key, i would decrement the key. I mean... there are alot of people scanning the whole 2^63 - 2^64 Range and they already scanned about 10-20% of it from the beginning already. So scanning it again makes no sense. But I did not see a modification of BitCrack which implements decrementing the keys.
Check: http://ttdsales.com/64bit/login.php
That project splits the work and sends the region to check. They will probably not tell you which parts were already checked, but at least they show the progress in subsets.
Instead of using random numbers i am using some logical numbers where i take only 8 character of keys and the other 8 are my computation.
https://imgur.com/Sd93EOt
for example: I chose address which starts from 16 and ends from QN something like this - addr : 16FhwWS4QRadRp77Tuwd1K4ofggQb9uRQN pvk : B2BDE4B3FF60553F here i take the 8 characters of key from beginning and the other 8 is my computation. --keyspace b2bde4b300000000:b2bde4b3ffffffff... hope this trick will do something or maybe not
https://imgur.com/Sd93EOt
for example: I chose address which starts from 16 and ends from QN something like this - addr : 16FhwWS4QRadRp77Tuwd1K4ofggQb9uRQN pvk : B2BDE4B3FF60553F here i take the 8 characters of key from beginning and the other 8 is my computation. --keyspace b2bde4b300000000:b2bde4b3ffffffff... hope this trick will do something or maybe not
If you assume that address has any correlation with private key (like alphabetical order or so), then you are wrong. Address is created from hash functions, which completely destroy any order or correlation. The fact that your example address comes from known private key means completely nothing and cannot be any proof or base to assume that other address is somewhere 'near'.
Instead of using random numbers i am using some logical numbers where i take only 8 character of keys and the other 8 are my computation.
https://imgur.com/Sd93EOt
for example: I chose address which starts from 16 and ends from QN something like this - addr : 16FhwWS4QRadRp77Tuwd1K4ofggQb9uRQN pvk : B2BDE4B3FF60553F here i take the 8 characters of key from beginning and the other 8 is my computation. --keyspace b2bde4b300000000:b2bde4b3ffffffff... hope this trick will do something or maybe not
today or tomorrow i will scan the whole range from a5a46bed to ffffffff and i am adding only 1 in begin numbers so those numbers are also running in sequence.
https://imgur.com/Sd93EOt
for example: I chose address which starts from 16 and ends from QN something like this - addr : 16FhwWS4QRadRp77Tuwd1K4ofggQb9uRQN pvk : B2BDE4B3FF60553F here i take the 8 characters of key from beginning and the other 8 is my computation. --keyspace b2bde4b300000000:b2bde4b3ffffffff... hope this trick will do something or maybe not
today or tomorrow i will scan the whole range from a5a46bed to ffffffff and i am adding only 1 in begin numbers so those numbers are also running in sequence.
Maybe this fork is working for you
https://github.com/ZenulAbidin/BitCrack-3000
But you would need to compile it yourself. I am Linux-User, so I cant help you there with compiling it. THere is also a sp version precompiled for windows fork, it is somewhere linked. I did not save the link as it was uninteresting for me.
https://github.com/ZenulAbidin/BitCrack-3000
But you would need to compile it yourself. I am Linux-User, so I cant help you there with compiling it. THere is also a sp version precompiled for windows fork, it is somewhere linked. I did not save the link as it was uninteresting for me.
For faster speed on Windows use the fork by richieburns which has a compiled exe here:
https://github.com/richieburns/BitCrack_AMP/releases/download/v1.0.0_AMP/BitCrack_AMP.zip
Bitcrack CUDA 11.2 Compute 8.6 Win10
Would appreciate some benchmarks for RTX 30 series cards.....
Cheers
Bitcrack CUDA 11.2 Compute 8.6 Win10
Would appreciate some benchmarks for RTX 30 series cards.....
Cheers
sp-mod does not work with RTX 30xx as far as I know.
Jump to: