Bitcoin puzzle transaction ~32 BTC prize to who solves it

[papiro08]

I don't know if anyone has done this before, but I was with a man who has the gift of remote viewing. He says the key to Puzzle 68 lies between E0000000000000000 and E0FFFFFFFFFFFFFFF. 

Tell him, he is totally wrong 

There are no fortune tellers, the only one who knows the key is the creator or the one who has 3000 RTX 4090

[zahid888]

Per core, I'm getting 4.8 MK/s with single Base58 address… Maybe that's close to Hash160 speed. @Nomachine, may i know the speed of a single core with Hash160?

Where was the 4.8 MK/s at? I saw a bunch of 2 MK/s speeds. Maybe you did not show that part? And you only get that speed if you only search 1 address at a time?

Yes 4.8 MK/s with single bas58_address

Also, your bit mechanism seems broken. If you are searching in 69, but you have 68 ranges in your saved progress, that seems broken. Or am I missing something and that video has nothing to do with your comments/questions lol.

May be you are not notice in video i set -sbl(start bit length) to 68 and -ebl(end bit length) to 69 that is why you see 69 and 68 both bitrange key in process_save.txt for only 68 its required -sbl 68 and -ebl 68... you can see this when i search for puzzle 25 in video..

Interesting your executable! I would like to test it. Have you published it somewhere, or you don't want to share it?

Not yet   maybe soon  

I don't know if anyone has done this before, but I was with a man who has the gift of remote viewing. He says the key to Puzzle 68 lies between E0000000000000000 and E0FFFFFFFFFFFFFFF. 

I wouldn't call it a gift, it came standard with my PC, but I too have remote viewing with my Remote Desktop Protocol. However, it has never given me any hints to where the keys may lie, for any of the challenges. Maybe mine is faulty??!!

I don't know why but i also search 68 mostly in this range.. lol

[WanderingPhilospher]

Per core, I'm getting 4.8 MK/s with single Base58 address… Maybe that's close to Hash160 speed. @Nomachine, may i know the speed of a single core with Hash160?

Where was the 4.8 MK/s at? I saw a bunch of 2 MK/s speeds. Maybe you did not show that part? And you only get that speed if you only search 1 address at a time?

Yes 4.8 MK/s with single bas58_address

Also, your bit mechanism seems broken. If you are searching in 69, but you have 68 ranges in your saved progress, that seems broken. Or am I missing something and that video has nothing to do with your comments/questions lol.

May be you are not notice in video i set -sbl(start bit length) to 68 and -ebl(end bit length) to 69 that is why you see 69 and 68 both bitrange key in process_save.txt for only 68 its required -sbl 68 and -ebl 68... you can see this when i search for puzzle 25 in video..

Interesting your executable! I would like to test it. Have you published it somewhere, or you don't want to share it?

Not yet   maybe soon  

Ok, yeah, I missed some of those things. But regarding the 4.8 MK/s what am I missing there? What do you get on a standard public program like keyhunt-cuda or VS range limited version? I get 5 MK/s with out of the box keyhunt-cuda for address search on a single core.

Seems like you took cyclone or some other program and just added functionality to it versus changing the math or other type of real speed up. But it is early/late so maybe I missed something else too, especially since I am using my RDP to try and get a hint on the exact keyspace for 68

I don't know why but i also search 68 mostly in this range.. lol

I know why y'all are. Because 67s h160 starting chars were the range in which it was found. 68's starts with E0, so that is probably why.

[kTimesG]

If low-level custom firmware can be developed to give us direct access to the ASIC’s SHA-256 hashing function (without its built-in mining logic), then this approach could work. We could offload the SHA-256 part to the ASIC while handling the rest on the GPU/CPU, creating a hybrid GPU + ASIC system for Bitcoin address generation.

It's easier to simply use two GPUs to increase throughput, instead of trying to solve technical bottlenecks.

Because, before any hashing takes place, a GPU can produce much more public keys then the amount it can transfer out. The memory can't keep up.

An ASIC is required to do everything internally, on-chip.

[btc11235]

For your listening pleasure: Orphans of the Universe - Pattern-Seeking Animals

[zahid888]

Ok, yeah, I missed some of those things. But regarding the 4.8 MK/s what am I missing there? What do you get on a standard public program like keyhunt-cuda or VS range limited version? I get 5 MK/s with out of the box keyhunt-cuda for address search on a single core.

Seems like you took cyclone or some other program and just added functionality to it versus changing the math or other type of real speed up. But it is early/late so maybe I missed something else too, especially since I am using my RDP to try and get a hint on the exact keyspace for 68

You’re right, I added features to Cyclone itself since I’ve seen so many posts about it, so implementing my approach there made sense. I haven’t tried keyhunt-cuda yet, but I’ll check it out to see what speed I get. There’s no doubt that much higher speeds are available in the market.

I don't know why but i also search 68 mostly in this range.. lol

I know why y'all are. Because 67s h160 starting chars were the range in which it was found. 68's starts with E0, so that is probably why.

Lol you are right i even remember the post of @mcdouglasx as he mention this range in his probability list 

If low-level custom firmware can be developed to give us direct access to the ASIC’s SHA-256 hashing function (without its built-in mining logic), then this approach could work. We could offload the SHA-256 part to the ASIC while handling the rest on the GPU/CPU, creating a hybrid GPU + ASIC system for Bitcoin address generation.

It's easier to simply use two GPUs to increase throughput, instead of trying to solve technical bottlenecks.
Because, before any hashing takes place, a GPU can produce much more public keys then the amount it can transfer out. The memory can't keep up.
An ASIC is required to do everything internally, on-chip.

The biggest issue is exactly what you pointed out: before any hashing even happens, a GPU can generate way more public keys than it can transfer out. The memory bandwidth becomes the limiting factor, not just the compute power.

ASICs, on the other hand, are designed to handle everything on-chip, avoiding this bottleneck entirely. So unless an ASIC is specifically designed for this kind of workload, trying to mix ASICs and GPUs effectively might not be worth the effort.

Let’s see who will be the first to bring this approach into a practical, working solution. Though, to be honest, it sounds much easier in theory than it will be in practice! 

[WanderingPhilospher]

The old Cyclone...can not be beat, period.

Was trying to run a few tests on the new Cyclone trend, but it is too fast.

Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -t 1 -b 5 -r AF6E3791FC8000000:AF6E3791FC8ffffff
←[2J←[1;1H
No match found.
Total Checked : 2101760
Elapsed Time  : 00:00:00
Speed         : 3.33325 Mkeys/s

Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -r AF6E3791FC0000000:AF6E3791FCfffffff -t 1 -b 5
←[1;1H================= WORK IN PROGRESS =================
Puzzle/Bits   : 0
Mode          : Sequential
Range         : af6e3791fc0000000:af6e3791fcfffffff
Target Hash160: e0b8a2baee1b77fc703455f39d51477451fc8cfc
CPU Threads   : 1
Mkeys/s       : 3.48
Total Checked : 17375744
Elapsed Time  : 00:00:05
Progress      : 6.4730 %
Progress Save : 0
Stride        : 1

No match found.
Total Checked : 33620480
Elapsed Time  : 00:00:09
Speed         : 3.5046 Mkeys/s

Ok, but for real, what am I doing wrong lol.

[singlethread1]

Speaking of coin flips and probabilities. I'm curious to see how many of you can solve this logic question (without Googling the answer of course). My brother first heard it at a job interview and later he told me. I was able to solve it but it took me a good 20 minutes of thinking.

Here it is:

Code:

You have a weighted coin. When you flip it, it will either land on heads or tails, but not with a 50/50 probability. In fact, you don't know the probabilities (could be 51% chance of heads, 49% chance of tails.. Could be 99%/1%, could be 45.1234132452%/54.8765867548%).

How can you make an exact 50/50 decision every time with this unknown weighted coin?

[nomachine]

The old Cyclone...can not be beat, period.

Was trying to run a few tests on the new Cyclone trend, but it is too fast.

Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -t 1 -b 5 -r AF6E3791FC8000000:AF6E3791FC8ffffff
←[2J←[1;1H
No match found.
Total Checked : 2101760
Elapsed Time  : 00:00:00
Speed         : 3.33325 Mkeys/s

Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -r AF6E3791FC0000000:AF6E3791FCfffffff -t 1 -b 5
←[1;1H================= WORK IN PROGRESS =================
Puzzle/Bits   : 0
Mode          : Sequential
Range         : af6e3791fc0000000:af6e3791fcfffffff
Target Hash160: e0b8a2baee1b77fc703455f39d51477451fc8cfc
CPU Threads   : 1
Mkeys/s       : 3.48
Total Checked : 17375744
Elapsed Time  : 00:00:05
Progress      : 6.4730 %
Progress Save : 0
Stride        : 1

No match found.
Total Checked : 33620480
Elapsed Time  : 00:00:09
Speed         : 3.5046 Mkeys/s

Ok, but for real, what am I doing wrong lol.

I noticed that there is a bug where the Puzzle/Bits value is not being calculated and displayed correctly. I will try to fix it, although I don't have time to deal with this.

[WanderingPhilospher]

The old Cyclone...can not be beat, period.

Was trying to run a few tests on the new Cyclone trend, but it is too fast.

Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -t 1 -b 5 -r AF6E3791FC8000000:AF6E3791FC8ffffff
←[2J←[1;1H
No match found.
Total Checked : 2101760
Elapsed Time  : 00:00:00
Speed         : 3.33325 Mkeys/s

Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -r AF6E3791FC0000000:AF6E3791FCfffffff -t 1 -b 5
←[1;1H================= WORK IN PROGRESS =================
Puzzle/Bits   : 0
Mode          : Sequential
Range         : af6e3791fc0000000:af6e3791fcfffffff
Target Hash160: e0b8a2baee1b77fc703455f39d51477451fc8cfc
CPU Threads   : 1
Mkeys/s       : 3.48
Total Checked : 17375744
Elapsed Time  : 00:00:05
Progress      : 6.4730 %
Progress Save : 0
Stride        : 1

No match found.
Total Checked : 33620480
Elapsed Time  : 00:00:09
Speed         : 3.5046 Mkeys/s

Ok, but for real, what am I doing wrong lol.

I noticed that there is a bug where the Puzzle/Bits value is not being calculated and displayed correctly. I will try to fix it, although I don't have time to deal with this.

I was more referring to it not completing a range. I put in a range, and the total checked and range size are not equal. Not even close. But wasn't 100% if I somehow did something wrong lol.

[Akito S. M. Hosana]

I noticed that there is a bug where the Puzzle/Bits value is not being calculated and displayed correctly. I will try to fix it, although I don't have time to deal with this.

It's good that it works at all, considering you only worked on this for a couple of days. I would have worked on this for months and probably achieved nothing. 

[nomachine]

I was more referring to it not completing a range. I put in a range, and the total checked and range size are not equal. Not even close. But wasn't 100% if I somehow did something wrong lol.

It's not your fault. The percentage stopping at 6% even though the script completes the entire range is due to an incorrect calculation of the total range size (totalRangeLD) or an incorrect update of globalComparedCount. It could also be caused by an incorrect range calculation, or both. ...Need to debug and fix this..

[papiro08]

I leave you this song from our Aunt Taylor while you decipher puzzle number 68 https://www.youtube.com/watch?v=AgFeZr5ptV8

[Bram24732]

snip

snip

McD, ktimesg and Bram, you all are arguing over doing the same thing in different ways lol.

McD has changed the way his script, or at least his thought process of how the script should work, versus his initial draft.

There could be the possibility that a 10 matching h160 is right next to another one, but of all the data I have sifted through, it never has happened. It's easy to run a decent sized range, say 2^48, where on average, you would find, 256 10 leading h160 matches, but none of them will be right beside each other. Or you can sift through Bram's PoWs and you will find, none of them are right beside each other either.

So there is nothing wrong with what McD is suggesting. You find x amount prefix, pad it by y amount on both sides (+/-) and keep on trucking until z amount of range is filled up. If key is not found, you shrink all of your previously stored padded ranges by x amount, and search again. The key would eventually be found, just as if you did large range searches, randomly or sequentially, throughout the whole range. Brute forcing an entire range says the magic key will be found on avg, at or around 50% of total range keys searched. That's an average, could be at 1% or 99.99%. The last 2 keys were found between 51-57% via large range searches, selected randomly. There is no way of knowing which is better/faster, as it depends on which key was found and padded, close to the actual key we are searching for.

For me, I would and have tweaked the way McD script/plan works. Instead of just finding random prefixes 100% of the time, you swap over to filling the gaps, with 100% of keys. So if one padded range ends with 0x...12345, then I brute force keys starting at 0x...12346 to however large a range size you want to chew up. I have the padded ranges and the complete search ranges marked differently in the db, so if I need to shrink the padded ranges, I will only shrink those and not the 100% searched ranges.

Now, for what Bibli is doing, I am not 100% sure. I know he finds a prefix and with some calculations, makes a jump and searches for the next. But in this manner you could skip over the actual key. But I am not sure how you would go back and check the gaps you skipped unless you tracked start and end ranges and jump sizes, and then go back in and have to manually fill in those gaps if key isn't found. My issue with this, is you could find a 14 h160 match in 0xF range and spend a lot of time in that range when the actual key could be in the 0x8 range. But I do not know all of the ends and outs of his plan/thought process so I can't speak on it 100%.

I don’t understand why they insist on declaring as false something that has all the logic of mathematics behind it, even when all the failure points of these methods have easy solutions that have already been discussed previously. What they do is focus on the worst-case scenario. It's like if I told Bram that his method fails because it could leave the winning block as random at the end; obviously, that’s something that could happen, but it’s absurd to say so because the probabilities would be too low to consider it a real problem. I think this happens when someone wants to maintain a position at all costs, even when it’s wrong.

They focus exclusively on the worst cases, which reminds me of the fallacy of composition assuming that because one part can fail under specific circumstances, the whole is defective.

I’ll clarify then. Of course your method works, you’re checking all keys eventually.
I’m saying there is no speed boost doing it this way instead of doing it in sequence, only drawbacks because of gap management.Those drawbacks are also minimal if the ranges are big enough, but then you’re only adding complexity to the brute force process for no good reason.

[papiro08]

Performance with modified Cyclon approximately with an i5 1335u 50mkey/s laptop when stabilized

[mcdouglasx]

I’ll clarify then. Of course your method works, you’re checking all keys eventually.
I’m saying there is no speed boost doing it this way instead of doing it in sequence, only drawbacks because of gap management.Those drawbacks are also minimal if the ranges are big enough, but then you’re only adding complexity to the brute force process for no good reason.

My point is not that it is necessarily better, but that it is the most efficient probabilistic search for brute force in the "homemade" context, because you are trying your luck with the few resources you might have, based on probabilistic expectation. In your "pool" context, a "full random" search is the best option, because it is the easiest way to deal with the problem.

However, in the context of someone who only has a single GPU, a search like this would be better than yours, as they could spend years searching within just a few sub-ranges.

In other words, the optimal strategy depends directly on the resources available and the time horizon at hand.

[kTimesG]

What the f*** is a probabilistic brute force method? Is it brute force, or is it not? Is it more efficient or is it not better than something else? Make up your mind. So many freaking things that smell so badly of logical non-sense, when a normal person is trying to read and understand your posts.

Maybe you're a genius, who knows. Those people are never understood by the rational people, since they function on a totally different frequence.

This thread may give a normal person a brain aneurysm once they see fellow people failing to see plain out contradictions when they are being drawn right under their nose more times than there are keys in Puzzle 256. We don't need a freaking diploma in rocket science to have some common sense... I give up.

In computer science, brute-force search or exhaustive search, also known as generate and test, is a very general problem-solving technique and algorithmic paradigm that consists of systematically checking all possible candidates for whether or not each candidate satisfies the problem's statement.

[Bram24732]

I’ll clarify then. Of course your method works, you’re checking all keys eventually.
I’m saying there is no speed boost doing it this way instead of doing it in sequence, only drawbacks because of gap management.Those drawbacks are also minimal if the ranges are big enough, but then you’re only adding complexity to the brute force process for no good reason.

My point is not that it is necessarily better, but that it is the most efficient probabilistic search for brute force in the "homemade" context, because you are trying your luck with the few resources you might have, based on probabilistic expectation. In your "pool" context, a "full random" search is the best option, because it is the easiest way to deal with the problem.

However, in the context of someone who only has a single GPU, a search like this would be better than yours, as they could spend years searching within just a few sub-ranges.

In other words, the optimal strategy depends directly on the resources available and the time horizon at hand.

Nope, still not. Even with a single GPU the odds of both methods are EXACTLY the same. You have 1/(2**67 - nbKeysAlreadyChecked) chance for every key you check, no matter the order. Trying to use probabilities in arbitrary defined ranges does not improve odds because just like with a coin flip, each event is independent.

[mcdouglasx]

What the f*** is a probabilistic brute force method? Is it brute force, or is it not? Is it more efficient or is it not better than something else? Make up your mind. So many freaking things that smell so badly of logical non-sense, when a normal person is trying to read and understand your posts.

Maybe you're a genius, who knows. Those people are never understood by the rational people, since they function on a totally different frequence.

This thread may give a normal person a brain aneurysm once they see fellow people failing to see plain out contradictions when they are being drawn right under their nose more times than there are keys in Puzzle 256. We don't need a freaking diploma in rocket science to have some common sense... I give up.

In computer science, brute-force search or exhaustive search, also known as generate and test, is a very general problem-solving technique and algorithmic paradigm that consists of systematically checking all possible candidates for whether or not each candidate satisfies the problem's statement.

Your problem is that you take all opinions that differ from yours as a call to war, and that says more about you than about me.

Nope, still not. Even with a single GPU the odds of both methods are EXACTLY the same. You have 1/(2**67 - nbKeysAlreadyChecked) chance for every key you check, no matter the order. Trying to use probabilities in arbitrary defined ranges does not improve odds because just like with a coin flip, each event is independent.

I disagree because I replicate your scenario and mine (as it should be done before giving an opinion), and in mine, I always end up obtaining the key first. Although I could be wrong, these are the data I obtain in each test, within a friendly range for my limited resources.

[Bram24732]

What the f*** is a probabilistic brute force method? Is it brute force, or is it not? Is it more efficient or is it not better than something else? Make up your mind. So many freaking things that smell so badly of logical non-sense, when a normal person is trying to read and understand your posts.

Maybe you're a genius, who knows. Those people are never understood by the rational people, since they function on a totally different frequence.

This thread may give a normal person a brain aneurysm once they see fellow people failing to see plain out contradictions when they are being drawn right under their nose more times than there are keys in Puzzle 256. We don't need a freaking diploma in rocket science to have some common sense... I give up.

In computer science, brute-force search or exhaustive search, also known as generate and test, is a very general problem-solving technique and algorithmic paradigm that consists of systematically checking all possible candidates for whether or not each candidate satisfies the problem's statement.

Your problem is that you take all opinions that differ from yours as a call to war, and that says more about you than about me.

Nope, still not. Even with a single GPU the odds of both methods are EXACTLY the same. You have 1/(2**67 - nbKeysAlreadyChecked) chance for every key you check, no matter the order. Trying to use probabilities in arbitrary defined ranges does not improve odds because just like with a coin flip, each event is independent.

I disagree because I replicate your scenario and mine (as it should be done before giving an opinion), and in mine, I always end up obtaining the key first. Although I could be wrong, these are the data I obtain in each test, within a friendly range for my limited resources.

The reason you get this is because the prefix is small enough when compared to the range size.
This is of no use when the prefix size becomes closer to the range size. Like when the prefix is 67 bits and the range also is 67 bits, like for any of those puzzles.