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

The old version had issues of actually finding keys in range; make sure your version actually finds several keys inside a range. At least 3, 1 up front, 1 in middle, 1 at end.

In sequence I reach D450 to D452

Proof of work

16jY7qLJUaufsL5txajW6ZoHQtSr5TYvwz  D45012EB3DB1832E
16jY7qLJqsq8GF2MhDtpNiRVyzgvMtj1dC  D45013CC5549536E
16jY7qLJaVKDJxJ3EkUsqqwQ3euWFBEngc  D450264B1FFE218E
16jY7qLJWuGpNAdJz8UdbE55fhQVMJP7wu  D450275B6A8F6609
16jY7qLJnRVevUWiGvZALtRwZg2U8EHboN  D4502ACBE5190ED4
16jY7qLJvBuPPFEsqhd1YG6dFKVvts2ijd  D4502D5B9B2C0435
16jY7qLJFFcYnsHZmR91cGGjZRYzpFfv2R  D4502ECBB2E8AC29
16jY7qLJHnqsTt8TAQsaDBpAQssVHVfSnH  D450425C8EDF26CD
16jY7qLJUQnkD25HBd2sHghnJaCddsk3vA  D450481BBE592778
16jY7qLJcqz7TLZv19qBSewUVAMZBwejhP  D45048ECA5CFAF4E
16jY7qLJJBQ2bmUViRhfHAioYk7qntqUkx  D450492B1A522737
16jY7qLJANPDVkTRGj1k7SsfQKotDMgm4w  D45056CB1BF09FAA
16jY7qLJuEq3wmYSyk16o2F7bYB3yPfYPd  D4505AAB8FFE082A
16jY7qLJoe9zhgyqpVpQPkDi3mKkou6LDy  D4505D7B31B8843E
16jY7qLJ4cGBS37pmd3xKARPjH5f9UQVUP  D4505F4B5E0432AD
16jY7qLJspZt4utME4TtoKd847FCVi3QFY  D4505F6B2CEA838E
16jY7qLJMkXZzHAfaKD2t5g4JnCUb96Hcp  D4507AFB66B7A47F
16jY7qLJ4CBhpr41CHYJxsuzWTXDWPrgP4  D4507E2BF014B35E
16jY7qLJrPE7VPgyFzSGxvMbaBvcTget2j  D450845B14FCACE6
16jY7qLJwbwR8jTq7MgC1VGqH68V3VDczv  D450954B2ED00F4B
16jY7qLJykUb88ofyXx3vuyYkk4R5BSVu9  D450980B08FCB255
16jY7qLJ9LDvXHXvQLp5dQsK6PZGwkLkV7  D450A05BE8E8F4F8
16jY7qLJd6FeNSbvFUyNvFKHGF83znxEDK  D450A5CB98EB5163
16jY7qLJ6wA94WAY2bfXFazD1cCD46uzH4  D450B25B39FE958B
16jY7qLJ7RZxHSpv49XbbrXqiGYkLViUkE  D450C12B941496C6
16jY7qLJ6ffJW4jmbW8MJuDGhzpGzU9RTM  D450C16BDF82C020
16jY7qLJGYrcTT9BcQeCUAFVEdhXCSzgZd  D450C9AB7E0FC564
16jY7qLJprs1RuTWWT1GezAsHEZhC3qcq9  D450D70BD1E6B64D
16jY7qLJfVpYcbuie5NEiiZAkStUKnsKMs  D450DD5B9AFCAA69
16jY7qLJLNwVxd5KjTHRjGBSmQ3oSVAgUW  D450E32B41FE9869
16jY7qLJMPaGAyReHJwbjGittAMQ8BSvQm  D450EF9BB5D084ED
16jY7qLJp7ersQi5R7VD8wfkPgkBPfq52u  D4510DCB03B118AA
16jY7qLJuF5FiXBmoUEa6VnW1Q2dAKZy8d  D451179B6E8A4E17
16jY7qLJhrpH9yKEVVudVwngmugKx2BXvS  D45117BBD75764DB
16jY7qLJL5XpPPCXsVJdTxiC3sQtoNhTXC  D45118BB8546FC28
16jY7qLJughyD4jPSaQ2nnEn6kr8chqKZx  D451206BAB9F8870
16jY7qLJDjytorShy9CMFopk7VCdUgu7xa  D451297B1CA629E5
16jY7qLJaKKq9jUp53NFxZf3YUCboULocx  D4514CCB91F6534D
16jY7qLJno65XTkhMQTdRSZJArVE7H3kCo  D451639BA890B0F4
16jY7qLJ7D9tH5HM9Ko9wuojt9RPCmZpSp  D451656B2B6073BE
16jY7qLJtTRQWuWDU1DoChpPQavY6jofUZ  D45169BB30495DEA
16jY7qLJQf8ep8FDm51wALr5HKeqnEL3KJ  D4516D9C0960D5E2
16jY7qLJsXUs4qugupxGKjC21Hc8kcAq6h  D45172CB12EAF4C4
16jY7qLJMCjjh6MzFX9VA3D8TmZd8RHmn7  D4517BBB01ABB335
16jY7qLJ126wgitnhWmWwq5cRZEEiUTKdj  D451839B7C3E8F55
16jY7qLJteYryW4QMRnrjfM6BMp62nNd3Z  D451B64B5105F222
16jY7qLJkgXEYqqf731iTMqtvfBpmWwioC  D451BC7C9EEBB587
16jY7qLJBUHKN4PQC7dEoEXssm9NP1SAcH  D451BF9B9A7FC624
16jY7qLJnq1zjdvv8H6t5mninvWmyX4KVg  D451D25B05CC6B07
16jY7qLJJ4JLKPn5K7uE4DunvtUkkVpY4Y  D451DE9BB197A0C0
16jY7qLJwS3jdV9q5rU8gHxUMxNMnjp3ad  D451E68BB3D3FDF1
16jY7qLJ3uskMpa6tjpvX95kSVuEeq4DmJ  D451F5EBC26BBC5B
16jY7qLJhBqJMBkNtXMV9U8KFk623hd48E  D451F70BC2CDB418

purpose to post.. don't waste time in these ranges

Perhaps someone else will tell us their scanned range so that we do not waste time in those ranges.

I search a lot with prefix like this but can not find any pattern vanity  16jY7qLJ
I think we find to wrong pattern

Done:
https://github.com/Uzlopak/BitCrackOpenCL/releases/tag/v.0.4.0

I also tested the performance:
On my System with a Vega56 I had at the beginning with the old clBitCrack about 58 MKeys/s. Now I get about 83 MKeys/s. Keep in mind: This is just without any specified -b -t -p parameters, which will increase the throughput significally. with -p 5000. I get about 215 MKeys/s. With the old clBitCrack I get with -b 5000 about 190 MKeys/s. If I change only -b to 512 I get about 130 MKeys/s

So the 30 % Improvement are significantly when having low pressure on the GPU. On big load I get "just" 12 % improvement.

I read you can get the bytecode of the on-the-fly compiled openCL part.I will probably implement a solution to store the compiled openCL bytecode in the same folder and load if you run again clBitCrack. Thus should speed up the starting speed... Testing the best parameters should be then not taking always 20 seconds, because OpenCL is building.....

EDIT:
I get with clBitCrack.exe -i addresses.txt --keyspace 1:fffffffffff -b 512 -t 256 -p 256 about 268 MKeys/s

With the old clBitCrack I get in the same case about 210 MKeys/s

So the performance gain is definetely there

Range completed with --stride 1111

Proof of work

16jY7qLJ7nCjNCw3vnHjsNZbswAWbjgJRE  D451B2D7C5C1F338
16jY7qLJ3Dvbu1wTLpuTqpNpmeoyZu6edt  D4532C684B1A0377
16jY7qLJnByZxp2wFGigyn18Q1H53TTmVa  D4538334E25AE667
16jY7qLJqUPuYXpH2sG2RDLs7bkxQ8PeEJ  D457720CFE8EF9B9
16jY7qLJmL7ASHkjmYxyeocgsyCGF7dLuG  D4590E552E66414D
16jY7qLJX52y1TU63G3dZENuZdfbhQNMtp  D45B9DA6D0CCA91C
16jY7qLJWAAv5RTtZ3RzgazoiS8hEV1sAX  D463D679528F8815
16jY7qLJU8XxLVq2BM2bHBEe5vwr4Pffuc  D46458AB1B9F130B
16jY7qLJHSatNNrmU6m3MRJEPuN7RiJaV7  D46B91712BD763C2
16jY7qLJQ1m34R4YBGRWRdGTdABEcyLE65  D46BE3E6992BFEC5

Next --stride 12345

Maybe it is something you can easily digest. But for me this just raises questions.

Do we have some codesnippet which we can copy and put into our codebase?

Professor Lubin noted this here:
https://math.stackexchange.com/questions/3697090/endomorphism-rings-of-elliptic-curves-over-finite-fields

Perhaps this will be of some help to understand more about endomorphism, rings and EC. His example uses a diff formula than what's used by secp256k1 but for me it was helpful.

How do you want to know this range?

Puzzle 64 is between --keyspace D450000000000000:D46fffffffffffff Let's see who solve it first..

Don't bother with that guy he's a troll.

About your other suggestion yesterday:


I'm not going to pretend I know about endomorphisms (besides them being results from projection functions on the and can generate equivalent results), but before any work related to that can be started we have to fully understand how secp256k1 benefits from using them.

I found a copy of the Effective Cryptography book hosted here: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.394.3037&rep=rep1&type=pdf

So... I'm going to study that and try to see what secp256k1 does with endomorphisms.

I also set up my VScode workspace with Github integration the other day so I'm really excited about actually overhauling the codebase

Well actually not. This is a common misconception. A quantum computer is faster for specific operations. And hashing is not necesserily an operation which can make use of quantum supremacy. Thats why there are already encryption methods existing which are quantum-safe.

https://cloud.ibm.com/docs/key-protect?topic=key-protect-quantum-safe-cryptography-tls-introduction

It can not run because an Innosilicon A11 Pro 8GB is an ASIC. ASIC means that the hashing units are optimized microchips which can only one thing and only one thing very very good.

cuda and openCL means that we utilize a graphic cards processing unit (GPU). A GPU is generalized processing unit like a CPU but optimized for mathematical calculations. A CPU has a generalized architecture to process all kind of things.

Thats why a CPU is "slower" than a GPU for calculating hashes and a GPU is "slower" than an ASIC when calculating one specific hash-type.

I think it can not run on ETH mining machine

cuBitcrack can use on NVIDIA CUDA GPU on Windows and Linux only

(Did have any report for use on x86 MAC?)

Can we run cuBitcrack in Innosilicon A11 Pro 8GB 2000Mh ETH mining machine ?

When you have time could you compile an .exe release please? Would like to test it vs. the original. Thanks.

Maybe if we leverage this change from a different repo helps to improve the speed?

https://github.com/RustCrypto/elliptic-curves/pull/82

At least your question didn't get closed as "duplicate"  

But I would change the matrix multiplication algorithm to O( n^2.8 ) Strassen which is faster than standard O(n^3) matmul. Changes in the algorithm used generally make a much more noticeable performance impact than vectorization does.

I forked now BitCrack and improved it a little.

https://github.com/Uzlopak/BitCrackOpenCL/

In this Fork I concentrate on the OpenCL implementation. So no CUDA-stuff.

I already could improve the performance about 30 %. I assume I can get it better, when I start vectorizing the operations.

Already wrote on stackoverflow for help to get atleast the multiply256 function improved:

https://stackoverflow.com/questions/67667314/transform-native-c-matrix-multiplication-to-opencl-simd-matrix-multiplication

Already posted in various chats and on fiverr with a bounty of 25 € to get it done by somebody else... Probably will ending solving it by myself. Some dude on fiverr was first promising to implement it, but I guess it was more like a dud.

I assume a performance improvement of 200-300% when this function is using SIMD-Operation.

I am fixing and optimizing the OpenCL Version of the Bitcracker... It is really odd, but the debug version is faster than the release version... Crazy.

Any Ideas?

Yeah ! faster .. see your screenshot - https://ibb.co/Dpc0HxR -  50% in 1.26609e+32years ^^ good luck  so DON'T BUY IT !!