Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Bram24732]

Wooow there is Mr. 67 68, perhaps we can call him the god of puzzles. With the power of 25K GPU in his hands, he is probably equal to Snap Tanos, who is able to wipe out most creatures in the universe.

Way too intense, as usual.
Also, it’s spelled Thanos.

[parcok]

not Thanos but tan Or shit yellow (feces)

Wooow there is Mr. 67 68, perhaps we can call him the god of puzzles. With the power of 25K GPU in his hands, he is probably equal to Snap Tanos, who is able to wipe out most creatures in the universe.

Way too intense, as usual.
Also, it’s spelled Thanos.

[goresat2025]

Here you go @goresat2025
 

The death of the monitoring bots for the low bit challenge/puzzles such as the 66, 67, 68 bits.
The sure fire way to get all of your hard earned 6.6 BTC into one of your safe wallets...or is it a sure fire way?
Let me know what you think.

...

thank you

this also apply to key 71, bot can brute force private key in seconds with pubkey?
or it takes time? like haf hour[/color]

[kTimesG]

this also apply to key 71, bot can brute force private key in seconds with pubkey?
or it takes time? like haf hour[/color]

Hundreds of milliseconds (less than a second, to be clear for some people around here).

[0xastraeus]

Who knew somebody with "cok" in their name could handle it and take it so well...relax buddy

not Thanos but tan Or shit yellow (feces)

Wooow there is Mr. 67 68, perhaps we can call him the god of puzzles. With the power of 25K GPU in his hands, he is probably equal to Snap Tanos, who is able to wipe out most creatures in the universe.

Way too intense, as usual.
Also, it’s spelled Thanos.

[0xastraeus]

There's some people here who's sole purpose is to monitor and use their bots to snipe and replace the transaction. As of right now, it still applies for this range.

this also apply to key 71, bot can brute force private key in seconds with pubkey?
or it takes time? like haf hour[/color]

Hundreds of milliseconds (less than a second, to be clear for some people around here).

[SecretAdmirere]

Does anyone have benchmark data for a 1080 Ti GPU running multiple publicly available programs? I have been unable to find comprehensive results.

The closest I found is on the website https://btcpuzzle.info/benchmark, which lists 652 million k/s for VanitySearch and BitCrack. Another source, https://github.com/sp-hash/Bitcrack/releases, claims 705 million k/s. There is also a forum topic started by Zielar (https://bitcointalk.org/index.php?topic=5218972.msg53649803#msg53649803) that claims 900 million k/s - though I suspect that figure uses endomorphism, which is useless for a specific range search.

I have compiled and run many of these publicly available tools myself but could not achieve key rates close to the claimed figures. Has anyone run a different program on a 1080 Ti and obtained a benchmark number?

With the program I developed, I can achieve a stable 760 to 775 million k/s on stock settings and power target (250W max power draw), varying slightly with GPU temperature. By simply unlocking the power target from 100% to 110%, I get a stable 800 million k/s. Increasing it to 150% allows me to reach 850 million k/s on my 1080 Ti.

I want to know if I am approaching the maximum limit of what the 1080 Ti can do, which is why I am asking.

For clarity, when I refer to keys per second (k/s), I mean hash160 comparisons per second. I am tracking the number of comparisons performed against a target hash160.

[stillhere@2009]

Does anyone have benchmark data for a 1080 Ti GPU running multiple publicly available programs? I have been unable to find comprehensive results.

The closest I found is on the website https://btcpuzzle.info/benchmark, which lists 652 million k/s for VanitySearch and BitCrack. Another source, https://github.com/sp-hash/Bitcrack/releases, claims 705 million k/s. There is also a forum topic started by Zielar (https://bitcointalk.org/index.php?topic=5218972.msg53649803#msg53649803) that claims 900 million k/s - though I suspect that figure uses endomorphism, which is useless for a specific range search.

I have compiled and run many of these publicly available tools myself but could not achieve key rates close to the claimed figures. Has anyone run a different program on a 1080 Ti and obtained a benchmark number?

With the program I developed, I can achieve a stable 760 to 775 million k/s on stock settings and power target (250W max power draw), varying slightly with GPU temperature. By simply unlocking the power target from 100% to 110%, I get a stable 800 million k/s. Increasing it to 150% allows me to reach 850 million k/s on my 1080 Ti.

I want to know if I am approaching the maximum limit of what the 1080 Ti can do, which is why I am asking.

For clarity, when I refer to keys per second (k/s), I mean hash160 comparisons per second. I am tracking the number of comparisons performed against a target hash160.

make sure your program is working correctly

[Bram24732]

Does anyone have benchmark data for a 1080 Ti GPU running multiple publicly available programs? I have been unable to find comprehensive results.

The closest I found is on the website https://btcpuzzle.info/benchmark, which lists 652 million k/s for VanitySearch and BitCrack. Another source, https://github.com/sp-hash/Bitcrack/releases, claims 705 million k/s. There is also a forum topic started by Zielar (https://bitcointalk.org/index.php?topic=5218972.msg53649803#msg53649803) that claims 900 million k/s - though I suspect that figure uses endomorphism, which is useless for a specific range search.

I have compiled and run many of these publicly available tools myself but could not achieve key rates close to the claimed figures. Has anyone run a different program on a 1080 Ti and obtained a benchmark number?

With the program I developed, I can achieve a stable 760 to 775 million k/s on stock settings and power target (250W max power draw), varying slightly with GPU temperature. By simply unlocking the power target from 100% to 110%, I get a stable 800 million k/s. Increasing it to 150% allows me to reach 850 million k/s on my 1080 Ti.

I want to know if I am approaching the maximum limit of what the 1080 Ti can do, which is why I am asking.

For clarity, when I refer to keys per second (k/s), I mean hash160 comparisons per second. I am tracking the number of comparisons performed against a target hash160.

I’ll rent a cloud 1080Ti real quick and let you know
Edit : Only 1080Ti I could find on vast / clore are power limited so I cant run a real benchmark for you. I have a 1080Ti somewhere at my house, but swaping my 5090 is not worth the hassle

[SecretAdmirere]

make sure your program is working correctly

In terms of testing and correctness, it passes every test I can think of. I'm not sure what else to throw at it. There are likely bugs in the program that I haven't been able to find yet.

I’ll rent a cloud 1080Ti real quick and let you know
Edit : Only 1080Ti I could find on vast / clore are power limited so I cant run a real benchmark for you. I have a 1080Ti somewhere at my house, but swaping my 5090 is not worth the hassle

Thank you for the quick reply and for trying to check the benchmark. Yes, swapping the 5090 for a 1080 Ti, and possibly dealing with driver changes, isn’t very appealing, especially for some random person on the internet like me. This is the only GPU I have available, so I’m limited to 2017-era hardware. I’ll try to squeeze a bit more performance out of my 1080 Ti, though I'm not sure how much is possible at this point.

For a quick comparison between hashing and non-hashing (hashing EC coordinates vs. computing only EC coordinates), the difference is substantial. Using the lowest values: 760M hashes/s vs. 1.6B EC coordinates/s (both are measurements of comparisons per second). This means operations without hashing are roughly 2.1 times faster than those with hashing. On my 1080 Ti. Improving either part would result in more processed keys and addresses, but I’m at a point where even a 1% gain is a massive win for me, because I’m stuck on what to possibly improve. I guess I have to try harder and learn more.

Overall, I was just wondering if I’m on the right track. Based on publicly available benchmarks, I seem to be, but not everything is public, which is why I asked here. I suppose the next step is finally upgrading my PC or, as I mentioned, trying harder to improve the code.

[retrograded]

If puzzle 130 was relatively easy to solve than 135, why not we just reduce puzzle 135 to 130 and solve it? I know a method which can at least precisely reduce to few bits like 4-5 (not exact, still reduces to a level where the time and space complexity reduces from 135 to ~131). But I lack the optimised algorithm which was used by 120, 125, 130 solver! Not to mention I also lack proper hardwares. It's just not much feasible for me to solve higher than 100 bits.

[GnSekhar]

well i had another doubt since you mentioned it will take no time for bots to get the puzzle after making a transaction does it apply to even if we disable the RBF factor or it won't help even if we disable it

[JackMazzoni]

If puzzle 130 was relatively easy to solve than 135, why not we just reduce puzzle 135 to 130 and solve it? I know a method which can at least precisely reduce to few bits like 4-5 (not exact, still reduces to a level where the time and space complexity reduces from 135 to ~131). But I lack the optimised algorithm which was used by 120, 125, 130 solver! Not to mention I also lack proper hardwares. It's just not much feasible for me to solve higher than 100 bits.

You do you mean subtracting 21778071482940061661655974875633165533184 to the public key? The new resulting public key now located from 1 to 21778071482940061661655974875633165533184 . This is your method?

[retrograded]

If puzzle 130 was relatively easy to solve than 135, why not we just reduce puzzle 135 to 130 and solve it? I know a method which can at least precisely reduce to few bits like 4-5 (not exact, still reduces to a level where the time and space complexity reduces from 135 to ~131). But I lack the optimised algorithm which was used by 120, 125, 130 solver! Not to mention I also lack proper hardwares. It's just not much feasible for me to solve higher than 100 bits.

You do you mean subtracting 21778071482940061661655974875633165533184 to the public key? The new resulting public key now located from 1 to 21778071482940061661655974875633165533184 . This is your method?

I had read somewhere that puzzle 130 was solved in a month? Now the solver may have even more compute power, hardwares and more optimised algorithms, so if it is possible for him to solve again a key falling in 130 bits in a months than I can guarantee by my method puzzle 135 can be solved in 4 months to 6 months. It's not about subtracting!

[JackMazzoni]

If puzzle 130 was relatively easy to solve than 135, why not we just reduce puzzle 135 to 130 and solve it? I know a method which can at least precisely reduce to few bits like 4-5 (not exact, still reduces to a level where the time and space complexity reduces from 135 to ~131). But I lack the optimised algorithm which was used by 120, 125, 130 solver! Not to mention I also lack proper hardwares. It's just not much feasible for me to solve higher than 100 bits.

You do you mean subtracting 21778071482940061661655974875633165533184 to the public key? The new resulting public key now located from 1 to 21778071482940061661655974875633165533184 . This is your method?

I had read somewhere that puzzle 130 was solved in a month? Now the solver may have even more compute power, hardwares and more optimised algorithms, so if it is possible for him to solve again a key falling in 130 bits in a months than I can guarantee by my method puzzle 135 can be solved in 4 months to 6 months. It's not about subtracting!

It was solved in two months with 400 gpu by retiredcoder.

[Pepepatrol]

Has anyone found a hash of 160 starting with f6f5431d25bbf5.... and f6f5431d25bbf6....? I'm starting to think that maybe such hashes don't exist in the 71-bit range.

Why should we care about prefixes? f6f5431d25bbf is 100% in range due to puzzle hash being f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8. Why would you think f6f5431d25bbf(4..5..6) etc is in puzzle range, it could be anywhere on the curve.

Prefixes give ZERO indication how close you are to the target.

Personally, prefixes are important to me. They help me quickly find other private keys with the prefix f6f5431d25bbf.
You personally shouldn't be concerned. Continue searching the full range from start to finish to avoid accidentally missing the key you're looking for.
Besides you, there are people on this forum who also compile their own prefix lists.
The question was addressed to them.

Any idea how to co confirm that address is compressed? Because I have found hash started with f6f5f431 in Uncompressed section. Any idea how to confirm?

[SRG02289]

Has anyone found a hash of 160 starting with f6f5431d25bbf5.... and f6f5431d25bbf6....? I'm starting to think that maybe such hashes don't exist in the 71-bit range.

Why should we care about prefixes? f6f5431d25bbf is 100% in range due to puzzle hash being f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8. Why would you think f6f5431d25bbf(4..5..6) etc is in puzzle range, it could be anywhere on the curve.

Prefixes give ZERO indication how close you are to the target.

Personally, prefixes are important to me. They help me quickly find other private keys with the prefix f6f5431d25bbf.
You personally shouldn't be concerned. Continue searching the full range from start to finish to avoid accidentally missing the key you're looking for.
Besides you, there are people on this forum who also compile their own prefix lists.
The question was addressed to them.

Any idea how to co confirm that address is compressed? Because I have found hash started with f6f5f431 in Uncompressed section. Any idea how to confirm?

1PWo3JeB9jqhsXUNL7QLWQ6JPSCNXHnScG     F6F5431D25BBF7...
1PWo3JeB9jmYb4L3mkPc36Vkw5bNRtEx1n    F6F5431D25BBF5...
1PWo3JeB9jogeV61sgEiE9dDry1cwsKumn     F6F5431D25BBF6...
1PWo3JeB9jkhKNCi5FGeEwvWYLPDo8cVoJ     F6F5431D25BBF5...
1PWo3JeB9jmAGH9txSdNMmtcbCoUgyWgWD   F6F5431D25BBF5...
... and about 200 more compressed pieces

[retrograded]

If puzzle 130 was relatively easy to solve than 135, why not we just reduce puzzle 135 to 130 and solve it? I know a method which can at least precisely reduce to few bits like 4-5 (not exact, still reduces to a level where the time and space complexity reduces from 135 to ~131). But I lack the optimised algorithm which was used by 120, 125, 130 solver! Not to mention I also lack proper hardwares. It's just not much feasible for me to solve higher than 100 bits.

You do you mean subtracting 21778071482940061661655974875633165533184 to the public key? The new resulting public key now located from 1 to 21778071482940061661655974875633165533184 . This is your method?

I had read somewhere that puzzle 130 was solved in a month? Now the solver may have even more compute power, hardwares and more optimised algorithms, so if it is possible for him to solve again a key falling in 130 bits in a months than I can guarantee by my method puzzle 135 can be solved in 4 months to 6 months. It's not about subtracting!

It was solved in two months with 400 gpu by retiredcoder.

Code:

@RetiredCoder

What do you say? Can you now solve the puzzle falling in range like that of puzzle #130 in approximately a month? You now prolly have more advanced hardwares purchased from millions earned by solving the three puzzles 😁 plus more optimised codes as time has passed a lot, so I am expecting you can solve it in one month range?

[GinnyBanzz]

If puzzle 130 was relatively easy to solve than 135, why not we just reduce puzzle 135 to 130 and solve it? I know a method which can at least precisely reduce to few bits like 4-5 (not exact, still reduces to a level where the time and space complexity reduces from 135 to ~131). But I lack the optimised algorithm which was used by 120, 125, 130 solver! Not to mention I also lack proper hardwares. It's just not much feasible for me to solve higher than 100 bits.

You do you mean subtracting 21778071482940061661655974875633165533184 to the public key? The new resulting public key now located from 1 to 21778071482940061661655974875633165533184 . This is your method?

I had read somewhere that puzzle 130 was solved in a month? Now the solver may have even more compute power, hardwares and more optimised algorithms, so if it is possible for him to solve again a key falling in 130 bits in a months than I can guarantee by my method puzzle 135 can be solved in 4 months to 6 months. It's not about subtracting!

It was solved in two months with 400 gpu by retiredcoder.

Code:

@RetiredCoder

What do you say? Can you now solve the puzzle falling in range like that of puzzle #130 in approximately a month? You now prolly have more advanced hardwares purchased from millions earned by solving the three puzzles 😁 plus more optimised codes as time has passed a lot, so I am expecting you can solve it in one month range?

Millions? The prizes for the 120,125,130,135 puzzles are much smaller, he absolutely did not get millions from it, more like $160,000.

[retrograded]

If puzzle 130 was relatively easy to solve than 135, why not we just reduce puzzle 135 to 130 and solve it? I know a method which can at least precisely reduce to few bits like 4-5 (not exact, still reduces to a level where the time and space complexity reduces from 135 to ~131). But I lack the optimised algorithm which was used by 120, 125, 130 solver! Not to mention I also lack proper hardwares. It's just not much feasible for me to solve higher than 100 bits.

You do you mean subtracting 21778071482940061661655974875633165533184 to the public key? The new resulting public key now located from 1 to 21778071482940061661655974875633165533184 . This is your method?

I had read somewhere that puzzle 130 was solved in a month? Now the solver may have even more compute power, hardwares and more optimised algorithms, so if it is possible for him to solve again a key falling in 130 bits in a months than I can guarantee by my method puzzle 135 can be solved in 4 months to 6 months. It's not about subtracting!

It was solved in two months with 400 gpu by retiredcoder.

Code:

@RetiredCoder

What do you say? Can you now solve the puzzle falling in range like that of puzzle #130 in approximately a month? You now prolly have more advanced hardwares purchased from millions earned by solving the three puzzles 😁 plus more optimised codes as time has passed a lot, so I am expecting you can solve it in one month range?

Millions? The prizes for the 120,125,130,135 puzzles are much smaller, he absolutely did not get millions from it, more like $160,000.

I meant million dollor worth of Bitcoins not million bitcoins. He have got I think 25+ bitcoins worth 2+ million dollors