Rx480 has a limit ... You can't have -t higher than 256.
Oh ... it changes the form of things :-) well ... I wanted better :-)
---
Is there someone here who would be able to convert the counting number of scanned keys in BitCrack into a counter showing the number of REMOTE keys to be scanned along with the estimated remaining time to complete? It would be more interesting information than the amount that was scanned. Unfortunately, I do not know the programming language completely, and my knowledge ends at the stage of compiling a ready solution with possible code change in the sources. I would be grateful for such a small addition.
Please checkout the branch "remaining" at
https://github.com/pikachunakapika/BitCrack. It also includes my changes for random starting points. With -r you get no ETA and remaining count.
Hello all
i notice, this random called update just start with random starting points instead of series starting points
after 1st generates random starting points, each starting point start searching series,
Random should be every second each every string random
if you understand, its ok, if you need to understand more in details with example, feel free to ask
your random version of bitcrack working like
[2019-03-04.21:09:12] [Info] Starting point sample: 5B60A7D6CAC10CEF8FF0CD0F7D3D4D7E72265EA3564F3A7C4CEC060DD434BD5E (255 bit range)
[2019-03-04.21:09:12] [Info] Starting point sample: 507B5ACCB577F908D97155CD7A8F2827D7FF6752051D42D70AF33F6A80D4573F (255 bit range)
[2019-03-04.21:09:12] [Info] Starting point sample: 5C45836A0BFB1EAE9FE807030A511FAF5AE30E1708E6E9AC4CEEEEEF0D85883E (255 bit range)
each starting point key once random, next it starting working in series
starting point key : 5B60A7D6CAC10CEF8FF0CD0F7D3D4D7E72265EA3564F3A7C4CEC060DD434BD5E
next working : 5B60A7D6CAC10CEF8FF0CD0F7D3D4D7E72265EA3564F3A7C4CEC060DD434BD5f, ...60, ....61, .....62, ....63
starting point key : 507B5ACCB577F908D97155CD7A8F2827D7FF6752051D42D70AF33F6A80D4573F
next working : 507B5ACCB577F908D97155CD7A8F2827D7FF6752051D42D70AF33F6A80D4573F ,... 40, ... 41, ...42
each starting point working in series
what should be random, every second new starting point as random key should be in search pool
have you all tested pinka... BitCrack
?
have you seen this random style
You must precise your individual range to scan by --keyspace command (eg. start:end ) and add -r before all.
Try this:
cuBitCrack.exe -r 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB -c -o FOUND.txt --keyspace 01000000000000000:01FFFFFFFFFFFFFFF
... and you have random range only for #61 address
you did not follow
each starting point is random, onword from starting point series generating for process
example you searching from 100:1ff
7 starting point created, like 1 8 20 35 37 60 80
when process start
from 1 point to 8 close in sequence same 35 to 37 close , but all in sequence
first is starting point
1 2 3 4 5 6 7 8 9 10
8 9 10 11 12 13 14
20 21 22 23 24 25 26 27
in this sanrio, main brichard master branch is better continue sequence
Random should be not only starting point, after each next step should be random key for process
it does not work.
By firing "from scratch" on a clean script for the scope --keyspace 01000000000000000: 01FFFFFFFFFFFFFFF --share 41/160, the estimated time is 1.75 months. Using the --continue file which contains the starting point at half of what I initially set (just: in a situation where 50% of the range has already been scanned) - the counter gives 1.75 months. This is not something here .... since I've scanned 50% ... it can not be that it will take as long as it will last as if I started scanning from now on again
The -r option can not be used because it does not work with "- -continue "and not using this option at this level is probably a waste of time.
Thanks! Fixed respecting the --continue file. Working on the changes for --continue with -r option now.
All changes are in the master branch now and the remaining branch has been removed.
how use this
https://github.com/pikachunakapika/BitCrack need exe file
Stalker i compile for You executable versions of last release by Pikachanapika. You can get them from my repo:
https://github.com/ZielarSRC/BitCrack/releases/tag/v0.30./clBitCrack -d 1 -b 72 -t 256 -p 1024 --keyspace 1ABBCE2000000000:1ABBCE3000000000 -o res61.txt 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
[2019-03-04.19:49:36] [Info] Compression: compressed
[2019-03-04.19:49:36] [Info] Starting at: 0000000000000000000000000000000000000000000000001ABBCE2000000000
[2019-03-04.19:49:36] [Info] Ending at: 0000000000000000000000000000000000000000000000001ABBCE3000000000
[2019-03-04.19:49:36] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2019-03-04.19:49:36] [Info] Compiling OpenCL kernels...
[2019-03-04.19:49:43] [Info] Initializing Ellesmere
[2019-03-04.19:49:45] [Info] Generating 18,874,368 starting points (720.0MB)
[2019-03-04.19:49:49] [Info] 10.0%
[2019-03-04.19:49:51] [Info] 20.0%
[2019-03-04.19:49:52] [Info] 30.0%
[2019-03-04.19:49:52] [Info] 40.0%
[2019-03-04.19:49:53] [Info] 50.0%
[2019-03-04.19:49:53] [Info] 60.0%
[2019-03-04.19:49:53] [Info] 70.0%
[2019-03-04.19:49:54] [Info] 80.0%
[2019-03-04.19:49:54] [Info] 90.0%
[2019-03-04.19:49:55] [Info] 100.0%
[2019-03-04.19:49:55] [Info] Done
[00:02:06] 1152/7536MB | 1 target 109.79 MKey/s (0000000FB6800000 remaining) [ETA 10.23 minutes]
This does not work ETA stays 10min for too long. And the "remaining" never goes below 0000000F
00000000 ...
I think that you may have a declaration problem, your "remaining" integer may have been declared as a 32bit integer.
Lol.
I would leave it without comment, but I MUST (...):
The original version works in the same way (builds starting points [different] within the given range)... The difference is that you CAN NOT see it in it. In the "pikachunakapika" version this information is shown and this is not a reason to deny its contribution to development. I also mention that the option "-r" which is responsible for the randomness of a given interval is not imposed on the user, so it is simply an option for people who want to try this way ... I would even say that it is reasonable for the majority, because the original version is probably not the chances of scanning the amount I have already scanned (to get the key sooner).
I confirm after almost an hour of testing the current version of Pika that it works properly and is stable. I also agree with my readouts in the checkpoint files, so I can confirm that the progress is correct and scans in the correct order.
@pikachunakapika - to the suggestion regarding the format of presenting the remaining time, I still have a suggestion regarding the PRESENCE of the remaining keys, namely that it should be shown in the form DEC and not HEX.
@racminer - I will check it out on cuBitCrack or if the problem is the same. Nevertheless, even if so I think that ten minutes of incompatibility at this stage can be regarded as a tolerance threshold with a slight breath
