Pages:
Author

Topic: BitCrack - A tool for brute-forcing private keys - page 48. (Read 74618 times)

sp_
legendary
Activity: 2912
Merit: 1087
Team Black developer
sp-mod #5 has been released

https://github.com/sp-hash/Bitcrack/releases/tag/sp-mod5

-Fixed out of memory error on highend gpu's
-Faster hashing
-2nd. try to fix rtx cards compability

gtx 1080ti: 705 Mkeys
gtx titanx pascal 685 Mkeys
gtx 1070ti: 488 Mkeys
gtx 10603gb 366Mkeys

Solve puzzle 64 (0.64BTC):
cuBitCrack.exe -r --keyspace 8000000000000000:ffffffffffffffff 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQNQ

full member
Activity: 1078
Merit: 219
Shooters Shoot...
Did some tinkering.

Latest results of VBC (from earlier comparison test):

Code:
VanBitCracken v1.1a
Keyspace start=100000000
Keyspace   end=1FFFFFFFF
Search: 9 addresses (Lookup size 9,[1,1]) [Compressed]
Start at Fri Mar 26 03:07:30 2021
CPU threads used: 0
GPU: GPU #0 GeForce GTX 1060 6GB (10x128 cores) Grid(80x512)
165.542 MK/s (GPU 165.542 MK/s) (2^31.80) [00:00:22 Elapsed Time][9]
Finish at Fri Mar 26 03:07:54 2021

C:\Users\your\Documents\VanSearch>pause
Press any key to continue . . .


Finished test in 24 seconds.  Reduced overall search from 33 seconds to 24 seconds.

Compared to original bitcrack, this program is now 50% faster!
Original bitcrack did the search in 48 seconds, VBC in 24 seconds.
newbie
Activity: 2
Merit: 0
also during compile on VS 2017 i am getting there warnings

4>The system cannot find the file specified.
4>Error occurred while processing: ripemd160.cl.
4>The system cannot find the file specified.
4>Error occurred while processing: secp256k1.cl.
4>The system cannot find the file specified.
4>Error occurred while processing: sha256.cl.
4>
newbie
Activity: 2
Merit: 0
guys help
i am compiling but after successful i am getting this error
HW : RTX 3080 , OPENCL Nvidia 9.2 cuda , Visual studio 2017 ,

[2021-03-26.13:46:51] [Info] Compression: compressed
[2021-03-26.13:46:51] [Info] Starting at: 0000000000000000000000000000000000000000000000000000000000000001
[2021-03-26.13:46:51] [Info] Ending at:   FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
[2021-03-26.13:46:51] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2021-03-26.13:46:52] [Info] Compiling OpenCL kernels...
[2021-03-26.13:46:52] [Info] Error: :51:5: error: use of undeclared identifier 'uint64_t'
                                 uint64_t idx[5];
                                 ^
                             :53:5: error: use of undeclared identifier 'idx'
                                 idx[0] = ((hash[0] << 6) | (h5 & 0x3f)) & mask;
                                 ^
                             :54:5: error: use of undeclared identifier 'idx'
                                 idx[1] = ((hash[1] << 6) | ((h5 >> 6) & 0x3f)) & mask;
                                 ^
                             :55:5: error: use of undeclared identifier 'idx'
                                 idx[2] = ((hash[2] << 6) | ((h5 >> 12) & 0x3f)) & mask;
                                 ^
                             :56:5: error: use of undeclared identifier 'idx'
                                 idx[3] = ((hash[3] << 6) | ((h5 >> 18) & 0x3f)) & mask;
                                 ^
                             :57:5: error: use of undeclared identifier 'idx'
                                 idx[4] = ((hash[4] << 6) | ((h5 >> 24) & 0x3f)) & mask;
                                 ^
                             :60:26: error: use of undeclared identifier 'idx'
                                     unsigned int j = idx;
                                                      ^
                             :122:9: warning: implicit declaration of function 'readInt' is invalid in C99
                                     readInt(privateKeys, i, p);
                                     ^
                             :132:17: warning: implicit declaration of function 'isInfinity' is invalid in C99
                                         if(!isInfinity(x)) {
                                             ^
                             :133:17: warning: implicit declaration of function 'beginBatchAddWithDouble' is invalid in C99
                                             beginBatchAddWithDouble(gx, gy, xPtr, chain, i, batchIdx, inverse);
                                             ^
                             :139:5: warning: implicit declaration of function 'doBatchInverse' is invalid in C99
                                 doBatchInverse(inverse);
                                 ^
                             :159:17: warning: implicit declaration of function 'completeBatchAddWithDouble' is invalid in C99
                                             completeBatchAddWithDouble(gx, gy, xPtr, yPtr, i, batchIdx, chain, inverse, newX, newY);
                                             ^
                             :161:17: warning: implicit declaration of function 'copyBigInt' is invalid in C99
                                             copyBigInt(gx, newX);
                                             ^
                             :165:13: warning: implicit declaration of function 'writeInt' is invalid in C99
                                         writeInt(xPtr, i, newX);
                                         ^
                             :177:5: warning: implicit declaration of function 'sha256PublicKey' is invalid in C99
                                 sha256PublicKey(x, y, hash);
                                 ^
                             :184:5: warning: implicit declaration of function 'ripemd160sha256NoFinal' is invalid in C99
                                 ripemd160sha256NoFinal(hash, digestOut);
                                 ^
                             :191:5: warning: implicit declaration of function 'sha256PublicKeyCompressed' is invalid in C99
                                 sha256PublicKeyCompressed(x, yParity, hash);
                                 ^
                             :272:40: warning: implicit declaration of function 'readLSW' is invalid in C99
                                         hashPublicKeyCompressed(x, readLSW(yPtr, i), digest);
                                                                    ^
                             :281:9: warning: implicit declaration of function 'beginBatchAdd' is invalid in C99
                                     beginBatchAdd(incX, x, chain, i, i, inverse);
                                     ^
                             :291:9: warning: implicit declaration of function 'completeBatchAdd' is invalid in C99
                                     completeBatchAdd(incX, incY, xPtr, yPtr, i, i, chain, inverse, newX, newY);
jr. member
Activity: 35
Merit: 2
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";


Quote
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.

Where is the source code ?
full member
Activity: 1078
Merit: 219
Shooters Shoot...
Quote
Here is sp-mod #4 in vankraken mode: 7 seconds to solve puzzle 39 (4 seconds to set up the poins 3 secs to solve). Note that the speed is only 278Mkeys/s because I only set up 100 starting points.
You make me laugh...I mean that is good and all but you shrunk the 39 bit range down to a 33 bit range.  the correct range is 4000000000:7FFFFFFFFF NOT the range you have dialed in, 4B00000000:4C00000000 . If I shrunk the range down to a 33 bit range, the program would stop before it started with the key.

Come on sp, you're better than that.

Doesn't matter, random is random, and you can't even do that fairly.

I posted my results for side by side comparisons of original bitcrack versus vanbitcracken. vanbitcracken Exceeds your mods' "speed-up" percentages.

Post your best time in a 40 bit range (normal, not random, meaning reach the end of keyspace) and let me show you what vanbitcracken can really do...
I bet you I will beat your mods' best time by 100s of percents, maybe even 1000s of percents.  What say you?
full member
Activity: 1078
Merit: 219
Shooters Shoot...
Quote
As you can see, not only MKey/s on screen is faster, but also time to solve is ~5% faster. Unfortunally I cannot test sp_'s mod on my Tesla GPUs, because, as I said earlier, it all working under Ubuntu. So I'll waiting for Linux release to made a more complex and interesting tests.
Ok, I did the comparison test differently since I felt your test was still missing the point as "points, threads" can be spread out differently. I get it was ok for your test since you were comparing an original versus sp's modded version.

What I did was place an extra address that was outside of the range so that each program would actually have to find the 9 in the range and then reach the end of keyspace...that's what I wanted to see, how fast could it get through a range while finding all keys (in the range).

Here are my results:

original bitcrack:
Code:
[2021-03-26.01:13:58] [Info] Compression: compressed
[2021-03-26.01:13:58] [Info] Starting at: 0000000000000000000000000000000000000000000000000000000100000000
[2021-03-26.01:13:58] [Info] Ending at:   00000000000000000000000000000000000000000000000000000001FFFFFFFF
[2021-03-26.01:13:58] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2021-03-26.01:13:58] [Info] Initializing GeForce GTX 1060 6GB
[2021-03-26.01:13:59] [Info] Generating 4,194,304 starting points (160.0MB)
[2021-03-26.01:14:00] [Info] 10.0%
[2021-03-26.01:14:00] [Info] 20.0%
[2021-03-26.01:14:00] [Info] 30.0%
[2021-03-26.01:14:00] [Info] 40.0%
[2021-03-26.01:14:00] [Info] 50.0%
[2021-03-26.01:14:01] [Info] 60.0%
[2021-03-26.01:14:01] [Info] 70.0%
[2021-03-26.01:14:01] [Info] 80.0%
[2021-03-26.01:14:01] [Info] 90.0%
[2021-03-26.01:14:01] [Info] 100.0%
[2021-03-26.01:14:01] [Info] Done
[2021-03-26.01:14:01] [Info] Loading addresses from 'compare.txt'
[2021-03-26.01:14:01] [Info] 10 addresses loaded (0.0MB)
GeForce GTX 1060 1441 / 6144MB | 10 targets 84.16 MKey/s (775,946,240 total) [00:00:07][2021-03-26.01:14:11] [Info] Found key for address '13vN1zbeNJaLEAapSEB5q6Tx2u8Czbg3PC'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 9 targets 83.33 MKey/s (926,941,184 total) [00:00:09][2021-03-26.01:14:12] [Info] Found key for address '131P4vKA1Udm4pYLR6AdxqTS8MicrtHwAP'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 8 targets 85.65 MKey/s (1,396,703,232 total) [00:00:14][2021-03-26.01:14:19] [Info] Found key for address '15CvUrFPRuTmRfrqdyeJmzJyBm5XSgG2pF'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 7 targets 84.20 MKey/s (1,707,081,728 total) [00:00:18][2021-03-26.01:14:22] [Info] Found key for address '13ePh5jTqAScHpHn64veJCjsNercbY2Vk8'. Written to 'comparetest.txt'
[2021-03-26.01:14:23] [Info] Found key for address '1FHcbX4NRHyM7czubge2qGvTyWbm7mpHAj'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 5 targets 84.16 MKey/s (2,793,406,464 total) [00:00:31][2021-03-26.01:14:34] [Info] Found key for address '1F7GmqBsaijtTzubeuk32qC6Nn5MYAyfkT'. Written to 'comparetest.txt'
[2021-03-26.01:14:34] [Info] Found key for address '1CXTEzbAATX1D5YB3Ncci1gtBEEchT2JJs'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 3 targets 86.48 MKey/s (3,426,746,368 total) [00:00:38][2021-03-26.01:14:43] [Info] Found key for address '1KGqdarqVdTDS7qDxb4haaMqBMRZ4kJvEU'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 2 targets 85.60 MKey/s (3,741,319,168 total) [00:00:42][2021-03-26.01:14:46] [Info] Found key for address '15MjvwJbHtbxJKy8AmZWXjXppk66qxYaoV'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 1 target 86.43 MKey/s (4,219,469,824 total) [00:00:47][2021-03-26.01:14:51] [Info] Reached end of keyspace

C:\Users\your\Documents\VanSearch>pause
Press any key to continue . . .
It took right at 53 seconds to find the 9 keys in the range and actually reach the end of keyspace.

VanBitCracken results:
Code:
VanBitCracken v1.0
Keyspace start=100000000
Keyspace   end=1FFFFFFFF
Search: 10 addresses (Lookup size 10,[1,1]) [Compressed]
Start at Fri Mar 26 01:12:43 2021
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1060 6GB (10x128 cores) Grid(512x512)
[EXIT] Reached end of keyspace. (2^32.09) [00:00:37 Elapsed Time//Time Left 00:00:00][9]
Finish at Fri Mar 26 01:13:23 2021

C:\Users\your\Documents\VanSearch>pause
Press any key to continue . . .
VBC took right at 40 seconds to find the 9 keys in the range and actually reach the end of keyspace.

So VanBitCracken was 13 seconds faster. Which is what, 24.5% faster than the original cuBitCrack, right?

If I run the same exact test that you did, just finding the 9 keys, here are the results:

original bitcrack:
Code:
[2021-03-26.01:31:49] [Info] Compression: compressed
[2021-03-26.01:31:49] [Info] Starting at: 0000000000000000000000000000000000000000000000000000000100000000
[2021-03-26.01:31:49] [Info] Ending at:   00000000000000000000000000000000000000000000000000000001FFFFFFFF
[2021-03-26.01:31:49] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2021-03-26.01:31:49] [Info] Initializing GeForce GTX 1060 6GB
[2021-03-26.01:31:49] [Info] Generating 4,194,304 starting points (160.0MB)
[2021-03-26.01:31:50] [Info] 10.0%
[2021-03-26.01:31:51] [Info] 20.0%
[2021-03-26.01:31:51] [Info] 30.0%
[2021-03-26.01:31:51] [Info] 40.0%
[2021-03-26.01:31:51] [Info] 50.0%
[2021-03-26.01:31:51] [Info] 60.0%
[2021-03-26.01:31:51] [Info] 70.0%
[2021-03-26.01:31:51] [Info] 80.0%
[2021-03-26.01:31:51] [Info] 90.0%
[2021-03-26.01:31:51] [Info] 100.0%
[2021-03-26.01:31:51] [Info] Done
[2021-03-26.01:31:51] [Info] Loading addresses from 'compare.txt'
[2021-03-26.01:31:51] [Info] 9 addresses loaded (0.0MB)
GeForce GTX 1060 1441 / 6144MB | 9 targets 85.65 MKey/s (775,946,240 total) [00:00:07][2021-03-26.01:32:02] [Info] Found key for address '13vN1zbeNJaLEAapSEB5q6Tx2u8Czbg3PC'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 8 targets 85.60 MKey/s (931,135,488 total) [00:00:09][2021-03-26.01:32:02] [Info] Found key for address '131P4vKA1Udm4pYLR6AdxqTS8MicrtHwAP'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 7 targets 84.90 MKey/s (1,396,703,232 total) [00:00:14][2021-03-26.01:32:09] [Info] Found key for address '15CvUrFPRuTmRfrqdyeJmzJyBm5XSgG2pF'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 6 targets 84.90 MKey/s (1,707,081,728 total) [00:00:18][2021-03-26.01:32:12] [Info] Found key for address '13ePh5jTqAScHpHn64veJCjsNercbY2Vk8'. Written to 'comparetest.txt'
[2021-03-26.01:32:13] [Info] Found key for address '1FHcbX4NRHyM7czubge2qGvTyWbm7mpHAj'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 4 targets 86.43 MKey/s (2,818,572,288 total) [00:00:31][2021-03-26.01:32:24] [Info] Found key for address '1F7GmqBsaijtTzubeuk32qC6Nn5MYAyfkT'. Written to 'comparetest.txt'
[2021-03-26.01:32:24] [Info] Found key for address '1CXTEzbAATX1D5YB3Ncci1gtBEEchT2JJs'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 2 targets 86.48 MKey/s (3,451,912,192 total) [00:00:38][2021-03-26.01:32:33] [Info] Found key for address '1KGqdarqVdTDS7qDxb4haaMqBMRZ4kJvEU'. Written to 'comparetest.txt'
GeForce GTX 1060 1441 / 6144MB | 1 target 86.43 MKey/s (3,766,484,992 total) [00:00:42][2021-03-26.01:32:36] [Info] Found key for address '15MjvwJbHtbxJKy8AmZWXjXppk66qxYaoV'. Written to 'comparetest.txt'
[2021-03-26.01:32:36] [Info] No targets remaining

C:\Users\your\Documents\VanSearch>pause
Press any key to continue . . .

and VanBit:
Code:
VanBitCracken v1.0
Keyspace start=100000000
Keyspace   end=1FFFFFFFF
Search: 9 addresses (Lookup size 9,[1,1]) [Compressed]
Start at Fri Mar 26 01:33:34 2021
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1060 6GB (10x128 cores) Grid(512x512)
Finish at Fri Mar 26 01:34:07 2021^31.70) [00:00:28 Elapsed Time//Time Left 00:00:07][9]

C:\Users\your\Documents\VanSearch>pause
Press any key to continue . . .

To compare, original bitcrack took 48 seconds and VanBit took 33 seconds.  Which is what, 31.25% faster than the original cuBitCrack, right?
full member
Activity: 1078
Merit: 219
Shooters Shoot...
Quote
As you can see, not only MKey/s on screen is faster, but also time to solve is ~5% faster. Unfortunally I cannot test sp_'s mod on my Tesla GPUs, because, as I said earlier, it all working under Ubuntu. So I'll waiting for Linux release to made a more complex and interesting tests.
TBH, kinda hard to read it all but looks like 8 or 9 seconds faster. I'll take your word for it and we will say 5%.  But not 20%? 

Also, what is oBitCrack?
9 sec from 180 sec total is ~5%.
20% will probably be on more powerful GPUs of a different architecture, which is why I wrote about the need for tests on powerful video cards.

oBitCrack it is just renamed original cuBitCrack.exe.
May need to tweak your test...standby
sp_
legendary
Activity: 2912
Merit: 1087
Team Black developer
And I don't care about speed at all; I care about results...in time.
On the one hand, of course you are right. But we are discussing a bruteforce program here. For bruteforce, the only indicator of the quality of work is important - it is the number of keys/addresses per second.

Here is sp-mod #4 in vankraken mode: 7 seconds to solve puzzle 39 (4 seconds to set up the poins 3 secs to solve). Note that the speed is only 278Mkeys/s because I only set up 100 starting points.

Quote
cubitcrack --keyspace 4B00000000:4C00000000 122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8 -p 100


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


[2021-03-26.08:49:07] [Info] Compression: compressed
[2021-03-26.08:49:07] [Info] Starting at: 0000000000000000000000000000000000000000000000000000004B00000000
[2021-03-26.08:49:07] [Info] Ending at:   0000000000000000000000000000000000000000000000000000004C00000000
[2021-03-26.08:49:07] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2021-03-26.08:49:07] [Info] Initializing GeForce GTX 1070 Ti
[2021-03-26.08:49:07] [Info] Generating 1,945,600 starting points (74.2MB)
[2021-03-26.08:49:08] [Info] 10.0%
[2021-03-26.08:49:08] [Info] 20.0%
[2021-03-26.08:49:08] [Info] 30.0%
[2021-03-26.08:49:08] [Info] 40.0%
[2021-03-26.08:49:08] [Info] 50.0%
[2021-03-26.08:49:08] [Info] 60.0%
[2021-03-26.08:49:08] [Info] 70.0%
[2021-03-26.08:49:08] [Info] 80.0%
[2021-03-26.08:49:08] [Info] 90.0%
[2021-03-26.08:49:09] [Info] 100.0%
[2021-03-26.08:49:09] [Info] Done
GeForce GTX 1070 416 / 8192MB | 1 target 282.24 MKey/s (1,533,132,800 total) [00:00:03][2021-03-26.08:49:14] [Info] Address:     122AJh
LEfkFBaGAd84pLp1kfE7xK3GdT8
                             Private key: 0000000000000000000000000000000000000000000000000000004B5F8303E9
                             Compressed:  yes
                             Public key:
                             022D77CD1467019A6BF28F7375D0949CE30E6B5815C2758B98A74C2700BC006543

[2021-03-26.08:49:14] [Info] No targets remaining
Execution time = 7 seconds

Here is the original bitcrack in bitkraken mode with -p 100 (4-5 seconds to set up the poins 5 secs to solve)

Quote
GeForce GTX 1070 312 / 8192MB | 1 target 200.62 MKey/s (1,456,537,600 total) [00:00:05][2021-03-26.08:59:19] [Info] Address:     122AJhK
LEfkFBaGAd84pLp1kfE7xK3GdT8
                             Private key: 0000000000000000000000000000000000000000000000000000004B5F8303E9
                             Compressed:  yes
                             Public key:
                             022D77CD1467019A6BF28F7375D0949CE30E6B5815C2758B98A74C2700BC006543
member
Activity: 107
Merit: 61
Quote
As you can see, not only MKey/s on screen is faster, but also time to solve is ~5% faster. Unfortunally I cannot test sp_'s mod on my Tesla GPUs, because, as I said earlier, it all working under Ubuntu. So I'll waiting for Linux release to made a more complex and interesting tests.
TBH, kinda hard to read it all but looks like 8 or 9 seconds faster. I'll take your word for it and we will say 5%.  But not 20%? 

Also, what is oBitCrack?
9 sec from 180 sec total is ~5%.
20% will probably be on more powerful GPUs of a different architecture, which is why I wrote about the need for tests on powerful video cards.

oBitCrack it is just renamed original cuBitCrack.exe.
full member
Activity: 1078
Merit: 219
Shooters Shoot...
Quote
As you can see, not only MKey/s on screen is faster, but also time to solve is ~5% faster. Unfortunally I cannot test sp_'s mod on my Tesla GPUs, because, as I said earlier, it all working under Ubuntu. So I'll waiting for Linux release to made a more complex and interesting tests.
TBH, kinda hard to read it all but looks like 8 or 9 seconds faster. I'll take your word for it and we will say 5%.  But not 20%? 

Also, what is oBitCrack?
member
Activity: 107
Merit: 61
Again, here you are talking about speed in MKey/s...why?

Take away random, because my program kicks his backside, period. Small range.

What I am talking about is getting through a range and finding the key(s)...the results!

So are you willing to buy a program I created that will SHOW you on the screen that you are getting 2000 MKey/s with an old Nvidia or AMD card? Because I can sure fudge the speed on the screen to appear to be getting 2000 MKey/s

Or would you rather use a program that gets through a range quicker and finds all keys in the range?  That is my point. Someone can posts speed and increases in speed but unless you compare them, actually working through an entire range, not just finding one random key, then it's all talk and quite frankly, BS.

I did a test with the original bitcrack with a less powerful card than what sp was using with his mod and the numbers didn't compute. My lesser card only trailed his by a few seconds in finding the key, but his speed showed 450+ MKey/s while mine was at 93 or 113 MKey/s ... see the problem there? His program and card should have finished 4x faster than mine. But it didn't.

Of course I'm talking about real MKeys/sec, not about some digits on screen. I have my own Vanity modification for range searching, but I still have not fixed the speed multiplier by 6 when outputting to the screen, because the numbers on the screen are not the most important thing.

I asked someone do a true comparison test, through a range, with 1 key up front, 1 key in middle, and 1 at the end.  That's how you compare the two programs, not by MKey/s on a screen.
I made a simple syntetic test within puzzle 33 range, and run it on my old laptop. The grid on original and mod versions is same, to ensure that number of starting points not affecting the speed.

Keys generation:
Code:
import random
import btc

a = 0x100000000
b = 0x1ffffffff
for i in range(1,10):
  k = random.randint(a,b)
  print(hex(k), btc.key_to_address(k, True))
  
------
0x1e5594206 15MjvwJbHtbxJKy8AmZWXjXppk66qxYaoV
0x15ab52be9 15CvUrFPRuTmRfrqdyeJmzJyBm5XSgG2pF
0x16750f92f 13ePh5jTqAScHpHn64veJCjsNercbY2Vk8
0x16e34fd54 1FHcbX4NRHyM7czubge2qGvTyWbm7mpHAj
0x1377cdc0c 131P4vKA1Udm4pYLR6AdxqTS8MicrtHwAP
0x1a80ec32e 1CXTEzbAATX1D5YB3Ncci1gtBEEchT2JJs
0x1d3667a73 1KGqdarqVdTDS7qDxb4haaMqBMRZ4kJvEU
0x1343f12f9 13vN1zbeNJaLEAapSEB5q6Tx2u8Czbg3PC
0x1a7ceb1e9 1F7GmqBsaijtTzubeuk32qC6Nn5MYAyfkT

Original BitCrack:
Code:
oBitCrack.exe -b 6 -t 512 -p 512 --keyspace 100000000:1ffffffff -i addresses.txt
[2021-03-26.10:07:36] [Info] Compression: compressed
[2021-03-26.10:07:36] [Info] Starting at: 0000000000000000000000000000000000000000000000000000000100000000
[2021-03-26.10:07:36] [Info] Ending at:   00000000000000000000000000000000000000000000000000000001FFFFFFFF
[2021-03-26.10:07:36] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2021-03-26.10:07:36] [Info] Initializing GeForce 940M
[2021-03-26.10:07:36] [Info] Generating 1,572,864 starting points (60.0MB)
[2021-03-26.10:07:38] [Info] 10.0%
[2021-03-26.10:07:38] [Info] 20.0%
[2021-03-26.10:07:38] [Info] 30.0%
[2021-03-26.10:07:38] [Info] 40.0%
[2021-03-26.10:07:39] [Info] 50.0%
[2021-03-26.10:07:39] [Info] 60.0%
[2021-03-26.10:07:39] [Info] 70.0%
[2021-03-26.10:07:40] [Info] 80.0%
[2021-03-26.10:07:40] [Info] 90.0%
[2021-03-26.10:07:40] [Info] 100.0%
[2021-03-26.10:07:40] [Info] Done
[2021-03-26.10:07:40] [Info] Loading addresses from 'addresses.txt'
[2021-03-26.10:07:40] [Info] 9 addresses loaded (0.0MB)
GeForce 940M     503 / 2048MB | 9 targets 31.25 MKey/s (849,346,560 total) [00:00:25][2021-03-26.10:08:08] [Info] Address:     13vN1zbeNJaLEAapSEB5q6Tx2u8Czbg3PC
                             Private key: 00000000000000000000000000000000000000000000000000000001343F12F9
                             Compressed:  yes
                             Public key:
                             03C9A5A30DBEDAF27F315A0C7A1F4BFDF2A1537396F500CDD51101CDB0B131F4C7

GeForce 940M     503 / 2048MB | 8 targets 30.96 MKey/s (905,969,664 total) [00:00:27][2021-03-26.10:08:10] [Info] Address:     131P4vKA1Udm4pYLR6AdxqTS8MicrtHwAP
                             Private key: 00000000000000000000000000000000000000000000000000000001377CDC0C
                             Compressed:  yes
                             Public key:
                             02452A6D3FB3C4EBF93EDC7EFE5ABB1C1F953FFA033D9D397FE9E68261EFDA1E25

GeForce 940M     503 / 2048MB | 7 targets 31.23 MKey/s (1,478,492,160 total) [00:00:45][2021-03-26.10:08:29] [Info] Address:     15CvUrFPRuTmRfrqdyeJmzJyBm5XSgG2pF
                             Private key: 000000000000000000000000000000000000000000000000000000015AB52BE9
                             Compressed:  yes
                             Public key:
                             02DC0DF5814157C4134F4FC16B47CE49CDB20597EBDC5F3F71265BB75152C20416

GeForce 940M     503 / 2048MB | 6 targets 31.23 MKey/s (1,706,557,440 total) [00:00:52][2021-03-26.10:08:36] [Info] Address:     13ePh5jTqAScHpHn64veJCjsNercbY2Vk8
                             Private key: 000000000000000000000000000000000000000000000000000000016750F92F
                             Compressed:  yes
                             Public key:
                             0307CD9AA9FEB167423BA03675FCC911BFCE47D860FAB89E9E6CF2E8ABC7C181F8

GeForce 940M     503 / 2048MB | 5 targets 31.29 MKey/s (1,821,376,512 total) [00:00:56][2021-03-26.10:08:39] [Info] Address:     1FHcbX4NRHyM7czubge2qGvTyWbm7mpHAj
                             Private key: 000000000000000000000000000000000000000000000000000000016E34FD54
                             Compressed:  yes
                             Public key:
                             02D58BEA141737AE1B010188BDDAB3D91729E2E4385C85451F8BC47002099FFBCF

GeForce 940M     503 / 2048MB | 4 targets 31.56 MKey/s (2,801,270,784 total) [00:01:27][2021-03-26.10:09:10] [Info] Address:     1F7GmqBsaijtTzubeuk32qC6Nn5MYAyfkT
                             Private key: 00000000000000000000000000000000000000000000000000000001A7CEB1E9
                             Compressed:  yes
                             Public key:
                             03FD0E95164339B2F228CCF60A95F596FC706F5C5559F2D06AC7BBEED4BE1B2578

[2021-03-26.10:09:10] [Info] Address:     1CXTEzbAATX1D5YB3Ncci1gtBEEchT2JJs
                             Private key: 00000000000000000000000000000000000000000000000000000001A80EC32E
                             Compressed:  yes
                             Public key:
                             020C60BB4BED07723B7D4537E4C7A6C437477EDD9CF19FDD458EFDA1EFDE1C02FE

GeForce 940M     503 / 2048MB | 2 targets 31.58 MKey/s (3,493,330,944 total) [00:01:49][2021-03-26.10:09:34] [Info] Address:     1KGqdarqVdTDS7qDxb4haaMqBMRZ4kJvEU
                             Private key: 00000000000000000000000000000000000000000000000000000001D3667A73
                             Compressed:  yes
                             Public key:
                             0218FEB4168B89B4A118C8B1DA28309FD97405D979CA96165BC86FBA8E2C59A7E1

GeForce 940M     503 / 2048MB | 1 target 31.84 MKey/s (3,840,933,888 total) [00:02:00][2021-03-26.10:09:43] [Info] Address:     15MjvwJbHtbxJKy8AmZWXjXppk66qxYaoV
                             Private key: 00000000000000000000000000000000000000000000000000000001E5594206
                             Compressed:  yes
                             Public key:
                             0259B67380B41AD100F4592503C2F260B13334374238724105BE03EE1602C1F1AE

[2021-03-26.10:09:43] [Info] No targets remaining

sp_'s mod:
Code:
cuBitCrack.exe -b 6 -t 512 -p 512 --keyspace 100000000:1ffffffff -i addresses.txt


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


[2021-03-26.10:10:15] [Info] Compression: compressed
[2021-03-26.10:10:15] [Info] Starting at: 0000000000000000000000000000000000000000000000000000000100000000
[2021-03-26.10:10:15] [Info] Ending at:   00000000000000000000000000000000000000000000000000000001FFFFFFFF
[2021-03-26.10:10:15] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2021-03-26.10:10:15] [Info] Initializing GeForce 940M
[2021-03-26.10:10:15] [Info] Generating 1,572,864 starting points (60.0MB)
[2021-03-26.10:10:16] [Info] 10.0%
[2021-03-26.10:10:16] [Info] 20.0%
[2021-03-26.10:10:17] [Info] 30.0%
[2021-03-26.10:10:17] [Info] 40.0%
[2021-03-26.10:10:17] [Info] 50.0%
[2021-03-26.10:10:18] [Info] 60.0%
[2021-03-26.10:10:18] [Info] 70.0%
[2021-03-26.10:10:18] [Info] 80.0%
[2021-03-26.10:10:18] [Info] 90.0%
[2021-03-26.10:10:19] [Info] 100.0%
[2021-03-26.10:10:19] [Info] Done
[2021-03-26.10:10:19] [Info] Loading addresses from 'addresses.txt'
[2021-03-26.10:10:19] [Info] 9 addresses loaded (0.0MB)
GeForce 940M     505 / 2048MB | 9 targets 32.99 MKey/s (871,366,656 total) [00:00:23][2021-03-26.10:10:45] [Info] Address:     13vN1zbeNJaLEAapSEB5q6Tx2u8Czbg3PC
                             Private key: 00000000000000000000000000000000000000000000000000000001343F12F9
                             Compressed:  yes
                             Public key:
                             03C9A5A30DBEDAF27F315A0C7A1F4BFDF2A1537396F500CDD51101CDB0B131F4C7

[2021-03-26.10:10:46] [Info] Address:     131P4vKA1Udm4pYLR6AdxqTS8MicrtHwAP
                             Private key: 00000000000000000000000000000000000000000000000000000001377CDC0C
                             Compressed:  yes
                             Public key:
                             02452A6D3FB3C4EBF93EDC7EFE5ABB1C1F953FFA033D9D397FE9E68261EFDA1E25

GeForce 940M     505 / 2048MB | 7 targets 30.36 MKey/s (1,480,065,024 total) [00:00:42][2021-03-26.10:11:04] [Info] Address:     15CvUrFPRuTmRfrqdyeJmzJyBm5XSgG2pF
                             Private key: 000000000000000000000000000000000000000000000000000000015AB52BE9
                             Compressed:  yes
                             Public key:
                             02DC0DF5814157C4134F4FC16B47CE49CDB20597EBDC5F3F71265BB75152C20416

GeForce 940M     505 / 2048MB | 6 targets 34.14 MKey/s (1,711,276,032 total) [00:00:49][2021-03-26.10:11:11] [Info] Address:     13ePh5jTqAScHpHn64veJCjsNercbY2Vk8
                             Private key: 000000000000000000000000000000000000000000000000000000016750F92F
                             Compressed:  yes
                             Public key:
                             0307CD9AA9FEB167423BA03675FCC911BFCE47D860FAB89E9E6CF2E8ABC7C181F8

GeForce 940M     505 / 2048MB | 5 targets 32.97 MKey/s (1,830,813,696 total) [00:00:53][2021-03-26.10:11:14] [Info] Address:     1FHcbX4NRHyM7czubge2qGvTyWbm7mpHAj
                             Private key: 000000000000000000000000000000000000000000000000000000016E34FD54
                             Compressed:  yes
                             Public key:
                             02D58BEA141737AE1B010188BDDAB3D91729E2E4385C85451F8BC47002099FFBCF

GeForce 940M     505 / 2048MB | 4 targets 27.78 MKey/s (2,809,135,104 total) [00:01:22][2021-03-26.10:11:43] [Info] Address:     1F7GmqBsaijtTzubeuk32qC6Nn5MYAyfkT
                             Private key: 00000000000000000000000000000000000000000000000000000001A7CEB1E9
                             Compressed:  yes
                             Public key:
                             03FD0E95164339B2F228CCF60A95F596FC706F5C5559F2D06AC7BBEED4BE1B2578

[2021-03-26.10:11:43] [Info] Address:     1CXTEzbAATX1D5YB3Ncci1gtBEEchT2JJs
                             Private key: 00000000000000000000000000000000000000000000000000000001A80EC32E
                             Compressed:  yes
                             Public key:
                             020C60BB4BED07723B7D4537E4C7A6C437477EDD9CF19FDD458EFDA1EFDE1C02FE

GeForce 940M     505 / 2048MB | 2 targets 34.42 MKey/s (3,496,476,672 total) [00:01:42][2021-03-26.10:12:05] [Info] Address:     1KGqdarqVdTDS7qDxb4haaMqBMRZ4kJvEU
                             Private key: 00000000000000000000000000000000000000000000000000000001D3667A73
                             Compressed:  yes
                             Public key:
                             0218FEB4168B89B4A118C8B1DA28309FD97405D979CA96165BC86FBA8E2C59A7E1

GeForce 940M     505 / 2048MB | 1 target 34.14 MKey/s (3,792,175,104 total) [00:01:51][2021-03-26.10:12:14] [Info] Address:     15MjvwJbHtbxJKy8AmZWXjXppk66qxYaoV
                             Private key: 00000000000000000000000000000000000000000000000000000001E5594206
                             Compressed:  yes
                             Public key:
                             0259B67380B41AD100F4592503C2F260B13334374238724105BE03EE1602C1F1AE

[2021-03-26.10:12:14] [Info] No targets remaining

As you can see, not only MKey/s on screen is faster, but also time to solve is ~5% faster. Unfortunally I cannot test sp_'s mod on my Tesla GPUs, because, as I said earlier, it all working under Ubuntu. So I'll waiting for Linux release to made a more complex and interesting tests.
full member
Activity: 1078
Merit: 219
Shooters Shoot...
And I don't care about speed at all; I care about results...in time.
On the one hand, of course you are right. But we are discussing a bruteforce program here. For bruteforce, the only indicator of the quality of work is important - it is the number of keys/addresses per second.

If we are talking about randomness, then it is obvious that the program can select starting points in such a way that one target key is far from them, and the other is close, but this is not at all an indicator of the quality of work. For example, it is possible that someone wrote a program that instantly solved a some key in a wide range, due to the fact that one of the starting points coincided with the key - will this be an indicator of the speed of work?

Personally, I'm interested in testing different algorithms, but in this case your program is not available, you only show some working logs.
I also cannot fully test the modification from the sp_, since only executables for Windows are available, and 99% of my GPUs on Ubuntu. However, I saw a slight increase in speed on Windows machines, so in my opinion this modification at least has the right to life.

Again, here you are talking about speed in MKey/s...why?

Take away random, because my program kicks his backside, period. Small range.

What I am talking about is getting through a range and finding the key(s)...the results!

So are you willing to buy a program I created that will SHOW you on the screen that you are getting 2000 MKey/s with an old Nvidia or AMD card? Because I can sure fudge the speed on the screen to appear to be getting 2000 MKey/s

Or would you rather use a program that gets through a range quicker and finds all keys in the range?  That is my point. Someone can posts speed and increases in speed but unless you compare them, actually working through an entire range, not just finding one random key, then it's all talk and quite frankly, BS.

I did a test with the original bitcrack with a less powerful card than what sp was using with his mod and the numbers didn't compute. My lesser card only trailed his by a few seconds in finding the key, but his speed showed 450+ MKey/s while mine was at 93 or 113 MKey/s ... see the problem there? His program and card should have finished 4x faster than mine. But it didn't.

I asked someone do a true comparison test, through a range, with 1 key up front, 1 key in middle, and 1 at the end.  That's how you compare the two programs, not by MKey/s on a screen.
member
Activity: 107
Merit: 61
And I don't care about speed at all; I care about results...in time.
On the one hand, of course you are right. But we are discussing a bruteforce program here. For bruteforce, the only indicator of the quality of work is important - it is the number of keys/addresses per second.

If we are talking about randomness, then it is obvious that the program can select starting points in such a way that one target key is far from them, and the other is close, but this is not at all an indicator of the quality of work. For example, it is possible that someone wrote a program that instantly solved a some key in a wide range, due to the fact that one of the starting points coincided with the key - will this be an indicator of the speed of work?

Personally, I'm interested in testing different algorithms, but in this case your program is not available, you only show some working logs.
I also cannot fully test the modification from the sp_, since only executables for Windows are available, and 99% of my GPUs on Ubuntu. However, I saw a slight increase in speed on Windows machines, so in my opinion this modification at least has the right to life.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
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.

Because I can just paste the Int class from Kangaroo to VanitySearch to provide an initial speed boost while Inwork on other things  Wink



On the positive side though, I did manage to replace the Misaligned access error with an Invalid Argument error, I think that one should be reproducible in a debug environment.
member
Activity: 406
Merit: 45

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
jr. member
Activity: 36
Merit: 3
@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.


Quote
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.
full member
Activity: 1078
Merit: 219
Shooters Shoot...
Quote
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.
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
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.
sp_
legendary
Activity: 2912
Merit: 1087
Team Black developer
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.
Pages:
Jump to: