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

I would honestly not recommend using non-stable software. If I get it to work properly and understand the part going wrong, I'm happy to share. But at this moment, it needs front-running code to restart it. I would be feeling guilty and spending time helping people out, instead of fixing the real problem. I was hoping to trigger someone on the code part going wrong, rather then making people run unstable  

It's not copyBigInt() itself that's problematic (it's a simple element-wise assignment)  but one of the arrays passed to it which is not aligned. CUDA wants all arrays aligned to 32-but boundaries and one of the arrays that eventually reaches copyBigInt() comes from "xp" and "x" pointer arguments of beginBatchAdd()...these are passed to SubModP() and the result is stored in an 8-element int array that's then passed to MulModP() and from there to copyBigInt().

At first it wasn't clear to me where this error was coming from because the problem disappeared in debug mode, so I could not use the debugger. That's right, if you pass -g -G switches to NVCC, you get a working but extremely slow bitcrack binary.

I tried draconian measures in a attempt to fix this like unrolling the loop, changing the array assignment to memcpy(), qualifying it with __restrict__ and __align__ keywords and I even changed it to a #define statement but the destination and source arrays just don't want to be accessed (since these arrays cannot even be used in the parent function, the problem stems deeper). More bafflingly, assigning a constant to an element in the dest array or making a variable that's initialized to an element from src works but this obviously breaks the elliptic curve stuff.

This is supposed to be performance-critical code so I did not attempt to change the static array to malloc.

---

For the uninitiated: this is where the bug is: https://github.com/brichard19/BitCrack/blob/master/cudaMath/secp256k1.cuh

CudaMath/secp256k1.cuh, everything in here are inline functions.

We arrive here from CudaKeySearchDevice via beginBatchAdd() and beginBatchAddWithDouble(). Both of these functions call MulModP for point multiplication. Methods like that need to copy to and from temporary arrays. Somehow the arrays being passed are not on an alignment boundary, and I'm honestly not sure what to do. (Of course, rewriting the whole secp256k1 module is also an option but really...? That's like opening a nut with a sledgehammer.)

For staying in a certain range, (must be a small range); do you want it to end or push back into the range? Bitcrack ends, Kangaroo pushes back. Which route are you trying to go? To end, need last key function...

I would honestly not recommend using non-stable software. If I get it to work properly and understand the part going wrong, I'm happy to share. But at this moment, it needs front-running code to restart it. I would be feeling guilty and spending time helping people out, instead of fixing the real problem. I was hoping to trigger someone on the code part going wrong, rather then making people run unstable  

may I try your modified VanitySearch with keyspace search?

I've modified it to do keyspace search on CUDA 11.2 on my RTX 30XX cards. It just keeps going out of bound at random, so releasing it will just fill my issues with "this doesn't work"
Using small grids, you could keep it running for a bit, but still wouldn't be as stable to put my name on it.

When you say modified VanitySearch, what do you mean? How is it modified? Still searching for vanity/prefixes or doing a search sequentially like bitcracK? Vanity in general, is much more faster than bitcrack.

Really wonder if someone was able to run this against compute_75 & what speed bitcrack would hit. I've been running a modified VanitySearch, doing 4.6GK/s on a single 3090. Sadly due to the 86k threads it trying to fill, it goes out of bounds now & then (GPU/GPUCompute.h:54). Just cannot wrap my head around that funny one yet. But besides of me trying to understand that & learning a lot, CUDA should be doing something near that speed on bitcrack too  


Yeah, cuda on bitcrack has this interesting problem on the new drivers. Will try with line info later, was just doing a quick run of your repo.

Neat idea. I might give that a go and submit a pull request or fork BitCrack with that function. It should be possible.

Edit: my repo is at https://github.com/bitcoinforktech/BitCrack.git which will have some updates in the next few days.

But it should be possible to brute-force bc1 addresses since those also use private keys, if that's not implemented that'll make yet another good science fair project or even a Google Summer of Code project  

So what is your speed with 3090? If it's not doubling a 2080Ti, is it worth it? Meaning, it's great that it runs, but is it running as it should be, MH/s wise? I've only found one program that truly utilizes the new 30xx cards, on windows; but source code is not available.

if I understood correctly you have P2SH addresses in the list
they start with "3"
BitCrack does not accept them

Thanks for the link, I read up on the known issue. I then performed the test with the provided list of 18 addresses using Win64 + clbitcrack + 3090 + CUDA 11.2 and it found all keys in the list.

https://github.com/brichard19/BitCrack/issues/81
this was the main reason i said that, besides you can test it out easily if it works o.o.t.b.

I didn't change the compute_cap value and was still able to compile cubitcrack on windows simply by updating the references to CUDA 10.1 to 11.2 and making sure project resources were in the correct locations. I'm not able to actually run it because of the "misaligned address" error, so I am using clbitcrack instead until someone is able to fix cubitcrack and allow it to run again with CUDA 11.2+.

In the meantime, what issues should I expect clbitcrack to have running on Windows? I'm not working with any P2SH addresses. What other issues would cause clbitcrack to not find a private key, as @yoyodapro mentioned?

I didn't change the compute_cap value and was still able to compile cubitcrack on windows simply by updating the references to CUDA 10.1 to 11.2 and making sure project resources were in the correct locations. I'm not able to actually run it because of the "misaligned address" error, so I am using clbitcrack instead until someone is able to fix cubitcrack and allow it to run again with CUDA 11.2+.

In the meantime, what issues should I expect clbitcrack to have running on Windows? I'm not working with any P2SH addresses. What other issues would cause clbitcrack to not find a private key, as @yoyodapro mentioned?

clbitcrack has always had issues, still does, and did you change the compute_cap in your makefile,
otherwise compiling the cubitcrack won't succeed. even if succeeded won't work with your hardware.
change it accordingly to your hardware.

Apologize for the late reply to this comment, but @yoyodapro, what "multiplication issue" are you referring to? I've read this entire thread and do not recall an issue like that being mentioned. While I am using a 3090, I was able to compile the current build of bitcrack against CUDA 11.2 but updating the references from CUDA 10.1 to 11.2. While cubitcrack still gives the misaligned address error, clbitcrack seems to work fine, albeit at a slower rate. But curious what issue you are referring to so I can understand how it may or may not affect what I am working on.

I have compiled cuBitCrack using CUDA 11.2, confirmed working on 2080, 2080ti, and 3070 without the multiplication issue preventing private keys from being found.

Can anyone help me create a windows binary?

https://github.com/yoyodapro/BitCrack/releases/tag/v11.2-alpha

See this message. Some function is feeding bad pointers to batchBeginAdd() and batchBeginAddWithDouble(), and these are passed to MulModP() --> copyBigInt() to the point where array access of either of copyBigInt() parameters generates athe Misaligned Access exception everyone here is getting.

It might be something in host code that's giving batchBeginAdd some pointer that's incremented by 1 and not aligned or something. I didn't get a chance to check.