Bitcoin puzzle transaction ~32 BTC prize to who solves it

[puzzlemandelux]

Feb 27 2025
Puzzle 68 progress

Bram: 3% scanned
btc-hunters 0.11% scanned
btcpuzzle: 0.10% scanned
ttdpool: 0.04% scanned

Hi, I am working with a RTX 4070 SUPER, can I join a pool?

[kTimesG]

Now Bram resolves probabilistically, and you have something to say.

The guy posted in several places on the internet he scanned 57% of the entire range, key by key.

He published the proof that he did a full brute-force scan over all of those 57% of the keys. Those proofs are easily checked and show without doubt that the 57% of the keys were computed and hashed.

The statistical model you and bib are reading as "oh, he used probabilities" is the risk/reward statistical model he used in order to check if the crowdfunding makes sense from a spending/profits perspective, considering the misc. pools progress and other risk factors.

And I don't have anything against valid ideas, but I do have all the reasons to protect against anyone calling me either an idiot (like bilbilgin does to everyone who doesn't agree with him), or that I answer via "AI-prompts". I never called you stupid, arrogant, or personal attacks. There is a big difference between calling an idea stupid and calling a person stupid.

Your probabilistic software idea works just fine as long as you very carefully and correctly take into account the probabilities once you found whatever prefixes. The problem, however (as I see it) is that once you scanned, let's say, X% amount of the keys (in whatever skip order you think it's best), the probability to have hit the solution is still X%. Identical to a brute-force attempt (again, in my view).

But the difference is this: it's a lot easier to manage sequential scans. rather than managing what ends up being hundreds of millions of "I stopped there, skipped that much" database entries. And you also mentioned CUDA here - well, fragmentation of ranges is definitely not CUDA_friendly. It's not like if you have 25000 of concurrent threads it's simply easy-peasy to break out of them, skip stuff, and etc. - it's an anti-pattern which is a nightmare to implement, and it will complicate things (e.g less performance).

[mcdouglasx]

The guy posted in several places on the internet he scanned 57% of the entire range, key by key.

Full random yes.

https://github.com/Kowala24731/btc67

The problem was split in 256 sub ranges of size 2^58.
In each sub range, we save every private key which generates an address starting with 48 zeros.
There are statistically 1024 proofs per sub range.
If we can provide an average of 1024 proofs per sub range, it statistically guarantees that we scanned the whole sub range.

It was a simple vanity search, they assume they scanned 57% because they found 1024 matches in
57% of the subranges.
That's what I understood.

[kTimesG]

The guy posted in several places on the internet he scanned 57% of the entire range, key by key.

Full random yes.

https://github.com/Kowala24731/btc67

The problem was split in 256 sub ranges of size 2^58.
In each sub range, we save every private key which generates an address starting with 48 zeros.
There are statistically 1024 proofs per sub range.
If we can provide an average of 1024 proofs per sub range, it statistically guarantees that we scanned the whole sub range.

It was a simple vanity search, they assume they scanned 57% because they found 1024 matches in
57% of the subranges.
That's what I understood.

OK. They assumed they scanned a 2^58 range because they found 1024 addresses that start with 48 zeros. But what did they scan for? An address that starts with 48 zeros, or address of Puzzle 67?

For 3 years now I’ve been working on a seed recovery software which can bruteforce quite a few different scenarios. Private keys is one of those scenarios. My software is significantly faster than all the code you will find out there, even the ones used in the forums dedicated to brute forcing BTC67. This is our edge, and this is the plan : Brute force this faster (and cheaper) than the competition.

[mcdouglasx]

OK. They assumed they scanned a 2^58 range because they found 1024 addresses that start with 48 zeros. But what did they scan for? An address that starts with 48 zeros, or address of Puzzle 67?

LOL, I already responded to your "key by key" argument, and now you want to change the topic to reach a point that validates you. You see that I'm right and you're just a troll. Vanity starting with 1111xxxxxx, I don't see where you're going with this—well, I do see, I suppose to a point where it seems like you're right by saying that 1111xxxx isn't the same as 1BY8GQb because you're considering the bits and blah blah. Anyway, you're just paving ways to justify yourself. Man, I'm not a fool, I know what you're doing, but go ahead.

Regardless, assuming that a key isn't in a subrange just because you find 1024 matches is also "probability".Although the difference with my method is that if something fails or I miss the target, I can always readjust the DB without losing progress. On the other hand, if they casually omit the target, there will be no way to know in which subrange it was omitted, losing the progress.

[kTimesG]

~ snip ~

Nah, man, we're good. I honestly lost track with what you're trying to explain. The Bram dude posted a proof of all the RIPEMD-160 hashes (that start with 48 bits of 0) that he claims they guarantee that he scanned and hashed 57% of all keys. It's your problem how you interpret this claim. However, if I would be in a position to dispute his claim, my best strategy (after checking his dataset) would be to find another RIPEME-160 hash (that starts with 48 bits of 0) and is part of the 57% scanned range. If I can't do that, I would first shut up.

[mcdouglasx]

~ snip ~

Nah, man, we're good. I honestly lost track with what you're trying to explain. The Bram dude posted a proof of all the RIPEMD-160 hashes (that start with 48 bits of 0) that he claims they guarantee that he scanned and hashed 57% of all keys. It's your problem how you interpret this claim. However, if I would be in a position to dispute his claim, my best strategy (after checking his dataset) would be to find another RIPEME-160 hash (that starts with 48 bits of 0) and is part of the 57% scanned range. If I can't do that, I would first shut up.

You're still diverting everything. I copied and pasted what they said on their GitHub (those aren't my words).
https://github.com/Kowala24731/btc67

Somehow, finding the 1024 h160 assures them that they didn't skip the target key? No, right? Because it's just probability. You twist everything, which over time will only give you a bad reputation. I'm not criticizing them, I'm just pointing out a possible flaw that doesn't have a patch in their method. However, I consider it better than eternally scanning an entire range.

[WanderingPhilospher]

OK. They assumed they scanned a 2^58 range because they found 1024 addresses that start with 48 zeros. But what did they scan for? An address that starts with 48 zeros, or address of Puzzle 67?

LOL, I already responded to your "key by key" argument, and now you want to change the topic to reach a point that validates you. You see that I'm right and you're just a troll. Vanity starting with 1111xxxxxx, I don't see where you're going with this—well, I do see, I suppose to a point where it seems like you're right by saying that 1111xxxx isn't the same as 1BY8GQb because you're considering the bits and blah blah. Anyway, you're just paving ways to justify yourself. Man, I'm not a fool, I know what you're doing, but go ahead.

Regardless, assuming that a key isn't in a subrange just because you find 1024 matches is also "probability".Although the difference with my method is that if something fails or I miss the target, I can always readjust the DB without losing progress. On the other hand, if they casually omit the target, there will be no way to know in which subrange it was omitted, losing the progress.

He did not do a VanitySearch via an address, the way JLPs does a vanity search. He scanned a range and only saved H160s that met his criteria as a PoW key; which in his case, he used the leading 48 bits; 2^58-2^48 = 2^10 = 1,024. This saves time versus breaking it down to a vanity/any address. But he did not skip around after x keys were found. He still searched the entire subrange and kept the PoW keys as proof that the search had been done (think of proof to himself (that he actually scanned the range) and his investors). So in a sense, he was using probabilities as proof, but not to adjust his search pattern; he still scanned 100% of the subranges, even if he found 1,028 matching H160s before the subrange had been 100% completely scanned.

[karrask]

The topic has become toxic. You're all unhappy about something, arguing with each other. some lack knowledge, others lack money... but, it surprises me that no one who has the knowledge has yet found a way that will reduce any range by 70 percent or more. I'll give you a hint, at a speed of 4 billion per second, 68 are sorted out in a week. I envy your knowledge... but I think you are fools who are limited by your own knowledge...The answer is in front of you, and you are blind...about two years ago, I came across puzzles and the first thought was correct, but after reading your thoughts (on this topic), I was led in the other direction, it was my mistake...and now, I hope, they will help me with the implementation and write the code...I'm sorry for my words...Good day to you...I wish you good luck!

[WanderingPhilospher]

OK. They assumed they scanned a 2^58 range because they found 1024 addresses that start with 48 zeros. But what did they scan for? An address that starts with 48 zeros, or address of Puzzle 67?

LOL, I already responded to your "key by key" argument, and now you want to change the topic to reach a point that validates you. You see that I'm right and you're just a troll. Vanity starting with 1111xxxxxx, I don't see where you're going with this—well, I do see, I suppose to a point where it seems like you're right by saying that 1111xxxx isn't the same as 1BY8GQb because you're considering the bits and blah blah. Anyway, you're just paving ways to justify yourself. Man, I'm not a fool, I know what you're doing, but go ahead.

Regardless, assuming that a key isn't in a subrange just because you find 1024 matches is also "probability".Although the difference with my method is that if something fails or I miss the target, I can always readjust the DB without losing progress. On the other hand, if they casually omit the target, there will be no way to know in which subrange it was omitted, losing the progress.

He did not do a VanitySearch via an address, the way JLPs does a vanity search. He scanned a range and only saved H160s that met his criteria as a PoW key; which in his case, he used the leading 48 bits; 2^58-2^48 = 2^10 = 1,024. This saves time versus breaking it down to a vanity/any address. But he did not skip around after x keys were found. He still searched the entire subrange and kept the PoW keys as proof that the search had been done (think of proof to himself (that he actually scanned the range) and his investors). So in a sense, he was using probabilities as proof, but not to adjust his search pattern; he still scanned 100% of the subranges, even if he found 1,028 matching H160s before the subrange had been 100% completely scanned.

It took 67 days.
Custom software written from scratch

So the full random method? Which solves puzzle 67 in 67 days?

Full random yes.
I don't wan't to be disrespectful to anyone, but most of the theories I see here about patterns look crazy to me.
The ONLY way I could see a pattern between puzzles is if the creator messed up the randomess (unsecure RNG, predictable seed choice, etc...) and I really don't think he would make such a mistake.

Why did you quote all of that lol. Had not much to do with what I said.

Maybe your interpretation of full random can be different. Example. public pools are full 100% random. They randomly select a subrange and run it 100%. They do not go start at beginning subrange and then move sequentially to the next.

My real point was, he wasn't using a vanity search, but more than likely, the h160s hard coded into the kernel call, for his PoW and the actual address searching for. That's like 4 lines of code.

And I guarantee you, he did not find a match and stop the search and jump around to another spot in the overall range. He ran full 2^58 subranges. The order in which they were selected were 100% random. But I am guessing, he ran each subrange from key 1 to end of subrange, checking every key in that subrange. Maybe Bram can confirm/clear it all up lol.

[mjojo]

Maybe somebody can explain, I run script use some chars (not public key) as input sha256 then hashing to RMD160 then to base58 address and the address is active and have balance. Then I run same script use real public key as input with same above sequence and give active btc address too. my question is possible create address without private key and public key?

[mcdouglasx]

Maybe your interpretation of full random can be different. Example. public pools are full 100% random. They randomly select a subrange and run it 100%. They do not go start at beginning subrange and then move sequentially to the next.

My real point was, he wasn't using a vanity search, but more than likely, the h160s hard coded into the kernel call, for his PoW and the actual address searching for. That's like 4 lines of code.

And I guarantee you, he did not find a match and stop the search and jump around to another spot in the overall range. He ran full 2^58 subranges. The order in which they were selected were 100% random. But I am guessing, he ran each subrange from key 1 to end of subrange, checking every key in that subrange. Maybe Bram can confirm/clear it all up lol.

My real point was, he wasn't using a vanity search, but more than likely, the h160s hard coded into the kernel call, for his PoW and the actual address searching for. That's like 4 lines of code.

Anyway, I understand your deduction, but given Bram's statements about "full random," it doesn't make clear what his script does.

There could be many tricks where a random search covers the entire range. You put one on the table, which is the least efficient if you don't have a GPU farm, and I presented another equally valid one, more efficient for us mortals. If he did it as you say, that's fine; we don't know for certain, we're just speculating. I could join a pool and randomly scan the 1024 checks and justify that I went through all the keys (when I didn't), and no one in the pool would know.

[WanderingPhilospher]

Maybe your interpretation of full random can be different. Example. public pools are full 100% random. They randomly select a subrange and run it 100%. They do not go start at beginning subrange and then move sequentially to the next.

My real point was, he wasn't using a vanity search, but more than likely, the h160s hard coded into the kernel call, for his PoW and the actual address searching for. That's like 4 lines of code.

And I guarantee you, he did not find a match and stop the search and jump around to another spot in the overall range. He ran full 2^58 subranges. The order in which they were selected were 100% random. But I am guessing, he ran each subrange from key 1 to end of subrange, checking every key in that subrange. Maybe Bram can confirm/clear it all up lol.

My real point was, he wasn't using a vanity search, but more than likely, the h160s hard coded into the kernel call, for his PoW and the actual address searching for. That's like 4 lines of code.

Anyway, I understand your deduction, but given Bram's statements about "full random," it doesn't make clear what his script does.

There could be many tricks where a random search covers the entire range. You put one on the table, which is the least efficient if you don't have a GPU farm, and I presented another equally valid one, more efficient for us mortals. If he did it as you say, that's fine; we don't know for certain, we're just speculating. I could join a pool and randomly scan the 1024 checks and justify that I went through all the keys (when I didn't), and no one in the pool would know.

I can tell you have never participated in a pool or ran your own in-depth, search.

Public pools do not use this format, because the pool needs to know you actually ran the range assigned. That is why they give out x amount of random PoW keys, spread out over the entire, assigned range. Also, the client software is closed source, so you can't enter into a "random" mode. So no, with a public pool, you could not fake your range.

If you are doing your own private pool, you can run as Bram did. Because who are you going to fool, yourself?!?! That would not make sense at all lol.

Let us say you could run a random search in a public pool, to fool them...some ranges would not have the full 1,024 probabilistic leading 48 bits of a h160, so your random mode search would actually do more searching, for infinity, trying to find the magical number 1,024 matches lol. You see?

You do understand the 1,024 is probable, not guaranteed. I think Bram said the lowest range contained only 938 found and the highest contained 1108.

Do you see why your "random" method would not work to fool a pool, or why a public pool cannot run the same way as Bram did his private search/pool??

[kTimesG]

Weirdest thing happened today.

The kids received some numbered animal wildlife cards. 5 packs of 4 surprise exchange cards each.

So I unpacked all 20 cards. Each of them had a number on a corner. Least was a 15, highest was a 92. No space for 3 digits in that number circle.

I then sorted the cards by their number. So, all 20 cards.

Why the f*** did I get # 88 as a repeat? Now I only have 19 different cards. Sad day for probabilities.

[mcdouglasx]

snip

My point is that you cannot be certain about what Bram did until he clarifies it himself. However, my search method remains more efficient, so one thing does not negate the other. To clarify, 'full random' is 100% random, and should not be confused with 'Random+Sequential,' which introduces a sequential component that may not be entirely random if we are precise. Precision in terminology is crucial in programming.

edit:

I admit that it was a vague example. I wanted to tell you that 1024 h160 is not 100% valid proof to attest to what Bram did, but rather that his terms 'full random' are not correct, mathematically speaking.

[dastic]

You could precompute 80000000 - ffffffff, store in ram (or DB) and then sequentially scan the rest comparing against all the start keys at once. It's around 2 billion start keys so 1 trillion left to scan (easy). Good luck.

If it's useful donate: bc1qsyhgm200sx3d4s8snjzxt6teq472k0rtl2zt74

 

[COBRAS]

You could precompute 80000000 - ffffffff, store in ram (or DB) and then sequentially scan the rest comparing against all the start keys at once. It's around 2 billion start keys so 1 trillion left to scan (easy). Good luck.

If it's useful donate: bc1qsyhgm200sx3d4s8snjzxt6teq472k0rtl2zt74

 

Simple math NOT work for btc puzzle. Divide mul sub add - THIS IS NOT WORK result will be same if nothing do with puzzle pubkey

[jstyler]

dastic's suggestion is on the right track, but precomputing 80000000 - ffffffff is still a massive undertaking. I was thinking more along the lines of a mathematical pattern that can be derived from the given addresses. The PVK values seem to be related to a simple polynomial or exponential function. Has anyone tried checking if the PVK values follow a Fibonacci sequence or a quadratic equation?

[whistle307194]

Hello everyone,

I need to show you something I was working on for a few months and because I am actually addicted of this, you have to see it.

So basically the case is I want to verify If I am that "smart" or it is just pure coincidence.

I have just now registered first ever account.

I am working with a very interesting python script that basically get's the private key directly from the hash160 of basically any address up to puzzle 130...sounds crazy isn't it?

So basically what I need to decode private key of the hash160 of an p2pkh bitcoin address? hah a private key

Seriously..

1.Chose whatever range, like I said, for the moment I have tested until puzzle 130, generate Yourself a hex private key in between chosen range and get the compressed address.
2 Convert the hash160 of that address to decimal string.
3.Convert the hexadecimal private key to decimal as well,
4 Now using a big integer calculator for example http://www.javascripter.net/math/calculators/100digitbigintcalculator.htm ( I am also using it ) divide the decimal string of hash160 by decimal version of private key
5.The resulting string now You have to multiply times decimal private key.
6 That multiplication will result with a long string of course but quite similar with the first digits like so basically that string will be required by me.

That is pretty obvious that having only hash160 string we cannot see the private key directly can we?
 
So what I need actually to decode private key then?

I need a hex range boundary of Your address choice and the the resulting decimal string from step 6. or as You want convert it to an address back using brainwallet converter, so range boundary and an compressed address

Time to get the private key? Instant, 0.1 sec.

The most important: I don't need a private key , I will get one to verify what I say and second read carefully so You have zero questions about the steps.

Don't forget to pick up the range and address with that private key You don't use personally, that is just a test. Wanna see the results reply with what I ask for.


When I have the private key I will reply with signed message so You can verify Yourself.

I guarantee you will be intrigued.


///////////////////// 01-03-2025 / 4:25PM update /////////////////////

At this moment I am going tell You something like this..
Because I don't want bother people trying prove something that is looking a little too crazy I want to increase difficulty to crack the pvk of Your choice to make this looking even more unimaginable.

In a first post I was asking You to do the 1-6 steps and provide me a range boundary and the initial address You have got from the pvk of Your choice of that range boundary...

Now I am asking You to provide only initial address and the decimal string from step 6 (or second address while converted to B58Check using brainwallet converted) BUT no range borders!.

Use of course a range boundary not from puzzles asking me for a private key but similar range up to puzzle 130!

So now the difficulty is that I will provide pvk using these two initials without knowing range boundary at all! Try me!

[WanderingPhilospher]

snip

My point is that you cannot be certain about what Bram did until he clarifies it himself. However, my search method remains more efficient, so one thing does not negate the other. To clarify, 'full random' is 100% random, and should not be confused with 'Random+Sequential,' which introduces a sequential component that may not be entirely random if we are precise. Precision in terminology is crucial in programming.

edit:

I admit that it was a vague example. I wanted to tell you that 1024 h160 is not 100% valid proof to attest to what Bram did, but rather that his terms 'full random' are not correct, mathematically speaking.

No, you cannot say your search method remains more efficient because I do not know your search method. If it is 100% random as you describe, then you would have to find a private key in a 67 bit range to compare numbers with Bram's / other's methods.

That is pretty obvious that having only hash160 string we cannot see the private key directly can we?
 
So what I need actually to decode private key then?

I need a hex range boundary of Your address choice and the the resulting decimal string from step 6. or as You want convert it to an address back using brainwallet converter, so range boundary and an address

IS this a joke? You obviously need more than the range boundaries; you are asking people to provide you with step 6, which means they would have to know the private key. So how does this help any? With puzzles or life in general. The only people who would be intrigued are those who think you are doing something magical (and did not read everything you wrote) but in fact you are asking them to take their address's h160 and divide it by the private key (both in decimal format). If I know my private key, I don't need your tool. If I am chasing 68 or 69, your method does not help me because I obviously do not know the private key or I would sweep those funds lol.