Bitcoin puzzle transaction ~32 BTC prize to who solves it

[nomachine]

I#ve just found that Cyclone wrongly reads the ranges from file and/or changee them.
For example, I have small ranges with an amplitude of 0x1000000 and Cyclone changes the ranges to an amplitude of 0x10000000000

- Fixed range parsing in `readRangesFromFile`:
  - Normalized hex values to uppercase.
  - Removed whitespace from ranges.
  - Added hex character validation.
  - Resolved discrepancies between file and direct input.

./Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -f list.txt -t 1 -b 5 -S

================= WORK IN PROGRESS =================
Puzzle/Bits   : 29
Target Hash160: e0b8a2baee1b77fc703455f39d51477451fc8cfc
Prefix length : 5 bytes
Mode          : Sequential
CPU Threads   : 1
Mkeys/s       : 4.44
Total Checked : 88743936
Elapsed Time  : 00:00:20
Range         : af6e3791fc0000000:af6e3791fcfffffff
Progress      : 33.059692 %
Progress Save : 0
Stride        : 1
^C

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

[E36cat]

I#ve just found that Cyclone wrongly reads the ranges from file and/or changee them.
For example, I have small ranges with an amplitude of 0x1000000 and Cyclone changes the ranges to an amplitude of 0x10000000000

- Fixed range parsing in `readRangesFromFile`:
  - Normalized hex values to uppercase.
  - Removed whitespace from ranges.
  - Added hex character validation.
  - Resolved discrepancies between file and direct input.

./Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -f list.txt -t 1 -b 5 -S

================= WORK IN PROGRESS =================
Puzzle/Bits   : 29
Target Hash160: e0b8a2baee1b77fc703455f39d51477451fc8cfc
Prefix length : 5 bytes
Mode          : Sequential
CPU Threads   : 1
Mkeys/s       : 4.44
Total Checked : 88743936
Elapsed Time  : 00:00:20
Range         : af6e3791fc0000000:af6e3791fcfffffff
Progress      : 33.059692 %
Progress Save : 0
Stride        : 1
^C

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

First of all congratulations and thank you for the work put into Cyclone.

Illegal instruction (core dumped)
root@evelk-ThinkPad-T430s:~/.a/Cyclone# ./Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -r b07003137ec6788df:b0733313986012278 -b 6

I am getting this core dumped error only on some laptop models (could be that they have old processors?)
On others Cyclone starts without problems (same operating system ubuntu 18 on all of them)
Thanks in advance

[deep_seek]

I#ve just found that Cyclone wrongly reads the ranges from file and/or changee them.
For example, I have small ranges with an amplitude of 0x1000000 and Cyclone changes the ranges to an amplitude of 0x10000000000

- Fixed range parsing in `readRangesFromFile`:
  - Normalized hex values to uppercase.
  - Removed whitespace from ranges.
  - Added hex character validation.
  - Resolved discrepancies between file and direct input.

./Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -f list.txt -t 1 -b 5 -S

================= WORK IN PROGRESS =================
Puzzle/Bits   : 29
Target Hash160: e0b8a2baee1b77fc703455f39d51477451fc8cfc
Prefix length : 5 bytes
Mode          : Sequential
CPU Threads   : 1
Mkeys/s       : 4.44
Total Checked : 88743936
Elapsed Time  : 00:00:20
Range         : af6e3791fc0000000:af6e3791fcfffffff
Progress      : 33.059692 %
Progress Save : 0
Stride        : 1
^C

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

What do you mean by this stride? Is it working here? By default, it makes sense in a sequential search, but does the function still work if we increase it?

[kTimesG]

Hey Puzzler, I'm working on a lottery-style Puzzle 68. Got any good ideas for the first 4 digits?

I can hash the rest over the course of a week😅

which means I'm basically taking 1 in 32,768 lottery tickets every week 😅

Or less than 12 hours with a 8x RTX 4090 rig.

Your lottery ticket costs 35 $, and anyone can buy it. Or are you looking for someone to give you as a clue a range they already scanned?

[nomachine]

Illegal instruction (core dumped)
root@evelk-ThinkPad-T430s:~/.a/Cyclone# ./Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -r b07003137ec6788df:b0733313986012278 -b 6

I am getting this core dumped error only on some laptop models (could be that they have old processors?)
On others Cyclone starts without problems (same operating system ubuntu 18 on all of them)
Thanks in advance

If you have a processor that does not support AVX2, it will not work.

What do you mean by this stride? Is it working here? By default, it makes sense in a sequential search, but does the function still work if we increase it?

This means that the default stride is 1. It can be increased, I think, to 2000000000. It doesn't work beyond that value.

[Akito S. M. Hosana]

This means that the default stride is 1. It can be increased, I think, to 2000000000. It doesn't work beyond that value.

Why ? 

[nomachine]

This means that the default stride is 1. It can be increased, I think, to 2000000000. It doesn't work beyond that value.

Why ? 

Because the type used for Int is uint32_t, you can use a larger data type, such as int64_t:

Int step;
step.SetInt64(stride);
privateKey.Add(&step);

However, I’m not responsible for what happens after that.

The script processes keys in batches (e.g., POINTS_BATCH_SIZE). A large stride might cause the batch size to be exceeded, leading to incomplete or incorrect processing, progress calculation or even crashing the entire program.

That’s why I don’t like to mess with other people’s scripts. It’s easier for me to rebuild a new one from scratch than to try to support someone else’s script that works in a way they think is well-designed.

[POD5]

- Fixed range parsing in `readRangesFromFile`:
  - Normalized hex values to uppercase.
  - Removed whitespace from ranges.
  - Added hex character validation.
  - Resolved discrepancies between file and direct input.

Thanks! Was using some .SH instead...   

Code:

dos2unix unscanned.txt

or

sed -i 's/\r$//' unscanned.txt

[singlethread1]

However, I’m not responsible for what happens after that.

The script processes keys in batches (e.g., POINTS_BATCH_SIZE). A large stride might cause the batch size to be exceeded, leading to incomplete or incorrect processing, progress calculation or even crashing the entire program.

That’s why I don’t like to mess with other people’s scripts. It’s easier for me to rebuild a new one from scratch than to try to support someone else’s script that works in a way they think is well-designed.

Hey nomachine, maybe you already mentioned this in an earlier message, and if so I apologize. Why am I getting almost twice the MKeys/s with your program than I get with the original Cyclone program? Have you optimized for this much of a speed increase, or am I doing something wrong? Thanks!

[nomachine]

However, I’m not responsible for what happens after that.

The script processes keys in batches (e.g., POINTS_BATCH_SIZE). A large stride might cause the batch size to be exceeded, leading to incomplete or incorrect processing, progress calculation or even crashing the entire program.

That’s why I don’t like to mess with other people’s scripts. It’s easier for me to rebuild a new one from scratch than to try to support someone else’s script that works in a way they think is well-designed.

Hey nomachine, maybe you already mentioned this in an earlier message, and if so I apologize. Why am I getting almost twice the MKeys/s with your program than I get with the original Cyclone program? Have you optimized for this much of a speed increase, or am I doing something wrong? Thanks!

Which version and from where? Use the latest version from GitHub. It doesn’t go beyond 4.80 Mkeys/s  per core, which is the same as in the original version.

================= WORK IN PROGRESS =================
Puzzle/Bits   : 68
Target Hash160: e0b8a2baee1b77fc703455f39d51477451fc8cfc
Prefix length : 5 bytes
Mode          : Random
CPU Threads   : 1
Mkeys/s       : 4.80
Total Checked : 110313472
Elapsed Time  : ∞
Range         : 80000000000000000:fffffffffffffffff
Progress      : ∞
Progress Save : 0
Stride        : 1

[Akito S. M. Hosana]

Which version and from where? Use the latest version from GitHub. It doesn’t go beyond 4.80 Mkeys/s  per core, which is the same as in the original version.

I am getting 4.61 Mkeys/s on Linux and 4.70 Mkeys/s (CPU Threads: 1) on Windows on the same machine with the latest version. 

[nomachine]

Which version and from where? Use the latest version from GitHub. It doesn’t go beyond 4.80 Mkeys/s  per core, which is the same as in the original version.

I am getting 4.61 Mkeys/s on Linux and 4.70 Mkeys/s (CPU Threads: 1) on Windows on the same machine with the latest version.  

The compiler used on Windows might be different from the one used on Linux. Different compilers can produce code with varying levels of optimization, which can impact performance.

I am achieving 6 Mkeys/s per core with /opt/AMD/aocc-compiler-5.0.0/bin/clang++.

AOCC is specifically optimized for AMD hardware and can leverage AMD-specific features and instructions to deliver better performance.

The actual (EC) throughput with AOCC (clang) is between 10 Mkeys/s and 12 Mkeys/s per core, using the raw Bitcoin Core secp256k1 library without any hashing. You can't go faster than that on a CPU.

[kTimesG]

The actual (EC) throughput with AOCC (clang) is between 10 Mkeys/s and 12 Mkeys/s per core, using the raw Bitcoin Core secp256k1 library without any hashing. You can't go faster than that on a CPU.

What's the frequency of a single core?

Are you doing affine (not jacobian) batched addition, using the secp256k1_fe_* primitives? And the P (+ - ) Q trick?

[POD5]

Which version and from where? Use the latest version from GitHub. It doesn’t go beyond 4.80 Mkeys/s  per core, which is the same as in the original version.

I am getting 4.61 Mkeys/s on Linux and 4.70 Mkeys/s (CPU Threads: 1) on Windows on the same machine with the latest version.  

The compiler used on Windows might be different from the one used on Linux. Different compilers can produce code with varying levels of optimization, which can impact performance.

I am achieving 6 Mkeys/s per core with /opt/AMD/aocc-compiler-5.0.0/bin/clang++.

AOCC is specifically optimized for AMD hardware and can leverage AMD-specific features and instructions to deliver better performance.

The actual (EC) throughput with AOCC (clang) is between 10 Mkeys/s and 12 Mkeys/s per core, using the raw Bitcoin Core secp256k1 library without any hashing. You can't go faster than that on a CPU.

What is the behaviour of RANDOM?
4,6 Mk /s ? Or is there a minimal sequence N = X to be filled at each random key?

[nomachine]

What is the behaviour of RANDOM?
4,6 Mk /s ? Or is there a minimal sequence N = X to be filled at each random key?

RANDOM mode does not enforce any sequence or minimal number of keys to generate before checking. Each key is generated and checked independently.

The program does not enforce any specific sequence or pattern in the keys it generates. It relies on the randomness of the PRNG to explore the key space uniformly.

The program processes keys in batches of 512 (2 × 256) to optimize performance using AVX2 instructions for hashing.

Progress and elapsed time are not calculated in RANDOM mode.

The speed of 4.6 Mkeys/s per core is achievable with AVX2 optimizations, but it depends on the hardware.

What's the frequency of a single core?

Are you doing affine (not jacobian) batched addition, using the secp256k1_fe_* primitives? And the P (+ - ) Q trick?

7985WX has a base clock frequency of 3.2 GHz and a maximum boost clock frequency of up to 5.1 GHz for a single core, depending on workload and thermal conditions.

Yes, I am using affine coordinates for batched addition, as it is more efficient for certain operations.


I am going fishing today.

[Akito S. M. Hosana]

Why am I feeling pain in my brain after this informations?   

[kTimesG]

7985WX has a base clock frequency of 3.2 GHz and a maximum boost clock frequency of up to 5.1 GHz for a single core, depending on workload and thermal conditions.

Yes, I am using affine coordinates for batched addition, as it is more efficient for certain operations.

That's weird. I have over 17 MK/s per core on a Laptop CPU: i9 13900H and it's only running at 3 GHz.

This with a batch size of 512 constant elements, adding a single point (middle) left and right in a range of 1025. Higher batch sizes have diminishing returns, below measurable.

This is futile though, since the hashing is the bottleneck, it will never matter if the EC throughput increases.

Let's assume we can hash at 6 MH/s per core.

With 12 MK/s EC throughput/core, we end up with (12 * 6) / (12 + 6) = 4.0 M op/s
With 24 MK/s EC throughput/core, we end up with (24 * 6) / (24 + 6) = 4.8 M op/s
With 100 MK/s EC throughput/core, we end up with (100 * 6) / (100 + 6) = 5.66 M op/s

etc...

[POD5]

RANDOM mode does not enforce any sequence or minimal number of keys to generate before checking. Each key is generated and checked independently.

The program does not enforce any specific sequence or pattern in the keys it generates. It relies on the randomness of the PRNG to explore the key space uniformly.

The program processes keys in batches of 512 (2 × 256) to optimize performance using AVX2 instructions for hashing.

Progress and elapsed time are not calculated in RANDOM mode.

The speed of 4.6 Mkeys/s per core is achievable with AVX2 optimizations, but it depends on the hardware.

What's the frequency of a single core?

Are you doing affine (not jacobian) batched addition, using the secp256k1_fe_* primitives? And the P (+ - ) Q trick?

That is, if the programm shows 4 M keys second in RND mode, there were generated 4 M random keys?

[nomachine]

That's weird.

I am currently using and testing AVX-256(for these headache sufferers), and it is slower than AVX-512 by half. The AVX-256 workload here can cause the CPU to downclock significantly, which might negate the performance gains from vectorization. The CPU is throttling as a result.

Why am I feeling pain in my brain after this informations?    

Your brain is like that one friend who loves drama but can’t feel it themselves. It’s sitting there going, ‘Oh no, the nerves and muscles around me are freaking out! Better make you feel like your head’s exploding!’ But your brain? Totally chill, no pain receptors, just vibes. So when your head hurts, blame the drama queens around your brain, not the brain itself.  

[b0dre]

What is the behaviour of RANDOM?
4,6 Mk /s ? Or is there a minimal sequence N = X to be filled at each random key?

RANDOM mode does not enforce any sequence or minimal number of keys to generate before checking. Each key is generated and checked independently.

The program does not enforce any specific sequence or pattern in the keys it generates. It relies on the randomness of the PRNG to explore the key space uniformly.

The program processes keys in batches of 512 (2 × 256) to optimize performance using AVX2 instructions for hashing.

Progress and elapsed time are not calculated in RANDOM mode.

The speed of 4.6 Mkeys/s per core is achievable with AVX2 optimizations, but it depends on the hardware.

What's the frequency of a single core?

Are you doing affine (not jacobian) batched addition, using the secp256k1_fe_* primitives? And the P (+ - ) Q trick?

7985WX has a base clock frequency of 3.2 GHz and a maximum boost clock frequency of up to 5.1 GHz for a single core, depending on workload and thermal conditions.

Yes, I am using affine coordinates for batched addition, as it is more efficient for certain operations.


I am going fishing today.

The random mode is out of range.

Code:

./Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -r e0000000000000000:e0fffff0000000000 -b 4 -t 10 -R
================= WORK IN PROGRESS =================
Puzzle/Bits   : 60
Target Hash160: e0b8a2baee1b77fc703455f39d51477451fc8cfc
Prefix length : 4 bytes
Mode          : Random
CPU Threads   : 10
Mkeys/s       : 33.77
Total Checked : 1181870080
Elapsed Time  : ∞
Range         : e0000000000000000:e0fffff0000000000
Progress      : ∞
Progress Save : 0
Stride        : 1
================== PARTIAL MATCH FOUND! ============
Prefix length : 4 bytes
Private Key   : 0000000000000000000000000000000000000000000000000D2B2956A4A96991
Public Key    : 02B4C83F6D2BD1173A475ECA4AC4D1BF83F3EEE5830D79268A17AA881FEDACC4DB
Found Hash160 : e0b8a2ba6bac9c314858584c83768e38d2cfe956
Target Hash160: e0b8a2baee1b77fc703455f39d51477451fc8cfc
Matched bytes : e0b8a2ba