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?
Topic: BitCrack - A tool for brute-forcing private keys - page 36. (Read 76850 times)
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.
Quote
Not disagreeing with you, but the hex ranges I showed above are correct right? Why would clBitcrack state "[Info] Reached end of keyspace" unless there is some bug or those are not the correct ranges. maybe I missed a 0 or two?
Appreciate the explanation.
edit: I see 2^64 = 18,446,744,073,709,551,616 in decimal. Whereas the difference between the two hex ranges is 9,223,372,036,854,775,808 so I am guessing the 64 bit range that the puzzle is in is anywhere from 2^1 -> 2^64? Whereas I have just scanned 2^63 -> 2^64 which is just a single segment of the whole range?
I reread post.Appreciate the explanation.
edit: I see 2^64 = 18,446,744,073,709,551,616 in decimal. Whereas the difference between the two hex ranges is 9,223,372,036,854,775,808 so I am guessing the 64 bit range that the puzzle is in is anywhere from 2^1 -> 2^64? Whereas I have just scanned 2^63 -> 2^64 which is just a single segment of the whole range?
Here is the math for a GPU getting 1100 MKey/s
Per day: 1100000000*60*60*24 = 95040000000000 keys checked in one day
Total keys in range: 9223372036854775807
Days needed to scan range: 9223372036854775807 / 95040000000000 = 97,047 days
If you are using cl, there were known issues. But the math is simple on how much time it would take to scan the entire #64 range. And no, bitcrack isn't designed to skip/ignore keys unless you use the --stride option.
Quote
So scanning it again makes no sense. But I did not see a modification of BitCrack which implements decrementing the keys. So you would have a better chance to find the solution if you begin from the middle and increment the key or from the end and decrementing the key. Picking some random ranges in the big range as some people mentioned gives imho no actual benefit. In contrary: The Key could be in any subrange. And if you do it randomly, you would have to store the information which ranges you already scanned in your statusfile (--continue FILENAME). This file would just consume more of your VRAM and depending on the amount of subranges could reduce your speed.
How long have you used bitcrack or actually scanned ranges with it?
It is simple to track the subranges checked. Nothing to do with vram; when you run a random range, you save that range to a text file. Then you can sort it after a period and see which ranges you have checked. Or you could use one of the programs that tracks it for you. The program breaks the 64 bit range into however many subranges you want and then assigns a subrange and keeps track of what you have checked. Or one could use a simple python script to generate random ranges and print ranges checked to a file.
Random or sequential, doesn't matter how you use bitcrack as long as you keep track of random ranges searched.
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.
If you take care of the chunking I guess it will work fine.
I think if you combine following Forks you get a good head start
ByLamacq has implemented the Vectorization Patch
https://github.com/ByLamacq/BitCrack/commits/master
BoGnY and his OpenCL Fix
https://github.com/BoGnY/BitCrack/commits/master
Fishpeppers Base58 Patch
https://github.com/fishpepper/BitCrack/commit/af2aa3e2df798453338b71f619f2596620a600a5
And you would just have to apply the changes manually without knowing that much of c++.
I think if you combine following Forks you get a good head start
ByLamacq has implemented the Vectorization Patch
https://github.com/ByLamacq/BitCrack/commits/master
BoGnY and his OpenCL Fix
https://github.com/BoGnY/BitCrack/commits/master
Fishpeppers Base58 Patch
https://github.com/fishpepper/BitCrack/commit/af2aa3e2df798453338b71f619f2596620a600a5
And you would just have to apply the changes manually without knowing that much of c++.
Thank You, I will take a look.
If you take care of the chunking I guess it will work fine.
I think if you combine following Forks you get a good head start
ByLamacq has implemented the Vectorization Patch
https://github.com/ByLamacq/BitCrack/commits/master
BoGnY and his OpenCL Fix
https://github.com/BoGnY/BitCrack/commits/master
Fishpeppers Base58 Patch
https://github.com/fishpepper/BitCrack/commit/af2aa3e2df798453338b71f619f2596620a600a5
And you would just have to apply the changes manually without knowing that much of c++.
I think if you combine following Forks you get a good head start
ByLamacq has implemented the Vectorization Patch
https://github.com/ByLamacq/BitCrack/commits/master
BoGnY and his OpenCL Fix
https://github.com/BoGnY/BitCrack/commits/master
Fishpeppers Base58 Patch
https://github.com/fishpepper/BitCrack/commit/af2aa3e2df798453338b71f619f2596620a600a5
And you would just have to apply the changes manually without knowing that much of c++.
Jump to: