Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Baskentliia]

Have you heard of render farms ? I think they can offer their "services" for custom cuda software - and often have thousands of GPUs and much cheaper than standard cloud gpu instances.

One of the many theories 

What you wrote is not theory, it's reality
If you want to rent 1000s of graphics cards, you will need to use Render farms.

[frozenen]

@Zahid888  multiple seeds between (1000000000, 9999999999) will manage to get the same correct privkey prefix!

Do you have any idea how many seeds there are that would be able to get the same privkey prefix if looking for #67 ?

[mrxtraf]

And here's what I thought. It was a mistake to remove prizes from addresses longer than 160 bits. Yes. If you take a search purely by addresses, then in theory they should all fall within 160 bits (ripemd160). But, this is practically a simple enumeration, without using any mathematical logic. The maximum that this is an attempt to guess on the tea leaves, in which part of the range this address can be. And at the moment only the 67th bit is open. But with addresses with known public keys, there is already a different situation. There is no such collision as with addresses. And the complexity between 165 and 160 addresses will be approximately twice as much as between 160 and 155.

If I were the creator of this puzzle, I would still add addresses above 160 bits. Or activate those that were in the first initial transaction. Not necessarily each, but let's say with an interval of 3-5 addresses.

Sorry for the English, translated by an automatic translator.

[benjaniah]

Feb 27 2025
Puzzle 68 progress

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

[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