Bitcoin puzzle transaction ~32 BTC prize to who solves it

[0x1FFFFFF]

How to edit VanitySearch by JLP to search in puzzle 71 space (not from 1)?

Anybody gone into c/c++ in this project?

https://i.ibb.co.com/fY2Y7CT0/Screenshot-2025-05-12-032148.png

I am currently working on it.. it works but still inconsistent, I'll post it when became stable

[Akito S. M. Hosana]

However, unless SECP256K1 itself is accelerated, it doesn't matter which program you use if it's based on JLP. Same shit.

What do you mean? I can't figure it out. Can you explain this better with a some practical example? 

[pbies]

by JLP

All programs based on SECP256K1 by JLP have very similar performance when running on a CPU. They operate at the same speed using the same function Point Secp256K1::ComputePublicKey(Int *privKey). Other components such as AVX SIMD hashing, bloom filters, the kangaroo algorithm, or the BSGS algorithm can speed up specific scripts. However, unless SECP256K1 itself is accelerated, it doesn't matter which program you use if it's based on JLP. Same shit.

I am trying to use it because it works on GPU.

[mjojo]

How to edit VanitySearch by JLP to search in puzzle 71 space (not from 1)?

Anybody gone into c/c++ in this project?

Try JLP VanitySearch forked by @allinbit and @Ilker, starting from ranges what you want.
https://github.com/ilkerccom/VanitySearch

[pbies]

How to edit VanitySearch by JLP to search in puzzle 71 space (not from 1)?

Anybody gone into c/c++ in this project?

Try JLP VanitySearch forked by @allinbit and @Ilker, starting from ranges what you want.
https://github.com/ilkerccom/VanitySearch

It hangs when given keyspace option.

[nomachine]

Can you explain this better with a some practical example? 

Here is a practical example:

https://github.com/NoMachine1/Cyclone/tree/main/PUB

No AVX2, no algorithm, nothing. Just raw Point and Public Key search. If you want it even faster, you have to brainstorm and work to change SECP256K1 and to science the shit out of this. 

[Akito S. M. Hosana]

Can you explain this better with a some practical example? 

Here is a practical example:

https://github.com/NoMachine1/Cyclone/tree/main/PUB

No AVX2, no algorithm, nothing. Just raw Point and Public Key search. If you want it even faster, you have to brainstorm and work to change SECP256K1 and to science the shit out of this. 

I have about 65 Mkeys/s here. This is about 20 Mkeys/s faster than the version with Hash 160 as the target. So -20 goes to hashing.

[pbies]

How to edit VanitySearch by JLP to search in puzzle 71 space (not from 1)?

Anybody gone into c/c++ in this project?

Try JLP VanitySearch forked by @allinbit and @Ilker, starting from ranges what you want.
https://github.com/ilkerccom/VanitySearch

It hangs when given keyspace option.

There was need to modify the code. Works fine now.

[mjojo]

How to edit VanitySearch by JLP to search in puzzle 71 space (not from 1)?

Anybody gone into c/c++ in this project?

Try JLP VanitySearch forked by @allinbit and @Ilker, starting from ranges what you want.
https://github.com/ilkerccom/VanitySearch

It hangs when given keyspace option.

There was need to modify the code. Works fine now.

No need modify, just change some line on makefile to matching with GPU type and CUDA version.

[pbies]

How to edit VanitySearch by JLP to search in puzzle 71 space (not from 1)?

Anybody gone into c/c++ in this project?

Try JLP VanitySearch forked by @allinbit and @Ilker, starting from ranges what you want.
https://github.com/ilkerccom/VanitySearch

It hangs when given keyspace option.

There was need to modify the code. Works fine now.

No need modify, just change some line on makefile to matching with GPU type and CUDA version.

No, there are obvious bugs in the code, like using scanf istead of sscanf.

[sxiclub]

How to edit VanitySearch by JLP to search in puzzle 71 space (not from 1)?

Anybody gone into c/c++ in this project?

Try JLP VanitySearch forked by @allinbit and @Ilker, starting from ranges what you want.
https://github.com/ilkerccom/VanitySearch

I tested it with puzzle 57, give wrong private key generated:

Code:

VanitySearch v1.16 Linux with BitCrack integration
[keyspace] start=                                                 1EB25C907000000
[keyspace]   end=                                                 1EB25C90795DFFF
Difficulty: 1461501637330902918203684832716283019655932542976
Search: 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz [Compressed]
Current task START time: Mon May 12 16:13:57 2025
Number of CPU thread: 0
GPU: GPU #0 NVIDIA GeForce RTX 2050 (16x128 cores) Grid(2048x256)
 
Warning, wrong private key generated !
  Addr :15c9mPGLku1HuW9LRtBf4jcHVpBUunRoQS
  Check:1MH9K9aeZNBvLoyRzk2pwfMwygM5hMjwgZ
  Endo:0 incr:540 comp:1
[EXIT] Range research completed (2^36.55) [00:01:06 RUN || END ...finishing][0]  
Current task END time: Mon May 12 16:15:05 2025

[brainless]

Can you explain this better with a some practical example? 

Here is a practical example:

https://github.com/NoMachine1/Cyclone/tree/main/PUB

No AVX2, no algorithm, nothing. Just raw Point and Public Key search. If you want it even faster, you have to brainstorm and work to change SECP256K1 and to science the shit out of this. 

Need multiple pubkeys load by file and  search...

[nomachine]

Need multiple pubkeys load by file and  search...

Why I never add a list of targets in any of my apps ?

When you’re searching for 1 target public key, your app only does 1 comparison per candidate key.

But if you’re searching for 10 target keys, now it’s gotta do 10 comparisons per candidate key.

This is called linear time complexity (O(n)), where:

n = number of target keys

Runtime scales directly with the number of keys

Here’s how different methods stack up:

Brute-Force (O(n)) = ~10x slower

Hash Prefix (O(1)) = ~3.5x slower

Bloom Filter (O(1)) = ~2.5x slower

Multi-Key AVX2 = ~5x slower

Even with AVX2, you still gotta loop through all targets:

cpp

Code:

for (int i = 0; i < 100; i++) {  
    __m256i target = load_key(targets[i]);  
    __m256i cmp = _mm256_cmpeq_epi8(candidate, target);  
    if (_mm256_movemask_epi8(cmp) == 0xFFFFFFFF) {  
        // Match found for targets[i]  
    }  
}  

100x more comparisons = 100x slower in the worst case.

Yeah, the CPU tries to predict the loop, but with 100 targets, it messes up more often, pipeline stalls happen.

[Akito S. M. Hosana]

Need multiple pubkeys load by file and  search...

Why I never add a list of targets in any of my apps ?

I have a list of about 1000 public keys. All are above 2BTC

[nomachine]

Need multiple pubkeys load by file and  search...

Why I never add a list of targets in any of my apps ?

I have a list of about 1000 public keys. All are above 2BTC

What range are they in, exactly? It's useless. Even if you know precisely how many bits each target is, if it's above 90 bits, it's useless.

[fixedpaul]

How to edit VanitySearch by JLP to search in puzzle 71 space (not from 1)?

Anybody gone into c/c++ in this project?

Try JLP VanitySearch forked by @allinbit and @Ilker, starting from ranges what you want.
https://github.com/ilkerccom/VanitySearch

It hangs when given keyspace option.

There was need to modify the code. Works fine now.

If you want in my GitHub you can find VanitySearch-bitcrack repo, 50% faster than these

[Bram24732]

Need multiple pubkeys load by file and  search...

Why I never add a list of targets in any of my apps ?

When you’re searching for 1 target public key, your app only does 1 comparison per candidate key.

But if you’re searching for 10 target keys, now it’s gotta do 10 comparisons per candidate key.

This is called linear time complexity (O(n)), where:

n = number of target keys

Runtime scales directly with the number of keys

Here’s how different methods stack up:

Brute-Force (O(n)) = ~10x slower

Hash Prefix (O(1)) = ~3.5x slower

Bloom Filter (O(1)) = ~2.5x slower

Multi-Key AVX2 = ~5x slower

Even with AVX2, you still gotta loop through all targets:

cpp

Code:

for (int i = 0; i < 100; i++) {  
    __m256i target = load_key(targets[i]);  
    __m256i cmp = _mm256_cmpeq_epi8(candidate, target);  
    if (_mm256_movemask_epi8(cmp) == 0xFFFFFFFF) {  
        // Match found for targets[i]  
    }  
}  

100x more comparisons = 100x slower in the worst case.

Yeah, the CPU tries to predict the loop, but with 100 targets, it messes up more often, pipeline stalls happen.

What’s your Bloomfilter implementation like ? 2.5x seems like a lot ?

[nomachine]

What’s your Bloomfilter implementation like ? 2.5x seems like a lot ?

My version, which is based on the Keyhunt version, didn’t work with more than 20 targets. What did work was either too slow or buggy, so I gave up on using the Bloomfilter altogether in brute-force puzzle apps.

[Akito S. M. Hosana]

so I gave up...

This is the first time someone has admitted they don’t know something while working on coding in this topic. Usually, everyone acts like they know everything. 

[nomachine]

Usually, everyone acts like they know everything. 

You've started trolling again, haven’t you?