Bitcoin puzzle transaction ~32 BTC prize to who solves it

[bcchanger]

The next thing I’m going to update is SECP256K1 itself—I’ve already removed some unnecessary files from Git

How fast can this go? 

For example, the Ryzen 9 7940HS achieves ~10 MK/s when using 1 thread and ~67 MK/s with 16 threads. Performance also depends on how it is compiled—using GCC, Clang, etc...

Any chance you could compile a Windows compatible version?

[nomachine]

Nope. It is not critical update for my version. Gradually, our scripts are starting to diverge in terms of functionality. The next thing I’m going to update is SECP256K1 itself—I’ve already removed some unnecessary files from Git, like Timer.cpp, Timer.h, Random.cpp, and Random.h. They were just collecting dust and serving no purpose, unnecessarily increasing the size of the executable file.

How many keys are scanned at once (batch = group_size) when using sequential or random mode? 0x10000? 0x100000?
This would be interesting to know, for example, when using STRIDE.
If I start at 0x400000000000000000 and STRIDE = 0x10000000 and BATCH = 0x10000, at the end of each round I just need to add
BATCH * Number of rounds to the start point 0x400000000000000000 (keeping the same STRIDE value)
The same principle of both python scripts that I had sent you in PM some weeks before.

That function has never worked here as it should. It just causes problems—either showing unrealistically high speeds or unrealistically low ones. I think I’ll remove it from the script altogether.

P.S. Removed the stride option—to avoid further confusion, since this option does nothing.

[Akito S. M. Hosana]

P.S. Removed the stride option—to avoid further confusion, since this option does nothing.

I think it's my fault. I asked for that option—to make it similar to Keyhunt. 

[nomachine]

P.S. Removed the stride option—to avoid further confusion, since this option does nothing.

I think it's my fault. I asked for that option—to make it similar to Keyhunt. 

But this isn’t even close to the same as Keyhunt. Here, you have batches of x8 AVX2 doing the work. Try implementing SHA-256 and RIPEMD-160 with 8x parallel processing in Keyhunt, and let me know what kind of confusion you get with the speed and counter calculations. And how did you solve the stride problem where everything is processed with 8x parallelism? 

[POD5]

P.S. Removed the stride option—to avoid further confusion, since this option does nothing.

I think it's my fault. I asked for that option—to make it similar to Keyhunt. 

STRIDE is also not working in KEYHUNT

nevertheless, the range file option is way better than stride...  

[nochkin]

- is there a way to prove that all of the above are unprovable?

I'm offering a 9000 trillion multiverse BTC bounty if someone proves that the last one is unprovable to be proven. Or something like that. Please no AI.

Easy-peasy. The answer to the proof is 42. Where is my reward?

[nomachine]

P.S. Removed the stride option—to avoid further confusion, since this option does nothing.

I think it's my fault. I asked for that option—to make it similar to Keyhunt. 

STRIDE is also not working in KEYHUNT

nevertheless, the range file option is way better than stride...  

It’s much easier to talk about a particular option than to make it work in practice. Better yet, how much time did you spend on it to actually make it work? I’d rather go fishing.  

[Akito S. M. Hosana]

I’d rather go fishing.  

Maybe you would have solved the puzzle if you hadn't gone fishing? 

[nochkin]

Maybe you would have solved the puzzle if you hadn't gone fishing? 

Not necessary. But if you go phishing instead of fishing, then it's definitely. Not nice though.

[FrozenThroneGuy]

P.S. Removed the stride option—to avoid further confusion, since this option does nothing.

I think it's my fault. I asked for that option—to make it similar to Keyhunt. 

STRIDE is also not working in KEYHUNT

nevertheless, the range file option is way better than stride...  

It’s much easier to talk about a particular option than to make it work in practice. Better yet, how much time did you spend on it to actually make it work? I’d rather go fishing.  

Hello NoMachine! Do you think about ShaNi intrinsic for speeding up SHA256? It is not so difficult like AVX Secp256k1, but it can speed up computing sha up to 2-3 times.
I was trying to do this, but the speed decrease from 6ns per hash to 150ns.

[kTimesG]

It's interesting to see how all sorts of complexities attempt to simplify the situation.

I guess it's now stride's week. How does it help? Well, it's boring to keep the algorithm straightforward. And it of course increases chances, since it's covering more terrain, I assume.

Code:

priv -> pub -> sha[0] -> rmd[0] -> check
[priv + 1] -> pub + G -> sha[1] -> rmd[1] -> check
...
{privs} -> {pubs batch} -> {shas} -> {rmds} -> check

Now, I have the ultimate maximum performance and speed method:

- compute k*G from 1 to 2**N / 2 (this is a one-time only step anyway)
- compute (2**(N-1) + k*(2**(N - 1) / 2))*G to get the middle key of the scan interval
- do a single batch addition to compute all the public keys of the interval; reuse the batched inverses (and you'll ever need a single inversion! wowza!)

Voila. At some point during the last step of this batch addition, you'll hit the key.

Genius. Don't thank me - script it!

[nomachine]

It is not so difficult like AVX Secp256k1

Yo, fam! If your code’s crawling at 150ns when it should be flying at 6ns, something’s off. AVX2’s 256-bit registers can handle 4 or 8 hashes at once like a pro. That W array expansion (the σ0/σ1 math) is begging for SIMD. sha256rnds2 goes brrr—like 5x faster than scalar.

You’re probably vectorizing just ONE hash instead of stacking 4-8 like pancakes. Double-check if you’re using the flags: -mavx2 -mbmi2 -madx -fwrapv.

Shoutout to the guy who nailed it:
https://github.com/ulhaocheng/avxecc

The core math is similar, just different numbers.

Key takeaways:

AVX2-optimized field multiplication (the slowest part of ECC).

Parallel limb ops (256-bit registers crunching 32/64-bit chunks).

Just tweak it for Secp256k1’s constants, and you’re golden

[Akito S. M. Hosana]

Shoutout to the guy who nailed it:
https://github.com/ulhaocheng/avxecc

Man, I’d way rather learn Chinese than mess with these crazy formulas from here:
https://sacworkshop.org/SAC20/files/preproceedings/27-HighThroughput.pdf

So, what's the idea here? To create a completely new form of AVX2-accelerated ECC from scratch with secp256k1 parameters?

 

[nomachine]

So, what's the idea here? To create a completely new form of AVX2-accelerated ECC from scratch with secp256k1 parameters?

It can’t be any other way. There is nothing similar using 'limb-slicing' published on GitHub.

[360videosro]

Besides bitcrack which wasn't updated for the last 5+ years,  is there any similar tool using the cuda GPU but to generate randomly within a range?

[kTimesG]

Shoutout to the guy who nailed it:
https://github.com/ulhaocheng/avxecc

Key takeaways:

AVX2-optimized field multiplication (the slowest part of ECC).

Parallel limb ops (256-bit registers crunching 32/64-bit chunks).

Just tweak it for Secp256k1’s constants, and you’re golden

I think you meant scalar multiplication there... which is basically a no-op if scanning ranges with sequential keys.

I bet libsecp256k1 is faster than that though, since it's already SIMD-ed by the compiler, because it uses carry-free independent limbs. That's like, free vectorization out of the box, less cycles / op, and so on.

Ideal for ending up with a fried CPU, which seems like it's what people want.

[nomachine]

Ideal for ending up with a fried CPU, which seems like it's what people want.

A fried CPU could indeed be the problem here.

[Akito S. M. Hosana]

Ideal for ending up with a fried CPU, which seems like it's what people want.

A fried CPU could indeed be the problem here.

What about the AOCC compiler that was mentioned earlier?

https://www.amd.com/en/developer/aocc.html

AOCC automatically converts scalar operations into SIMD instructions

[fixedpaul]

Besides bitcrack which wasn't updated for the last 5+ years,  is there any similar tool using the cuda GPU but to generate randomly within a range?

You can check my GitHub, VanitySearch-bitcrack has a random mode

[nomachine]

What about the AOCC compiler that was mentioned earlier?

https://www.amd.com/en/developer/aocc.html

AOCC automatically converts scalar operations into SIMD instructions

This is a great thing, but on one condition: all the code must be extremely pedantic. Even then, the CPU might overheat. You’ll need very good cooling.