Next update will get rid of the <bitrange> parameter and just generate random values in specified keyspace start:end if -r is specified.
This will also optimize key initializing hopefully so it will start faster.

Thanks! Fixed in current version.

"-r 61" will make all points start at a random offset in 61 bit range.
The 3 sample starting points are just for information/confirmation the correct range is used.

If your BitCrack is generating 37,748,736 starting points then each point starts at a random offset in 61 bit range.

It is easy to adjust the code now. Simply adjust in generateStartingPoints() function.

You can combine -r with --keyspace if you need to additional control.

Please "git pull" to get the latest version that also contains fixes.

Initial version for OpenCL only:

https://github.com/pikachunakapika/BitCrack

use -r <bitrange> to enable it. You will get 3 samples for starting points beeing used.

Please notice:
The total movement relative to each random starting point is defined by total processed keys / number of starting points.
E.g. if BitCrack generated 200,000 starting points and your total processed keys is 4,000,000. Each point moved by (only) 20 steps.
This is by original design and the only way to benefit from the huge parallel processing power of GPUs.

Tested OpenCL and Cuda with Nvidia Device on Linux.
Not tested on Windows. Please give feedback!

I am no youngling too but I like code. I can make adjustments to Cuda but have no experience with OpenCL yet so lets see.

K. You need OpenCL too, right?

You have to adjust the initial point generation, remove the first point doubling kernel and adjust the result reporting slightly.
Everything else can remain almost untouched and will not influence performance.

I like the idea of including randomness in the process. Because in the end you don't have to search any repeating patterns if consequently followed (0101, 1f1f).
It is possible in theory these patterns appear but very unlikely in practice.

I thought about ignoring ranges completely and just generate random starting offsets for each GPU working point. This would raise the factor of luck by a magnitude but make inclusion of deterministic methods harder.

That is a good idea. Feel free to post your keyspaces for us to check.

@Bajula, sure .

Very good! Good luck!
You have to be lucky²⁵⁶ to hit an address in 256 bit range.

In general you get the pubkeys from a transaction that has been sent from the target address (spent).

For puzzle key #60:
https://www.blockchain.com/btc/tx/6c08747ecd15904128c3f15f3bf47f6f365405da2661f17eb5119008807cee3e

ScriptSig: PUSHDATA(72)[3045022100b0d935af1a8b20186c2cd3e43dddb391d85acbfab890f025e683bc0da2534de702200b7816d64a59579da5328fbfd7ddd34b19ad864915fe2474338e53d04131257f01]
PUSHDATA(33)0348e843dc5b1bd246e6309b4924b81543d02b16c8083df973a89ce2c7eb89a10d

Compressed public key in red: 0348e843dc5b1bd246e6309b4924b81543d02b16c8083df973a89ce2c7eb89a10d

You can convert between compressed and uncompressed public key here:
https://iancoleman.io/bitcoin-key-compression/

But better use python and use bitcoin library. E.g.:


Just research little on your own from here.

Can you please check your performance with -u -c again please. I noticed you got 80Mkeys/s with compressed only.

[2019-02-22.19:47:44] [Info] Compression: compressed

Good speed increase if you only want to target the #61 puzzle address.

• Only -c
• Only one target: 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
• Make sure to use latest BitCrack version from github. There have been good speed improvements to the OpenCL version recently
• Check your settings. For Cuda I have better performance with more threads (~512) instead of high processes

GL HF

0x7496CBB87CAB44F