BitCrack - A tool for brute-forcing private keys

[sp_]

For the #39, it took the 1060 6GB card exactly 44 seconds to find the key.  Start to finish = 44 seconds, with 1 card. Grid size of 3072x512.
sp, is 44 seconds good on an old 1060 card?

No it is slow. should run under 100ms. You can retrieve the precalculated keys from https://privatekeys.pw/ . Since the answer to the puzzle is already known and can be precalculated.

Back to the speed of my bitcrack implementation.

puzzle 39:  2^39  = 549 755 813 888 possible combinations

with a speed of 400 000 000 (400MKeys)

puzzle #38: 274 877 906 944 / 400 000 000 = 1374 seconds (around 12minutes)
puzzle #39: 549 755 813 888 / 400 000 000 = 1374 seconds (around 23minutes)

With 400mkeys and solving puzzle 39 You would expect the program to spend 12-23 minutes. The hashes used to find the solution is printed in the miner window and the speed can easily be verified. Bitcrack sp-mod is working. I see that my fanclub is present already. I welcome you all. Go crack some keys.
The next version will come with more speed.

[1715220638]

1715220638

[1715220638]

1715220638

[1715220638]

1715220638

[renedx]

For the #39, it took the 1060 6GB card exactly 44 seconds to find the key.  Start to finish = 44 seconds, with 1 card. Grid size of 3072x512.
sp, is 44 seconds good on an old 1060 card?

No it is slow. should run under 100ms. You can retrieve the precalculated keys from https://privatekeys.pw/ . Since the answer to the puzzle is already known and can be precalculated.

Back to the speed of my bitcrack implementation.

puzzle 39:  2^39  = 549 755 813 888 possible combinations

with a speed of 400 000 000 (400MKeys)

puzzle #38: 274 877 906 944 / 400 000 000 = 1374 seconds (around 12minutes)
puzzle #39: 549 755 813 888 / 400 000 000 = 1374 seconds (around 23minutes)

With 400mkeys and solving puzzle 39 You would expect the program to spend 12-23 minutes. The hashes used to find the solution is printed in the miner window and the speed can easily be verified. Bitcrack sp-mod is working. I see that my fanclub is present already. I welcome you all. Go crack some keys.
The next version will come with more speed.

Fan club present? Are you referring to the program and you’re able to see who’s running it?

All these questions, I rather compile from source.

[gsciservices]

@fxsniper

Here is how my random "BitCrack" works. I call it Randomonium or VanBitKraken (since it is based off of VanitySearch and BitCrack). It can regenerate random points every so many keys based off of user input or user can decide to just let the program create random points throughout a range and search sequentially from each point generated.
With the flags/setup you see below, I am telling the program to search for 1Be2U address, generate new random points every 1600 Mkeys checked. I am also tell the program to search in the 36 bit range (900000000) via the boomT flag and setting the bits via the bitz flag to 32. So all random points will start with a 9 and random 32 bits, as evident by the keys below. I have it to stop once it finds the key, that's why the program stopped. Just a small sample size to show you how it works. I know there are some versions of BitCrack out there that have a random feature but I do not know which ones work. I think BitCrack generates x amount of points (based off of your -b -t -p settings) and spreads those points over the range you have identified in the --keyspace flag, but I could be wrong.

Code:

C:\Users\your\Documents\BitRangeFinderWithRandomonium>RandomoniumV1 -t 0 -r 1600 -stop -gpu -gpuId 0 -bitz 32 -boomT 900000000 -o FoundKeysWithRandomonium.txt 1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1
Rando-monium
Searching For: 1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1 [Compressed]
Started at Wed Feb 24 18:41:55 2021
CPU Threads Used: 0
GPU: GPU #0 GeForce GTX 1060 6GB (10x128 cores) Grid(80x128)

Key 0: 90FB029C9
Key 1: 915AB8BEF
Key 2: 94566471B
Key 3: 9B32AD4C5
Key 10236: 916FC7D4F
Key 10237: 9941AA5CC
Key 10238: 9CA0313F6
Key 10239: 9CD679F6E
Key 0: 971B253A7
Key 1: 9747E23CC
Key 2: 97155A495
Key 3: 95ADB5819
Key 10236: 94C80D1C1
Key 10237: 9718F18A5
Key 10238: 9733219BB
[424.30 Mkey/s][GPU 424.30 Mkey/s][Total 2^30.66][Prob 0.0%][50% in 7.5709e+31y][Found 0]
Key 0: 975D40E2C
Key 1: 94693B865
Key 2: 9CB0359C2
Key 3: 9A7E99691
Key 10236: 997802E90
Key 10237: 9C4F7F057
Key 10238: 9A619E828
[402.27 Mkey/s][GPU 402.27 Mkey/s][Total 2^31.91][Prob 0.0%][50% in 7.98551e+31y][Found 0]
Key 0: 94824A22E
Key 1: 98D8DF9B2
Key 2: 95FF97060
Key 3: 90D7649EB
Key 10236: 99728C9A7
Key 10237: 942FC0681
Key 10238: 9B6305716
[396.73 Mkey/s][GPU 396.73 Mkey/s][Total 2^32.57][Prob 0.0%][50% in 8.09702e+31y][Found 0]
Key 0: 9502B7D4F
Key 1: 9A50EB31E
Key 2: 9137FF051
Key 3: 98459EFC4
Key 10236: 9A4E0E1A3
Key 10237: 955C27269
Key 10238: 9344F13EE
[396.68 Mkey/s][GPU 396.68 Mkey/s][Total 2^33.03][Prob 0.0%][50% in 8.0979e+31y][Found 0]
Key 0: 90713B8A5
Key 1: 95F65F231
Key 2: 96C034F9B
Key 3: 9D5E97324
Key 10236: 9099689AA
Key 10237: 9673E3AB2
Key 10238: 9E37BEC45
[392.72 Mkey/s][GPU 392.72 Mkey/s][Total 2^33.37][Prob 0.0%][50% in 8.17973e+31y][Found 0]
Key 0: 98ECC53D8
Key 1: 98D4A705E
Key 2: 9EE3F71FB
Key 3: 9FCDC5825
Key 10236: 91581FDF1
Key 10237: 96B2A59CF
Key 10238: 9DA85DB2D
[392.74 Mkey/s][GPU 392.74 Mkey/s][Total 2^33.64][Prob 0.0%][50% in 8.1792e+31y][Found 0]
Key 0: 9524454BC
Key 1: 911B85D89
Key 2: 964F741BA
Key 3: 9AA26E965
Key 10236: 93D1494B2
Key 10237: 9680AC923
Key 10238: 9FAFE8130
[392.75 Mkey/s][GPU 392.75 Mkey/s][Total 2^33.87][Prob 0.0%][50% in 8.17905e+31y][Found 0]
Key 0: 997B54EDC
Key 1: 999C24D45
Key 2: 9A1DBE828
Key 3: 9C151CB30
Key 10236: 95EF8F151
Key 10237: 9C899397C
Key 10238: 9A032F0C9
[392.80 Mkey/s][GPU 392.80 Mkey/s][Total 2^34.07][Prob 0.0%][50% in 8.17792e+31y][Found 0]
Key 0: 9E1CD4F93
Key 1: 999311CD2
Key 2: 92FFE0C75
Key 3: 917BB7886
Key 10236: 951B19828
Key 10237: 908EAA926
Key 10238: 9C6AEA820
Key 10239: 9AE046F3E
C:\Users\your\Documents\BitRangeFinderWithRandomonium>pause
Press any key to continue . . .

Randomonium or VanBitKraken is available; please share to us...

[WanderingPhilospher]

For the #39, it took the 1060 6GB card exactly 44 seconds to find the key.  Start to finish = 44 seconds, with 1 card. Grid size of 3072x512.
sp, is 44 seconds good on an old 1060 card?

No it is slow. should run under 100ms. You can retrieve the precalculated keys from https://privatekeys.pw/ . Since the answer to the puzzle is already known and can be precalculated.

Back to the speed of my bitcrack implementation.

puzzle 39:  2^39  = 549 755 813 888 possible combinations

with a speed of 400 000 000 (400MKeys)

puzzle #38: 274 877 906 944 / 400 000 000 = 1374 seconds (around 12minutes)
puzzle #39: 549 755 813 888 / 400 000 000 = 1374 seconds (around 23minutes)

With 400mkeys and solving puzzle 39 You would expect the program to spend 12-23 minutes. The hashes used to find the solution is printed in the miner window and the speed can easily be verified. Bitcrack sp-mod is working. I see that my fanclub is present already. I welcome you all. Go crack some keys.
The next version will come with more speed.

It is slow? Yet my program found the key in 44 seconds but yours took around 10 minutes? 
So you are telling everyone how fast your mod is but it takes your mod over 10 times longer to find the same key, with a better GPU than the one I am using?

My GPU only gets 113 MKey/s and still found the key to #39 in under a minute. But that is slow? But your mod takes 23 minutes and it's fast? 

[sp_]

It is slow? Yet my program found the key in 44 seconds but yours took around 10 minutes?  

I have a program that find the key in 1ms. It is written in sql. Local database. Here is the sourcecode. It is OpenSource:

select privatekey from compressed_bitcoinadresses where adress="122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8";

So you are telling everyone how fast your mod is but it takes your mod over 10 times longer to find the same key, with a better GPU than the one I am using?

I just showed you my 1ms opensource program (puzzle #39). You can show me yours and we can compare them.

[WanderingPhilospher]

It is slow? Yet my program found the key in 44 seconds but yours took around 10 minutes?  

I have a program that find the key in 1ms. It is written in sql. Local database. Here is the sourcecode. It is OpenSource:

select privatekey from compressed_bitcoinadresses where adress="122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8";

So you are telling everyone how fast your mod is but it takes your mod over 10 times longer to find the same key, with a better GPU than the one I am using?

I just showed you my 1ms opensource program (puzzle #39). You can show me yours and we can compare them.

Man get outta here. Precomputed keys in a database is not the same as bitcrack or vanbitcracken.

Your bitcrack mod found #39 in 9+ minutes, my vanbitcracken found it in 44 seconds. That's what we are comparing, two key searching programs utilizing GPUs. Not some database.

You are announcing all these speeds to the community regarding your bitcrack mod, when I run similar tests, with my program or the original bitcrack, there is no gain/minimal gain in TIME finding keys, regardless of how fast you say or how many MKey/s your mod is getting.

[sp_]

Man get outta here. Precomputed keys in a database is not the same as vanbitcracken.

No binary, no sourcecode how can we tell the difference? How do we know that vanbitcracken doesn't use a sql database?

[WanderingPhilospher]

Man get outta here. Precomputed keys in a database is not the same as vanbitcracken.

No binary, no sourcecode how can we tell the difference? How do we know that vanbitcracken doesn't use a sql database?

Haha...if vanbitcracken were using a database then yes, it is truly slow! I gave reasons not to release binary. But you can say what you want, it's a legit program using the code of VanitySearch. Regardless, if you believe me or not, when I ran the original bitcrack program (which is opensource and what your mod is based off of) there was no gain in TIME that it took to find the keys. Like I said earlier, post all the outrageous MKey/s you want to, I'm all about the TIME, because I do not know what's in your code. You could merely be buffering and padding MKey/s which will not increase the actual TIME it takes to find a key...

Vanbitcracken uses/generates random points through a range. I said this long ago...in smaller ranges (up to around 44 bits), random is faster, in my tests. It uses the power of the rekey function to dictate how often random points are regenerated.  So it can either generate/spread out random points and sequentially start from each random point or regenerate random points every x seconds/keys.  AND, it can utilize multiple GPUs!

Bottom line, vanbitcracken using one GTX 1060 card, kicked your GTX 1070Ti and sp mod's a$$...period.

[sp_]

(up to around 44 bits), random is faster, in my tests.

Up to around 44 bits database is faster. The point is that why do you care about the speed in low bit problems? 2^64 and up is more interesting. My mod is based on bitcrack and yes it is scanning bruteforcing all of the solutions. That might be a littlebit stupid, but stupid solutions can still solve problems with enough hashing power. My fork has a random mode. Run with -r --random.

[WanderingPhilospher]

(up to around 44 bits), random is faster, in my tests.

Up to around 44 bits database is faster. The point is that why do you care about the speed in low bit problems? 2^64 and up is more interesting. My mod is based on bitcrack and yes it is scanning bruteforcing all of the solutions. That might be a littlebit stupid, but stupid solutions can still solve problems with enough hashing power. My fork has a random mode. Run with -r --random.

See, here you go again. You posted results of 34 bit and a 39 bit. I was merely following your lead and comparing programs.

So you have a database that has 17,592,186,044,416 keys in it? Why? And you say it is faster but how long does it take to compute and store 17,592,186,044,416 private keys?

And I don't care about speed at all; I care about results...in time.

[sp_]

And I don't care about speed at all; I care about results...in time.

But still no binary or sourcecode to look at.. Show me some code, and we can talk again.

[WanderingPhilospher]

And I don't care about speed at all; I care about results...in time.

But still no binary or sourcecode to look at.. Show me some code, and we can talk again.

Ditto...show us the code. Or at least stop posting speed claims that don't result in speed up of search time. Fair enough?

[Robert_BIT]

My fork has a random mode. Run with -r --random.

sp_ is it normal to take A LOT longer when using -r?

Code:

Bitcrack sp-mod #4 (https://github.com/sp-hash)


[2021-03-25.17:48:08] [Info] Compression: compressed
[2021-03-25.17:48:08] [Info] Starting at: 0000000000000000000000000000000000000000000000000000004000000000
[2021-03-25.17:48:08] [Info] Ending at:   0000000000000000000000000000000000000000000000000000007FFFFFFFFF
[2021-03-25.17:48:08] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2021-03-25.17:48:08] [Info] Initializing Tesla V100-SXM2-16GB
[2021-03-25.17:48:09] [Info] Generating 114,688,000 starting points (4375.0MB)
[2021-03-25.17:48:31] [Info] 10.0%
[2021-03-25.17:48:31] [Info] 20.0%
[2021-03-25.17:48:31] [Info] 30.0%
[2021-03-25.17:48:31] [Info] 40.0%
[2021-03-25.17:48:32] [Info] 50.0%
[2021-03-25.17:48:32] [Info] 60.0%
[2021-03-25.17:48:32] [Info] 70.0%
[2021-03-25.17:48:32] [Info] 80.0%
[2021-03-25.17:48:33] [Info] 90.0%
[2021-03-25.17:48:33] [Info] 100.0%
[2021-03-25.17:48:33] [Info] Done
Tesla V100-SXM2- 10825 / 16258MB | 1 target 1568.49 MKey/s (48,857,088,000 total) [00:00:29][2021-03-25.17:49:04] [Info] Address:     122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8
                             Private key: 0000000000000000000000000000000000000000000000000000004B5F8303E9
                             Compressed:  yes
                             Public key:
                             022D77CD1467019A6BF28F7375D0949CE30E6B5815C2758B98A74C2700BC006543

[2021-03-25.17:49:04] [Info] No targets remaining
Execution time = 56 seconds

Same key 39 bit range with -r took 361 seconds 

Code:

Bitcrack sp-mod #4 (https://github.com/sp-hash)


[2021-03-25.17:49:18] [Info] Compression: compressed
[2021-03-25.17:49:18] [Info] Starting at: 0000000000000000000000000000000000000000000000000000004000000000
[2021-03-25.17:49:18] [Info] Ending at:   0000000000000000000000000000000000000000000000000000007FFFFFFFFF
[2021-03-25.17:49:18] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2021-03-25.17:49:18] [Info] Generating random starting points
[2021-03-25.17:49:18] [Info] Initializing Tesla V100-SXM2-16GB
[2021-03-25.17:49:18] [Info] Generating 114,688,000 starting points (4375.0MB)
[2021-03-25.17:49:18] [Info] Starting point sample: 0000000000000000000000000000000000000000000000000000007ADA607C21 (39 bit range)
[2021-03-25.17:49:18] [Info] Starting point sample: 0000000000000000000000000000000000000000000000000000004E0381CEB0 (39 bit range)
[2021-03-25.17:49:18] [Info] Starting point sample: 0000000000000000000000000000000000000000000000000000007EBDC9D53C (39 bit range)
[2021-03-25.17:50:07] [Info] 10.0%
[2021-03-25.17:50:09] [Info] 20.0%
[2021-03-25.17:50:09] [Info] 30.0%
[2021-03-25.17:50:10] [Info] 40.0%
[2021-03-25.17:50:10] [Info] 50.0%
[2021-03-25.17:50:10] [Info] 60.0%
[2021-03-25.17:50:10] [Info] 70.0%
[2021-03-25.17:50:11] [Info] 80.0%
[2021-03-25.17:50:11] [Info] 90.0%
[2021-03-25.17:50:11] [Info] 100.0%
[2021-03-25.17:50:11] [Info] Done
Tesla V100-SXM2- 10825 / 16258MB | 1 target 1554.88 MKey/s (387,072,000,000 total) [00:04:05][2021-03-25.17:55:19] [Info] Address:     122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8
                             Private key: 0000000000000000000000000000000000000000000000000000004B5F8303E9
                             Compressed:  yes
                             Public key:
                             022D77CD1467019A6BF28F7375D0949CE30E6B5815C2758B98A74C2700BC006543

[2021-03-25.17:55:19] [Info] No targets remaining
Execution time = 361 seconds

[sp_]

sp_ is it normal to take A LOT longer when using -r?

puzzle #39:
cuBitCrack.exe --keyspace 4000000000:7fffffffff 1EeAxcprB2PpCnr34VfZdFrkUWuxyiNE
           
Will scan search for a private key between 2 numbers:

 274 877 906 944
 549 755 813 887

Without the -r parameter the scan is performed linary like a counter  274 877 906 944,  274 877 906 945...

The solution key is

323 724 968 937

Bitcrack will check 48 847 061 993 seeds
with -r Bitcrack will faster if the private key is above  274 877 906 944 + (549 755 813 887- 274 877 906 944)/2

[Robert_BIT]

OK, thanks.

So for key #64 it will be less productive to use random I guess...

[sp_]

if the private key is close to 2^65 random is faster, if it is closer to 2^64 linear is faster. given that you start the scan at 2^64.

Random will also increase the probabilty that the number interval hasn't been scanned by others.

The random code is based on:

https://github.com/BoGnY/BitCrack/commit/7cd546f3f965b4be51d6beb237e5b3640f75678f

With a few bugfixes.

[NotATether]

It is OpenSource:

select privatekey from compressed_bitcoinadresses where adress="122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8";

This is getting ridiculous.

The above is not open source, because the tables and databases are not public. Actually there's no point debating this because everybody knows DBs can't do the cracking themselves. I hope you're not implying that we should download a bunch of random listings from allprivatekeys into a DB because at this point it almost sounds like you're trolling us.

I decided after my contracted Kangaroo work is done (it's almost complete) I'm going to make a better Bitcrack. No point in me holding the source also or instead of trying to solve puzzles we spend ~3 pages of threads arguing about source code distribution.


@renedx, since you're also working on this bug:

I think that one of these variables in CudaKeySearchDevice.cu is guilty of the misaligned access:

Code:

__constant__ unsigned int _INC_X[8];

__constant__ unsigned int _INC_Y[8];

__constant__ unsigned int *_CHAIN[1];

Notice how they are all __constant__. When I inspected the PTX a few pages back, the faulty instruction was accessing some array at element [0xc].

I find it hard to believe that _CHAIN has an element that can be accessed at that location (it's just a one-element array, already 64-bits aligned anyway since it's a pointer) so my guess it's both INC_X and INC_Y being accessed at [3].

These same two variables are passed to BeginBatchAddWithDouble() and I could not access the memory of the first two parameters which they were passed in, which gives this guess credibility.

Removing the __constant__ qualifier and forcing its allocation on device memory would be the quickest solution IMO.

[WanderingPhilospher]

I decided after my contracted Kangaroo work is done (it's almost complete) I'm going to make a better Bitcrack. No point in me holding the source also or instead of trying to solve puzzles we spend ~3 pages of threads arguing about source code distribution.

Just curious, why bitcrack?  If you want to improve upon anything, I would suggest to look at VanitySearch. It already handles multi GPU and is faster. The issue is reading full address, but works with partial/strings. It already does what bitcrack does, and faster, just full address issue.

Just a question.

[renedx]

@NotATether

Noted, I still remember these cons as something I was debugging dead on. I’m really a data-driven debugger, without memory access and lack of in-depth knowledge of CUDA, data is the only way I would be able to track logic.

I remember we at the end modified the CUDA bocks and thread params to be 1/1 (per your idea) and ran into instant crashes when it finished the first loop. When we modified the code a little bit (e.g. safe wrapping unsigned) the problems would move “up”. I remember us checking / suspecting the blockId / blockDim / threadId parts, as we noticed these were jumping instead of incrementing. The code was different versus what normally would happen in the kernel part.

Will try to find in discord what I’ve been sharing, its already a month ago I guess, as I cannot exactly remember anymore. 3:30 here, so I’ll take a look tomorrow maybe something I’ll hit that helps anyone along too.

I decided after my contracted Kangaroo work is done (it's almost complete) I'm going to make a better Bitcrack. No point in me holding the source also or instead of trying to solve puzzles we spend ~3 pages of threads arguing about source code distribution.

Just curious, why bitcrack?  If you want to improve upon anything, I would suggest to look at VanitySearch. It already handles multi GPU and is faster. The issue is reading full address, but works with partial/strings. It already does what bitcrack does, and faster, just full address issue.

Just a question.

Personally tried, but same problem with bitcrack, debugging without memory access makes this a really difficult one. I personally found the bitcrack code easier to understand & follow, the vanity one makes me feel like I’m trying to debug professor code. But that’s just personal taste. Besides bitcrack has already built in keyspacing, but vanity can be modified to do so if needed.

I’m kinda convinced if we would be able to *understand* what makes ampere cards crash on bitcrack, you could prob. fix vanity too.

In general I guess the more people get a hand on 30XX cards, the more people will join, help and share. After that, we can (semi-)easily do things like make multi GPU work and stuff, as it doesn’t require CUDA knowledge at depth, but feels kinda useless to do that know. At least from my personal energy point.

[fxsniper]

I decided after my contracted Kangaroo work is done (it's almost complete) I'm going to make a better Bitcrack. No point in me holding the source also or instead of trying to solve puzzles we spend ~3 pages of threads arguing about source code distribution.
 

Can you work on KangarooCrack?
BitCrack with Kangaroo Algorithm

I know bitcrack scan from 12345...99.100 every key continue, if not may be not call bitcrack (like bitcrack random version)
I think bitcrack should be spit out to mufti version

main road
bitcrack original
bitcrack original GPU CUDA
bitcrack original GPU OpenCL
bitcrack modify performance
bitcrack modify new GPU card series support

crazy bitcrack mutant idea
mutant may be can not cal it is a bitcrack anymore

mutant line#1  algorithm
bitcrack random  (random)
bitcrack kangaroo (using Pollard kangaroo algorithm scan)
bitcrack BSGS (use Baby-Step-Giant-Step)
bitcrack fibonacci sequence/retracement

mutant line#2
bitcrack public point  (same gen prikey first)
bitcrack public key  (same gen prikey first)
bitcrack RIPEMD160  (same gen prikey first)
bitcrack WIF (random WIF and convert to privatekey)
bitcrack ECDSA  (multiply with ECDSA)
bitcrack hex (random private key at hex)
bitcrack decimal (random private key at decimal)
bitcrack binary (random private key at binary)
bitcrack byte (byte and binary is same or not)
bitcrack sha256 (N sha time)
bitcrack base58

mutant line#3 strategy
bitcrack pool  (easy to create pool just point to ip)
bitcrack slot   (split to slot and remember used/scan already to save file random slot scan)
bitcrack lotto  (make pool and get win as lotto method)

mutant line#4 Q
bitcrack Qiskit  (code on Qiskit  language)


bitcrack launcher (launcher by strategy open bitcrack to work)
launcher slot (random slot search and remember slot scan/already use slot)
bitcrack SAVE FILE (save generate to file csv)

Why bitcrack because bitcrack faster than python code 10x and bitcrack use GPU

sorry just and Variety idea
don't serious may be name help to creative way/method to crack success
just idea post please ignore
may be have a lot of bad idea