Bitcoin puzzle transaction ~32 BTC prize to who solves it

[neoman602]

the advantage is the ability to reach areas where random or sequential will never reach, and each base random number should be pass through transformations, that way is much more powerful

and that includes:

1) binary shifting(depending on the binary string length)
2) hex rotation(or in a binary format)
3) binary reversion
4) binary inversion

this are the 4 basic transforms that perform in nested loops and that no collision and give unique results

you cannot hit the target directly, but you can reach its transformed form

What do you mean by areas that the sequential method can never reach?

in a huge space, there are places where random never reaches....or will reach in a hundred years...

if you do tests, you will see what i am talking about

Damn. Seemed kinda cool until you said that. You lost me there buddy. Please explain.

Its not like flipping a coin, expecting close to a 50/50 EV and not accounting for it landing on its side.

lets say we search a private key of "1abcdef555"

we can go random, and at some point randomize a hex private key like "2bcdef0666"

and we do a rotation downwards

--------------------------

2bcdef0666

|
v

1abcdef555


--------------------------

so each hex char have 16 options from 0 to F

there are 16 different private keys, hitting one of them we do a 16 times rotation of each char and hit the target private key hex

so:

           1 A B C D E F 5 5 5
           ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
           2 B C D E F 0 6 6 6
           3 C D E F 0 1 7 7 7
           4 D E F 0 1 2 8 8 8
           5 E F 0 1 2 3 9 9 9
           6 F 0 1 2 3 4 A A A
           7 0 1 2 3 4 5 B B B
           8 1 2 3 4 5 6 C C C
           9 2 3 4 5 6 7 D D D - and here we hit the private key we search for
           A 3 4 5 6 7 8 E E E
           B 4 5 6 7 8 9 F F F
           C 5 6 7 8 9 A 0 0 0
           D 6 7 8 9 A B 1 1 1
           E 7 8 9 A B C 2 2 2
           F 8 9 A B C D 3 3 3
           0 9 A B C D E 4 4 4
           1 A B C D E F 5 5 5 ← back to original

so i call this a "mirror" of a private key

we can also reverse the hex and do the same

16 vertical rotations + 16 reversed vertical rotations = 32 different private keys hitting which we hit directly the private key hex

this is on vertical

its easy to understand, but how about if we do the same on a "horizontal" shift, depending on the hex length we do a shift by 1 hex char in a cycle so:

abc -> bca -> cab -> abc

this gives us another amount of mirrors (depending on the private key hex length)

so there are "vertical" and "horizontal" mirrors

but wait, how about if we reverse them and do the same? even more mirrors

oh i almost forgot...if we do a binary inversion and repeat the process this doubles the amount of "mirror" keys

do you think by doing this kind of "operations" there is a tiny chance of hitting something?

so i combined all of these in a nested loops

I did a simple python script on CPU to understand this: https://github.com/puzzleman22/Bitcoin-puzzle-transformations-CPU

also a GPU implementation: https://github.com/puzzleman22/Bitcoin-puzzle-transformations-CPU

its not so fast, because of the transformation operations that create a big divergence between threads on GPU, but it does the "thing"

you can try to use this idea on full range or on bitcoin puzzles

its not random, its not sequential, its a 3D search in the whole space, by applying full transformations

and with enough computational power this can be quite effective

in a binary format its even more accurate, cause it can hit tiny pieces

on hex format is faster, but less flexible


YOU CANNOT HIT THE PRIVATE KEY DIRECTLY, BUT YOU CAN HIT ITS "MIRRORS"

[cctv5go]

Seven words remain to solve the puzzle 17+7 = 24 word

That's approximately 4.79 billion years.

You have a much better chance of solving a WIF (Wallet Import Format) key that is missing the last 12–14 characters than cracking anything related to BIP39. Related processes (like PBKDF2) are intentionally slow to resist attacks.

https://github.com/AlexanderKud/WIF-Cracker_NoMachine

Can the teacher compile the GPU version? This looks good.

[teguh54321]

wtf i try the nvidia h200 and is just doing 2.8–3.0 billion keys/sec i was expecting more how can i gpu of  $31,000 to $32,000 do such low or im doing something wrong??

H200 gpu win on vram and efficiency watt.  But for cracking better 5090

[analyticnomad]

the advantage is the ability to reach areas where random or sequential will never reach, and each base random number should be pass through transformations, that way is much more powerful

and that includes:

1) binary shifting(depending on the binary string length)
2) hex rotation(or in a binary format)
3) binary reversion
4) binary inversion

this are the 4 basic transforms that perform in nested loops and that no collision and give unique results

you cannot hit the target directly, but you can reach its transformed form

What do you mean by areas that the sequential method can never reach?

in a huge space, there are places where random never reaches....or will reach in a hundred years...

if you do tests, you will see what i am talking about

Damn. Seemed kinda cool until you said that. You lost me there buddy. Please explain.

Its not like flipping a coin, expecting close to a 50/50 EV and not accounting for it landing on its side.

lets say we search a private key of "1abcdef555"

we can go random, and at some point randomize a hex private key like "2bcdef0666"

and we do a rotation downwards

--------------------------

2bcdef0666

|
v

1abcdef555


--------------------------

so each hex char have 16 options from 0 to F

there are 16 different private keys, hitting one of them we do a 16 times rotation of each char and hit the target private key hex

so:

           1 A B C D E F 5 5 5
           ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
           2 B C D E F 0 6 6 6
           3 C D E F 0 1 7 7 7
           4 D E F 0 1 2 8 8 8
           5 E F 0 1 2 3 9 9 9
           6 F 0 1 2 3 4 A A A
           7 0 1 2 3 4 5 B B B
           8 1 2 3 4 5 6 C C C
           9 2 3 4 5 6 7 D D D - and here we hit the private key we search for
           A 3 4 5 6 7 8 E E E
           B 4 5 6 7 8 9 F F F
           C 5 6 7 8 9 A 0 0 0
           D 6 7 8 9 A B 1 1 1
           E 7 8 9 A B C 2 2 2
           F 8 9 A B C D 3 3 3
           0 9 A B C D E 4 4 4
           1 A B C D E F 5 5 5 ← back to original

so i call this a "mirror" of a private key

we can also reverse the hex and do the same

16 vertical rotations + 16 reversed vertical rotations = 32 different private keys hitting which we hit directly the private key hex

this is on vertical

its easy to understand, but how about if we do the same on a "horizontal" shift, depending on the hex length we do a shift by 1 hex char in a cycle so:

abc -> bca -> cab -> abc

this gives us another amount of mirrors (depending on the private key hex length)

so there are "vertical" and "horizontal" mirrors

but wait, how about if we reverse them and do the same? even more mirrors

oh i almost forgot...if we do a binary inversion and repeat the process this doubles the amount of "mirror" keys

do you think by doing this kind of "operations" there is a tiny chance of hitting something?

so i combined all of these in a nested loops

I did a simple python script on CPU to understand this: https://github.com/puzzleman22/Bitcoin-puzzle-transformations-CPU

also a GPU implementation: https://github.com/puzzleman22/Bitcoin-puzzle-transformations-CPU

its not so fast, because of the transformation operations that create a big divergence between threads on GPU, but it does the "thing"

you can try to use this idea on full range or on bitcoin puzzles

its not random, its not sequential, its a 3D search in the whole space, by applying full transformations

and with enough computational power this can be quite effective

in a binary format its even more accurate, cause it can hit tiny pieces

on hex format is faster, but less flexible


YOU CANNOT HIT THE PRIVATE KEY DIRECTLY, BUT YOU CAN HIT ITS "MIRRORS"

I see what you mean about rotating, vertical, horizontal, and reversing now. I'm wondering if the cost of computational speed is worth the mangling of every random key and/or does it just complicate things by the factor of whatever additional operations were added.

In the end, random is random and we're talking about quintillions of keys. I like the approach, though. At least its not vanity searching.

[oddstake]

I am also running 135 puzzles, and using bsgs to run some old lost mining addresses. I have been running for more than half a year in total, but I haven't earned a penny. Haha, I wish you good luck.

Are you using BSGS random to break a 256-bit Bitcoin address where the length of a private key is 64 characters long?   That's wasted energy and resources. Even puzzle 135 is almost impossible to crack by using BSGS random where the prv key is having only 34 chars in length.  
Good luck though, I'm currently scanning puzzle 135,  bsgs random with 260 exakeys/s and almost giving up.

Code:

[+] Random mode
[+] Stats output every 1 seconds
[+] Mode BSGS random
[+] Opening file 135.txt
[+] Added 1 points from file
[+] Range
[+] -- from : 0x4000000000000000000000000000000000
[+] -- to   : 0x4fffffffffffffffffffffffffffffffff
[+] N = 0x1000000000000
[+] Bloom filter for 274877906944 elements : 942249.56 MB
[+] Bloom filter for 8589934592 elements : 29445.30 MB
[+] Bloom filter for 268435456 elements : 920.17 MB
[+] Allocating 4096.00 MB for 268435456 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_274877906944.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_8589934592.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_268435456.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_268435456.blm .... Done!
[+] Thread 0x4d0c36d8ff9468cc14ad1e038410891c47  conds: ~260 Ekeys/s (260967284607849559562 keys/s)

The 'Stats output every 1 seconds' give you wrong speed, to know the actual speed set the output to at least 10 seconds ( -s 10)

Nope, the speed is correct, changing to -s 10 or even -q doesn't influence the speed too much .

[vvSaKvv]

I am also running 135 puzzles, and using bsgs to run some old lost mining addresses. I have been running for more than half a year in total, but I haven't earned a penny. Haha, I wish you good luck.

Are you using BSGS random to break a 256-bit Bitcoin address where the length of a private key is 64 characters long?   That's wasted energy and resources. Even puzzle 135 is almost impossible to crack by using BSGS random where the prv key is having only 34 chars in length.  
Good luck though, I'm currently scanning puzzle 135,  bsgs random with 260 exakeys/s and almost giving up.

Code:

[+] Random mode
[+] Stats output every 1 seconds
[+] Mode BSGS random
[+] Opening file 135.txt
[+] Added 1 points from file
[+] Range
[+] -- from : 0x4000000000000000000000000000000000
[+] -- to   : 0x4fffffffffffffffffffffffffffffffff
[+] N = 0x1000000000000
[+] Bloom filter for 274877906944 elements : 942249.56 MB
[+] Bloom filter for 8589934592 elements : 29445.30 MB
[+] Bloom filter for 268435456 elements : 920.17 MB
[+] Allocating 4096.00 MB for 268435456 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_274877906944.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_8589934592.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_268435456.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_268435456.blm .... Done!
[+] Thread 0x4d0c36d8ff9468cc14ad1e038410891c47  conds: ~260 Ekeys/s (260967284607849559562 keys/s)

The 'Stats output every 1 seconds' give you wrong speed, to know the actual speed set the output to at least 10 seconds ( -s 10)

Nope, the speed is correct, changing to -s 10 or even -q doesn't influence the speed too much .

Totally agree, #135 using BSGS will take million years to crack. I went further and changes JLP vanitysearch, that it will calculate 2^30 precomputed table and run that in each thread against public key using bloomfilter, using symmetry and 8x 4090 can do 48 billion of 2^31 ranges per seacond, and that will take millions of years to go through 135 bits. I think BSGS at this stage is useless.

[viljy]

Good luck though, I'm currently scanning puzzle 135,  bsgs random with 260 exakeys/s and almost giving up.

Isn't this speed of 260 Ekeys/s the speed of checking keys through a bloom filter? The key generation rate is much lower. Is it so?

[oddstake]

Totally agree, #135 using BSGS will take million years to crack. I went further and changes JLP vanitysearch, that it will calculate 2^30 precomputed table and run that in each thread against public key using bloomfilter, using symmetry and 8x 4090 can do 48 billion of 2^31 ranges per seacond, and that will take millions of years to go through 135 bits. I think BSGS at this stage is useless.

So if your 8x 4090 can do 48 billion of 2^31 ranges per second (equal with 103,079,215,104,000,000,000 keys per second) it means your hardware is X2 slower than an AMD EPYC 64 cores + 1T RAM , running on BSGS random, doing 260,949,667,359,921,111,308 keys per second. Indeed, random is random, can never hit the private key especially on bigger ranges, while sequential search is a guarantee.

[oddstake]

Isn't this speed of 260 Ekeys/s the speed of checking keys through a bloom filter? The key generation rate is much lower. Is it so?

Yes, checking keys through a bloom filter which is loaded into RAM of about 1T in size. 

[kTimesG]

I'm wondering if the cost of computational speed is worth the mangling of every random key and/or does it just complicate things by the factor of whatever additional operations were added.

No need to wonder, it's obviously just another complicated way to slow down the search.

There is a bounty of 0.1 BTC for whoever speeds up the currently best known method of solving (and actually proves it, instead of fantasizing), but there isn't one for whoever manages to slow it down.

As a reminder, the fastest and most efficient way to solve any address-only puzzle is pretty simple:

- scan ranges sequentially (doesn't really matter how you pick the ranges, as long as you take care not to pick a range that was already scanned, which is trivial)
- halt when the key was found.

Whatever is being added on top of this can only have one single possible effect: slow down the process. Whoever doesn't agree should be reminded that there's a 0.1 BTC reward if they prove the contrary. Personally, I'd say it's a waste of time to even attempt, but this conclusion is formed by professional experience, so anyone is free to do what they want with their time and life. If brute-forcing is proven to be sped up by classical computing, then the consequences are far beyond we might ever imagine.

[Jorge54PT]

This is nothing new, and I've asked this question several times, and no satisfactory answer has been given in the forum. And it doesn't require coding, all calculations can be done with a calculator.
5HpHagT65TZzG1PH3CSu63k8DbpvM6sdcMk3rQ8hVnTJAphn1wQ
5Km2kuu7vtFDPpxywn4u3NLpbr5jTnTiwHZAqh7Go9SJu8y7XMR
1FAiLLQsUoJwVYeYPUuoceyAyNVENv3b5w

L5oLkpV3aqBjhki6LmvChTCV6odtRDex6c4zRv2gigEhzkSSVKEP
KwDiBf89QgGbjEhKnhXJuH7LrciWTivUb4Z1b36yk3d4nHheQ1AU
1PijtU6wcyyZYiPcjvTaRBbC6xMMkd5Cj

Why did you post these? You have WIFS/Private Keys that aren't in the curve. Maybe I am missing something.

´´Heklo friend WanderingPhilospher

Its possible you tell me wath diference i use or not the parameter in VBCr.exe  -r rekey? is better with rekey or dont use that paraneter? Any advantage if i use?  thank you so much  (my 3060 make 1070 Mkeys/s)

[Virtuose]

wtf i try the nvidia h200 and is just doing 2.8–3.0 billion keys/sec i was expecting more how can i gpu of  $31,000 to $32,000 do such low or im doing something wrong??

The H200 is optimized for AI and tensor workloads, not integer-heavy operations like secp256k1.
Most GPU bruteforce tools aren't tuned for Hopper architecture, so you're likely not using its full potential.

For this kind of task, RTX 4090 or 5090 performs better per dollar unless you write custom CUDA code optimized for H200.

[brainless]

wtf i try the nvidia h200 and is just doing 2.8–3.0 billion keys/sec i was expecting more how can i gpu of  $31,000 to $32,000 do such low or im doing something wrong??

The H200 is optimized for AI and tensor workloads, not integer-heavy operations like secp256k1.
Most GPU bruteforce tools aren't tuned for Hopper architecture, so you're likely not using its full potential.

For this kind of task, RTX 4090 or 5090 performs better per dollar unless you write custom CUDA code optimized for H200.

In my view h200 gpu is more powerful then 5090 gpu
Due to 140gb ram, not always hash calc, load of ram also calc and result would be 5 time higher then 24gb ram
He need adjust proper -b -p -t
If he reply if he need info about these setting for use h200 optimal speed...

[Virtuose]

wtf i try the nvidia h200 and is just doing 2.8–3.0 billion keys/sec i was expecting more how can i gpu of  $31,000 to $32,000 do such low or im doing something wrong??

The H200 is optimized for AI and tensor workloads, not integer-heavy operations like secp256k1.
Most GPU bruteforce tools aren't tuned for Hopper architecture, so you're likely not using its full potential.

For this kind of task, RTX 4090 or 5090 performs better per dollar unless you write custom CUDA code optimized for H200.

In my view h200 gpu is more powerful then 5090 gpu
Due to 140gb ram, not always hash calc, load of ram also calc and result would be 5 time higher then 24gb ram
He need adjust proper -b -p -t
If he reply if he need info about these setting for use h200 optimal speed...

That's true technically, but even with custom CUDA kernels, the H200 is not cost-effective for secp256k1 bruteforce.
You're paying $30k+ for AI-focused tensor performance, not INT32 throughput.

A few RTX 5090s will outperform it per watt, per dollar, and even in raw key/s with optimized tools. H200 is impressive, just not for this job.

[kTimesG]

In my view h200 gpu is more powerful then 5090 gpu
Due to 140gb ram, not always hash calc, load of ram also calc and result would be 5 time higher then 24gb ram

Maybe after you convince a book to read itself and present you the audio summary. Pretty much the same as what you said there.

Fastest code doesn't even use RAM, latency is too high, and guess what, it's not even needed, and if it unfortunately becomes needed, the speed drops. Like, big time. So, best practice is to limit to maximum any access to RAM. Having exabytes or zettabytes of it does not help with anything here (I hear the "bsgs" whispers, it is indeed a fantastic idea to do lookups in some memory-based huge table, after each EC point gets computed! It definitely won't go all over the place and add latencies).

[Tony8989]

true i few GeForce RTX 5090  will do the job for much less, the h200 is for Ai task using 4 RTX 5090  i can achieve  1_382_400_000_000_000  x day

for now i try few gpu

NVIDIA RTX A4000   818.15 MKey/s

GeForce RTX 5060 Ti  973.68 MKey/s

GeForce RTX 3080  1574.46

GeForce RTX 3060  656.09 MKey/s

GeForce RTX 3090 1324.28 MKey/s

GeForce RTX 4090   3061.96 MKey/s

GeForce RTX 4070 1286.45 MKey/s

GeForce RTX 5080  1988.08 MKey/s

GeForce RTX 3070  1014.12 MKey/s

NVIDIA RTX A5000  1338.56 MKey/s

GeForce RTX 5090  3956.87 MKey/s  top

GeForce RTX 4080 SUPER 1725.58 MKey/s

GeForce GTX 1070 119.88 MKey/s

NVIDIA H200 NVL  2871.53 MKey/s


any way to cut the key or skip consecutive number and letter smart way?


bro i try  -b -p -t  but
PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU -b 512 -t 512 -p 1090
[2025-08-03.19:30:45] [Info] Compression: compressed
[2025-08-03.19:30:45] [Info] Starting at: 00000000000000000000000000000000000000000000004EC2832F6F6B400000
[2025-08-03.19:30:45] [Info] Ending at:   00000000000000000000000000000000000000000000004EC2867589EDFFFFFF
[2025-08-03.19:30:45] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2025-08-03.19:30:45] [Info] Initializing NVIDIA H200 NVL
[2025-08-03.19:30:45] [Info] Generating 285,736,960 starting points (10900.0MB)
Segmentation fault


b 256 -t 256 -p 1090
[2025-08-03.19:28:31] [Info] Compression: compressed
[2025-08-03.19:28:31] [Info] Starting at: 00000000000000000000000000000000000000000000004EC2832F6F6B400000
[2025-08-03.19:28:31] [Info] Ending at:   00000000000000000000000000000000000000000000004EC2867589EDFFFFFF
[2025-08-03.19:28:31] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2025-08-03.19:28:31] [Info] Initializing NVIDIA H200 NVL
[2025-08-03.19:28:31] [Info] Generating 71,434,240 starting points (2725.0MB)
[2025-08-03.19:28:44] [Info] 10.0%
[2025-08-03.19:28:44] [Info] 20.0%
[2025-08-03.19:28:44] [Info] 30.0%
[2025-08-03.19:28:44] [Info] 40.0%
[2025-08-03.19:28:45] [Info] 50.0%
[2025-08-03.19:28:45] [Info] 60.0%
[2025-08-03.19:28:45] [Info] 70.0%
[2025-08-03.19:28:45] [Info] 80.0%
[2025-08-03.19:28:45] [Info] 90.0%
[2025-08-03.19:28:45] [Info] 100.0%
[2025-08-03.19:28:45] [Info] Done
NVIDIA H200 NVL  7070 / 143186MB | 1 target 2871.53 MKey/s

[2025-08-03.19:24:33] [Info] 80.0%
[2025-08-03.19:24:33] [Info] 90.0%
[2025-08-03.19:24:33] [Info] 100.0%
[2025-08-03.19:24:33] [Info] Done
[2025-08-03.19:24:33] [Info] Error: too many resources requested for launch

[brainless]

true i few GeForce RTX 5090  will do the job for much less, the h200 is for Ai task using 4 RTX 5090  i can achieve  1_382_400_000_000_000  x day

for now i try few gpu

NVIDIA RTX A4000   818.15 MKey/s

GeForce RTX 5060 Ti  973.68 MKey/s

GeForce RTX 3080  1574.46

GeForce RTX 3060  656.09 MKey/s

GeForce RTX 3090 1324.28 MKey/s

GeForce RTX 4090   3061.96 MKey/s

GeForce RTX 4070 1286.45 MKey/s

GeForce RTX 5080  1988.08 MKey/s

GeForce RTX 3070  1014.12 MKey/s

NVIDIA RTX A5000  1338.56 MKey/s

GeForce RTX 5090  3956.87 MKey/s  top

GeForce RTX 4080 SUPER 1725.58 MKey/s

GeForce GTX 1070 119.88 MKey/s

NVIDIA H200 NVL  2871.53 MKey/s


any way to cut the key or skip consecutive number and letter smart way?

What command you apply ?
And one same command for all gpu u tested ?
Or different command for above listed gpu
I am talking only about bitcrack

[Tony8989]

I used BitCrack with the same base command but manually tuned the -t, -b, and -p values for each GPU. I gradually increased these parameters until the GPU either crashed or was about to crash, then backed off slightly to get the maximum stable performance.

Someone in the group chat managed to push their RTX GPU to about 5356.87 MKey/s, which is higher than what I got. They were likely using a different GitHub project like KeyHunt-Cuda, which can sometimes achieve better raw speed. However, in my tests, I noticed that KeyHunt-Cuda occasionally skips some keys, especially with test/fake keys, which could lead to missing targets.

BitCrack, on the other hand, is very thorough and doesn't skip keys, so I prefer it for reliability, even if the speed is slightly lower

[brainless]

-b 132. -t 1024 - p 2048
-b 132. -t 1024 - p 1536
-b 132. -t 1024 - p 1024
-b 132. -t 1024 - p 512

-b 132. -t 512 - p 2048
-b 132. -t 512 - p 1536
-b 132. -t 512 - p 1024
-b 132. -t 512 - p 512

Start from top, one by one and tell me which one start working with ur h200

[Tony8989]

Bro Tried all these configs — all crash with too many resources requested for launch 

/bin/cuBitCrack --keyspace 5206e53083080a29e7:5206eef59f4d2c09e8 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU -b 132 -t 256 -p 6048
[2025-08-04.22:05:51] [Info] Compression: compressed
[2025-08-04.22:05:51] [Info] Starting at: 00000000000000000000000000000000000000000000005206E53083080A29E7
[2025-08-04.22:05:51] [Info] Ending at:   00000000000000000000000000000000000000000000005206EEF59F4D2C09E8
[2025-08-04.22:05:51] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2025-08-04.22:05:51] [Info] Initializing NVIDIA H200 NVL
[2025-08-04.22:05:51] [Info] Generating 204,374,016 starting points (7796.2MB)
[2025-08-04.22:06:30] [Info] 10.0%
[2025-08-04.22:06:31] [Info] 20.0%
[2025-08-04.22:06:31] [Info] 30.0%
[2025-08-04.22:06:32] [Info] 40.0%
[2025-08-04.22:06:32] [Info] 50.0%
[2025-08-04.22:06:32] [Info] 60.0%
[2025-08-04.22:06:32] [Info] 70.0%
[2025-08-04.22:06:32] [Info] 80.0%
[2025-08-04.22:06:33] [Info] 90.0%
[2025-08-04.22:06:33] [Info] 100.0%
[2025-08-04.22:06:33] [Info] Done
NVIDIA H200 NVL  19244 / 143156MB | 1 target 3079.91 MKey/s (11,444,944,896 total) [00:00:01]