What script do you use to collide the seeds with the KHex?

Seed : 2113081982 KHex : 730fc235
Seed : 2179848786 KHex : 730fc235
Seed : 2620256395 KHex : 730fc235
Seed : 3559516538 KHex : 730fc235
Seed : 5559894373 KHex : 730fc235
Seed : 5960477113 KHex : 730fc235
Seed : 6204436682 KHex : 730fc235
Seed : 7016671995 KHex : 730fc235
Seed : 8305603871 KHex : 730fc235
Seed : 8560029709 KHex : 730fc235
Seed : 8633074902 KHex : 730fc235
Seed : 9737552820 KHex : 730fc235

@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 ?

Feb 27 2025
Puzzle 68 progress

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

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).

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?

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.

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.

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.

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.