How do you want to know this range?

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.

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

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

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?

@TangentC

The solution is simple:
Everybody is free to chose if he wants to use bitcoin or not. Thats it.

Expected RAM is 135431276999271530496 MB

The Executable is running into OOM (out of memory) and silently fails?

What are you suggesting? That I compiled something else?

Well I used Visual Studio 2019 (Professional) on Windows 10 with CUDA 10.2 and Windows 10 SDK using the Visual Studio 2019 compiler (v142)

And if you google for _udiv128 you will find https://docs.microsoft.com/en-us/cpp/intrinsics/udiv128?view=msvc-160

This is so true...

Well like I posted before

https://github.com/ZenulAbidin/Kangaroo-256/issues/6

There are various compile versions.

Cuda 10
CUDA 10.2
CUDA 8

and CUDA 10.2 has targets for x32, x64 and x64 for SM 30 (which is actually targetting SM61)

So I will compile once for x64 with CUDA 10.2

EDIT:

here

https://github.com/ZenulAbidin/Kangaroo-256/issues/6

Which project do you actually need to be compiled? I could compile all variations, but would like to just compile the specific one you want...

Just because he has money, doesnt mean that he is smart...

I could successfully build the fork. But would you trust me if I publish the file?

What is the url of the fork?

"We have nothing to lose"

Right. Because you have some shitcoins, were you own x-amount of them. You ask to pump the price and then you will sell them, to become rich(whole purpose of this is that you become richt, or else you wouldn't invest time into this project despite you are losers).

At the end the investors become losers.

There is no real business purpose behind this. Other projects/coins have business models. You have none.

So yeah, nobody should invest because in the long run you lose (losercoim)

Wow, garbage

Well now I bought VS 2019 Pro with small money and used CLANG for compiling clBitCrack. Got from 190 MKeys/s to 192 MKeys/s.

I think this says all.