Search content
Sort by

Showing 20 of 82 results by Virtuose
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 21/07/2025, 10:46:10 UTC
Good to know:

50,000 BTC now in MARA’s treasury.

Fueled by 57+ EH/s of computational power, reinforcing new foundations for our nation’s digital economy and energy infrastructure.

This is MARA for America in action.

Next target: 75 EH/s by year-end.

https://x.com/MARA/status/1940799202159992835?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1940799202159992835%7Ctwgr%5E54fbd793bdd73c112e5f289ee31ea46a1c9c4f9c%7Ctwcon%5Es1_c10&ref_url=https%3A%2F%2Finvestx.fr%2Factu-crypto%2Fdoge-explose-52-analyse-dogecoin-baleine%2F
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 21/07/2025, 09:06:42 UTC
Its easyer to find a Bitcoin Block  Grin than finding the key here.

Yes you can try with your 50Mkeys/s  Grin
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 20/07/2025, 22:12:36 UTC
If everyone gives up, surely the creator will give us other clues and I know he is among us. Without clues for puzzle #160, we need to scan half of the key.

But that’s exactly the point, no clues. The challenge is to see if the key can be cracked without help. If hints were given every time people got stuck, it wouldn’t be a true test of possibility or limits. That’s what makes it worth chasing.
Post
Topic
Board Announcements (Altcoins)
Re: [ANN] Official Nito Network (NITO) Project - SHA256 PoW
by
Virtuose
on 20/07/2025, 19:59:22 UTC
🚀 NITO Whitepaper Released

We’re excited to share that the NITO whitepaper — created by the community, for the community — is now available!


Interesting project, I'll mine some! Are there any dapps or projects in progress or a ecosystem directory?
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 20/07/2025, 19:36:37 UTC
That’s not true. I’ve been working on Puzzle 73 for months and have scanned everything up to prefix 14 from 1000000000000000000 to 14fffffffffffffffff. Higher puzzles like 71+ are absolutely being searched, even if they haven’t been solved yet.
comme on Smiley)  how long and what power did you scan from 10 to 14.. for puzzle 73 Smiley)
You know how it goes, share too many details and in 2 minutes someone calls you a liar anyway 😉
Let’s just say it took time, decent firepower, and good software. If you know, you know.

Seems as everyone and their dog is a crypto genius these days, breaking boundaries this or that as easy as a weekend barbecue.

Needless to say, what you claim as having done has an identical problem size as P71, and requires at a bare minimum a few million $ to accomplish. If you know, you know this is why people like Bram won't bother with 71+ for quite some time. Going after 71 and up is simply throwing money out the window today.

Fair point but you're assuming everyone brute-forces blindly. I’m not claiming miracles, just targeted work over time with filtered subsets and decent resources. Not all efforts cost millions when strategy and persistence are involved. If you know, you know.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 19/07/2025, 21:19:48 UTC
hey man im using 4 Nvidia L4 but i cant find any good software,can you share it?? 

I’m using a custom-built tool I’ve been tweaking for a while, so I’m sticking with that for now. But if you’re on GPUs like the L4, check out VBCr, Keyhunt (CUDA branch), BSGS,  BitCrack, all solid options depending on your approach but I prefer VBCr.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 19/07/2025, 21:11:04 UTC
lol i start searching today,using 4 Nvidia L4 each scanning at 335 m/k x to 312 m/k x sec is all about lucky?Huh
But i believe the key is around 7............  why because Puzzle 70 was done in 2019-06-09 and since then nobody have find the key for 71 how many people have being scanning for key 71 since 2019-06-09 so must be around 6....... or 7............  what do you guys think?
because nobody has scanned for 71 until 69 was found
70 was found because the pubkey was intentional leaked..
but the latest found was 69

That’s not true. I’ve been working on Puzzle 73 for months and have scanned everything up to prefix 14 from 1000000000000000000 to 14fffffffffffffffff. Higher puzzles like 71+ are absolutely being searched, even if they haven’t been solved yet.
comme on Smiley)  how long and what power did you scan from 10 to 14.. for puzzle 73 Smiley)

You know how it goes, share too many details and in 2 minutes someone calls you a liar anyway 😉
Let’s just say it took time, decent firepower, and good software. If you know, you know.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 19/07/2025, 20:46:29 UTC
lol i start searching today,using 4 Nvidia L4 each scanning at 335 m/k x to 312 m/k x sec is all about lucky?Huh
But i believe the key is around 7............  why because Puzzle 70 was done in 2019-06-09 and since then nobody have find the key for 71 how many people have being scanning for key 71 since 2019-06-09 so must be around 6....... or 7............  what do you guys think?
because nobody has scanned for 71 until 69 was found
70 was found because the pubkey was intentional leaked..
but the latest found was 69

That’s not true. I’ve been working on Puzzle 73 for months and have scanned everything up to prefix 14 from 1000000000000000000 to 14fffffffffffffffff. Higher puzzles like 71+ are absolutely being searched, even if they haven’t been solved yet.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 16/07/2025, 21:56:27 UTC
It's incredible how many Einsteins have appeared since AI came into being.  Cheesy Cheesy Cheesy
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 14/07/2025, 04:44:48 UTC
trust me bro Grin

The Bitcoin puzzle could be a CIA honeypot to catch hackers brute-forcing keys.  Trust me bro Grin

Hmm, I'd say that's highly unlikely. However, it's possible that it's a conglomerate of server-hosting companies. It makes more money than it gives away, I'm certain of that.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 14/07/2025, 04:11:58 UTC
What to do if I found the Public Key and Private Key?

Don't trust people here, lot of scammers. So if you find these key you need to send it to me in private message, if the key are correct, I send you the prize trust me bro Grin
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 07/07/2025, 16:01:00 UTC

What about prefix jump ? Example after find  1PWo3JeBthen prefix then jump 1-3  trilion key ...

Mybe have to test safe jump range and how many prefix digit.  

Seems the aaaa bbbb filtering only reduce less than 2% 🙃. Now im focusing on finding sample range from quadrilion of keys to consider the safe jump range

Filtering doesn’t actually reduce the work in this context because you still have to find the correct value before you can filter it. It’s like claiming you can pick winning lottery tickets faster by throwing out the losing ones, but you still have to check each ticket to know if it’s a winner. With private keys, unless you already have extra information (like a public key prefix that actually leaks some useful bits), every candidate has to be generated and checked in full. Filtering after the fact doesn’t magically cut down the number of computations, it just adds an unnecessary layer. You can only filter something once you’ve already done the work to find out if it matches or not so there’s no real gain.

Skipping large key ranges based only on prefix distance is fundamentally flawed. There’s no guarantee the target isn’t in those skipped ranges. It’s not about distance, it’s about coverage, Bitcoin keys are uniformly distributed, so skipping based on superficial patterns will always risk missing the correct key. That’s why no serious cryptographer uses such methods but of course you can try your luck ^^
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 07/07/2025, 15:35:47 UTC

What about prefix jump ? Example after find  1PWo3JeBthen prefix then jump 1-3  trilion key ...

Mybe have to test safe jump range and how many prefix digit.  

Seems the aaaa bbbb filtering only reduce less than 2% 🙃. Now im focusing on finding sample range from quadrilion of keys to consider the safe jump range

Filtering doesn’t actually reduce the work in this context because you still have to find the correct value before you can filter it. It’s like claiming you can pick winning lottery tickets faster by throwing out the losing ones, but you still have to check each ticket to know if it’s a winner. With private keys, unless you already have extra information (like a public key prefix that actually leaks some useful bits), every candidate has to be generated and checked in full. Filtering after the fact doesn’t magically cut down the number of computations, it just adds an unnecessary layer. You can only filter something once you’ve already done the work to find out if it matches or not so there’s no real gain.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 06/07/2025, 21:11:32 UTC
By trying to be right, you're being silly. Your craps simulation is correct for that specific game, but it doesn't model prefix pruning. With prefixes, we abort at the first false positive without betting on future events. The probability of success is 63.2%, as my simulations demonstrate. You still fail to distinguish between sequential processes with aborts (prefixes) and conditional bets (your dice).

You inadvertently demonstrate that when you change the rules, the probability changes.

This validates my claim that "Every stopping criterion changes the probability of success."

Prefix pruning: 63.2%

Random stopping: 50%

Your craps bet: 48.2%

Dude, my craps bet (which is actually yours) is exactly what you described as "natural to bet that 6 doesn't appear again in 4 rolls". So if there's anything crappy about it, it was your original statement, which was proven to be false. If you happen to find something's wrong with it, please let me know and I'm happy to refactor it according to your conditionals or whatever. But the results will be identical, since it's simply empirical proof that in whatever 4 rolls (sequential, skipped, timed out and resumed, changing the dice, etc etc etc), any value has a 51.8% chances of showing up at least once. Conditionals are irrelevant, just like skipping is irrelevant. I think you should be the one to go back to the drawing board here.

If you have some other statement about something, or you discover what's wrong with the simulations (not flakes of snow) let me know. Congrats on discovering and demonstrating that there's a 63% chance of success to hit X at least once, when p=1/N, in N tries, btw. No one really bothered to do the math on that one. You're definitely the first.

Forget it, this guy’s ego is so inflated he never even considered that if prefix search actually worked or had any real merit, academics would’ve published on it by now. But there’s nothing because it’s just hot air. You can use any kind of filtering you want, but without the public key, you’ll still end up brute-forcing every private key anyway. In fact, its so-called "prefix search" just makes things less efficient. Good luck to him on his impossible quest.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 04/07/2025, 02:21:34 UTC

The math is simple: for example, in a 4096-bit search space, an h160 prefix is ​​found on average once. If this were frequent (2 out of 3 prefixes in 4096 bits), the hash function would be broken. That's why this is a good guide for probabilistic searches. Anyone who says otherwise is wrong.


The math is simple: for example, in a 6 dice rolls, a "six" comes up on average once. If this were frequent (2 out of 3 times in 6 rolls), the die would be broken. That's why this is a good guide for probabilistic searches. Anyone who says otherwise is wrong.

So, if I'm rolling one of my 6 dice one at a time and a "six" shows up, say, on the fifth roll, then the last roll has a lower chance of being a "six", right? Otherwise the die is rigged. I guess we need to rewrite the definition of uniform distribution in math textbooks.

Your analogy with dice tells me you still don't understand prefix searching. No, that's not what I'm saying. If you focused on understanding more and hating less, you would easily understand what the probabilistic prefix search method is based on. The fact that a six appears on the fifth roll doesn't mean that another 6 is less likely on the sixth; they are independent events. But it is true that if they tell you to roll a die 6 times, and the second time you got a 6, it's normal for you to bet that there won't be another 6 in the next 4 events. Although it could happen, statistically it doesn't change the probability of 1/6.

Now, when I say it's broken, if it becomes frequent, it would mean that for every 6 rolls you get two 6s. If these occurrences become frequent, it could be said that the die is rigged or defective.

And in the case of prefixes, the same thing happens. If the probability 2/4096 becomes common, it would mean the hash is broken.

I don't think their hatred will stop them from seeing what the script already irrefutably verifies.

Do you get it now?



Dude, every dev watching this thread is cracking up.

A 3-hex prefix is a 12-bit filter, 1 hit per 4 096 keys. Your script “wins” only because you fence the target inside a toy range of 2¹⁷ keys. In that puddle you expect 32 prefix matches, so stumbling on the right one 60 % of the time is no feat at all.

Scale to the real 2²⁵⁶-key ocean and you face 2²⁴⁴ such blocks; even with your pruning you’d still churn through ≈2²⁵⁵ hashes, basically the same work as a straight brute-force. The supposed speed-up vanishes.

If prefixes really repeated 2 times out of 3, SHA-256 would already be toast. They don’t, so your “probabilistic” shortcut is just a dressed-up linear scan in an aquarium.

Long story short: the math buries your claim, and your script is a party trick nothing more. You’re so ridiculous at this point, blinded by your own ignorance that it’s hard to tell whether you’re doing it on purpose or you’re just trolling for attention. No one’s fooled, so just move along.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 04/07/2025, 00:42:53 UTC
Buddy, here’s the A + B you keep dodging:

A. Toy range vs. real world
Your demo space = 2¹⁷ ≈ 131 k keys.
Hit rate for a 3-hex prefix there: (131 072 / 4096) ≈ 32 possible matches — easy pickings.

B. Actual Bitcoin key space
Size = 2²⁵⁶ ≈ 1.16 × 10⁷⁷.
Same prefix filter: 2²⁵⁶ / 4096 = 2²⁴⁴ ≈ 2.9 × 10⁷³ candidates.

At 1 trillion keys/sec (fantasy hardware) you’d still need ≈ 9 × 10⁶¹ years to exhaust those 2.9 × 10⁷³ keys. Your “67% success” collapses to 0 % in any universe that isn’t a 131 k fishbowl.

Uniformity doesn’t save you; it condemns you: every prefix is evenly packed with an astronomical number of keys. All you did was shrink the pond, hook a fish, then brag you’ve solved deep-sea fishing.

Keep moving those goalposts, mathematics will keep flattening them.

First, you don't need to quote the entire content, just what you're going to answer. This way, you avoid post-to-post content overload; no one is interested in reading the same thing every other post.

Second, as I told you, the search space doesn't matter here. It's statistically the same. If my script uses a low bit rate and wins 63% of the time on average, the same thing will happen using 10 prefixes and blocks of 1099511627776, or whatever size you come up with, as long as the idea is respected.

Third, you're confusing collision frequency with success probability.

Dude, you keep proving you don’t grasp basic probability.

Prefix math: 101

A 3-hex prefix is a 12-bit filter → 1 / 4096 hit-rate no matter the keyspace size.

Extend to a 10-hex prefix? That’s 40 bits: success odds = 1 / 2⁴⁰ ≈ 1 in a trillion.

Now look at your “63% win” claim:

You preset the target inside every block you scan, so there’s guaranteed to be at least one key that matches the full h160. Of course you “find” it most of the time, your script is playing hide-and-seek in a broom closet.

Scale that closet up to the real 2²⁵⁶-key universe and the expected number of matches per block collapses from “one or two” to 0.000…1 (40+ zeros). Your success rate plummets to statistical dust.

Different block sizes, ten prefixes, a bajillion prefixes doesn’t matter. Uniform randomness means you still need to brute-force ≈2²⁴⁴ keys for a single 3-digit hit on average. That’s 9 × 10⁶¹ centuries at 1 T keys/sec.

Stop moving the goalposts; start learning the rules. Your “idea” violates arithmetic, not just cryptography.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 04/07/2025, 00:17:37 UTC
You should straight up go to Princeton and give some lectures about this before they call the police.

Finding more than 1 (a prefix of length 3) in 4096 is rare, and omitting the target is even rarer. The length of the prefix doesn't matter as long as the block matches what's expected.
Nor do you try as much as you try, the probability will remain ≈ the same.
If finding more identical prefixes within 4096 were no longer so rare, the hashes would be broken.

I will again state that you don't really understand how an uniform distribution works. You're simplifying to a yes/no gambling, forgetting completely about the basics of it.

If finding more prefixes in some portion means the hash's broken, man, please don't make me provide actual examples about how wrong you are.

When you skip some rest of "block" as you call it, you simply move off the chances of finding (or not finding) another prefix, into the next block. Basically, a futile operation to perform, because it goes the other way around too: when you fail to find some prefix in the next "block" or whatever, it might simply mean (at an average level) that it was found in the skipped portion. Or any other portion, anywhere, to be honest. Because, for the 9000th time (for you): it's an uniform distribution, all keys are as likely as others, and all ranges are as likely as any other ranges.

So you're simply selling some illusion of some sort of benefit, but it does not exist, neither in theory, nor in practice. It would be great if it would, though.

The advantage of prefixes is that it's not common to find multiple prefixes of a hash in a space x where their probability is 1/x. This math isn't going to change even if you cry. For that single, indisputable mathematical reason, searching with prefixes is the most convenient, since they're based on REAL probabilities, the properties of a uniform distribution.

1st grade fact: A uniform distribution only means that the target is equally distributed, not that all stopping criteria perform equally.

LOL, each stopping criterion changes the probability of success within the block, even with a uniform distribution.

Pruning by 3 hex prefix: success ≈ 63.2%

Stopping at a random point: success ≈ 50%

Finding ≥ 2 prefix collisions in 4096 keys is very rare; if it were frequent, the hash function would be compromised (this doesn't mean there can't be cases where it happens, but the point is that for what the prefix lookup requires, it works).

Missing the target due to premature collision occurs in the remaining ~36.8%, just as the script predicts. I don't understand why you flatly deny this fact.

Instead of continuing to cry or hesitate, accept it.

I'm 100% sure you understand what I mean; your time, like the modern Digaran, is simply imprinted on you.


snip

Come on, man, you're taking all the fun out of mixing so much nonsense into a single post.

The 3-hex filter is 1/4096 in any space. It doesn't matter if the hash has 40 digits, the probability of matching the first 3 is always the same.

Limiting the range doesn't "fix" the math: the uniformity remains within that subspace, and the formula applies the same.

Going from 4096 to 2**256 only changes the scale. The exponential form is the same; the relative result remains the same.

kgtimes, you won't respond to this guy's statements, or you'll apply the "the enemies of my enemies are my friends" rule Grin.


Buddy, here’s the A + B you keep dodging:

A. Toy range vs. real world
Your demo space = 2¹⁷ ≈ 131 k keys.
Hit rate for a 3-hex prefix there: (131 072 / 4096) ≈ 32 possible matches — easy pickings.

B. Actual Bitcoin key space
Size = 2²⁵⁶ ≈ 1.16 × 10⁷⁷.
Same prefix filter: 2²⁵⁶ / 4096 = 2²⁴⁴ ≈ 2.9 × 10⁷³ candidates.

At 1 trillion keys/sec (fantasy hardware) you’d still need ≈ 9 × 10⁶¹ years to exhaust those 2.9 × 10⁷³ keys. Your “67% success” collapses to 0 % in any universe that isn’t a 131 k fishbowl.

Uniformity doesn’t save you; it condemns you: every prefix is evenly packed with an astronomical number of keys. All you did was shrink the pond, hook a fish, then brag you’ve solved deep-sea fishing.

Keep moving those goalposts, mathematics will keep flattening them.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 03/07/2025, 22:46:38 UTC

Prefixes [1PWo3JeB9j] identical to number800 If there is, does it have an impact on the target key search process?

The math is simple: for example, in a 4096-bit search space, an h160 prefix is ​​found on average once. If this were frequent (2 out of 3 prefixes in 4096 bits), the hash function would be broken. That's why this is a good guide for probabilistic searches. Anyone who says otherwise is wrong.

It's not worth relying on addresses; you're just wasting resources.

Here's a script that shows you, without much fanfare, that prefix searching isn't as useless as some claim. Run it yourself and draw your own conclusions:

The Iceland module is required.

https://github.com/iceland2k14/secp256k1 The Iceland files must be in the same location where you saved this script. Some operating systems require Visual Studio Redistributables to be installed for it to work.

You can adjust the number of tests by setting total_runs = 100.

Code:
import random
import secp256k1 as ice
import concurrent.futures

# Configuration
START = 131071
END = 262143
BLOCK_SIZE = 4096
MIN_PREFIX = 3
MAX_WORKERS = 4
TOTAL_RUNS = 100

def generate_blocks(start, end, block_size):
    """
    Split the keyspace [start..end] into blocks of size block_size,
    then shuffle the block list for randomized dispatch.
    """
    total_keys = end - start + 1
    num_blocks = (total_keys + block_size - 1) // block_size
    blocks = [
        (start + i * block_size,
         min(start + (i + 1) * block_size - 1, end))
        for i in range(num_blocks)
    ]
    random.shuffle(blocks)
    return blocks

def scan_block(b0, b1, target):
    """
    Scan keys in [b0..b1] looking for target.
    Prune the block only if both conditions happen in order:
      1) A false positive on MIN_PREFIX hex chars
      2) Later, a match on the first MIN_PREFIX-1 hex chars
    """
    full_pref = target[:MIN_PREFIX]
    half_pref = target[:MIN_PREFIX - 1]

    for key in range(b0, b1 + 1):
        addr = ice.privatekey_to_h160(0, 1, key).hex()
        if addr == target:
            return True, key
        if addr.startswith(full_pref) and addr != target:
            next_key = key + 1
            break
    else:
        return False, None

    for key in range(next_key, b1 + 1):
        addr = ice.privatekey_to_h160(0, 1, key).hex()
        if addr == target:
            return True, key
        if addr.startswith(half_pref):
            break

    return False, None

def worker(block_chunk, target):
    """
    Scan each block in block_chunk sequentially.
    Return the key if found, else None.
    """
    for b0, b1 in block_chunk:
        found, key = scan_block(b0, b1, target)
        if found:
            return key
    return None

def parallel_scan(blocks, target):
    """
    Distribute blocks round-robin across MAX_WORKERS processes.
    Returns the discovered key or None.
    """
    chunks = [blocks[i::MAX_WORKERS] for i in range(MAX_WORKERS)]
    with concurrent.futures.ProcessPoolExecutor(max_workers=MAX_WORKERS) as executor:
        futures = [executor.submit(worker, chunk, target) for chunk in chunks]
        for future in concurrent.futures.as_completed(futures):
            key = future.result()
            if key is not None:
                for f in futures:
                    f.cancel()
                return key
    return None

if __name__ == "__main__":
    found_count = 0
    not_found_count = 0

    for run in range(1, TOTAL_RUNS + 1):
        target_key = random.randint(START, END)
        target = ice.privatekey_to_h160(0, 1, target_key).hex()

        blocks = generate_blocks(START, END, BLOCK_SIZE)
        key = parallel_scan(blocks, target)

        if key is not None:
            found_count += 1
        else:
            not_found_count += 1

    print(f"\nOf {TOTAL_RUNS} runs, found: {found_count}, not found: {not_found_count}")

R: Of 100 runs, found: 67, not found: 33

If you reduce the block size by 25% BLOCK_SIZE = 3072 your success percentage will obviously increase, but it will involve covering more space to increase your success rate.

r:Of 100 runs, found: 78, not found: 22


Therefore, searching for prefixes is the best method as long as you are not trying to scan the entire range (just try your luck).


Disclaimer for the know-it-alls: yes, the code is partially done with AI but it is completely correct.

But your simple math forgets math  Cheesy

1 An h160 is 40 hex digits; matching just 3 gives you a 1 in 4096 filter.
2 Your script already knows the target key sits in a tiny 131 k value window: rigged lotto, congrats.
3 A 67% hit rate when the fish is trapped in the bowl only shows your heuristic is shaky; at the real scale (2^256 keys) that boost rounds to 0.000%.
4 If 2/3 of prefixes really repeated, SHA-256 would be broken, so yet you use it to “prove” it’s secure. That’s some top-tier circular logic.

Scanning prefixes in a kiddie pool proves nothing except your confusion between a demo and Python sleight of hand.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 17/05/2025, 09:38:55 UTC
Much ado about nothing..

You’re being an ass with people, criticising them about their inability to code. That’s very ironic.
You conveniently deleted all your posts about your AI generated C-bit solution which was not only not working, but also displaying false speeds (Some of this is still visible in quoted posts)

So yeah, when you spur bullshit here, I will call you out. I don’t think it’s trolling. I think it’s warranted.

You little idiot, you can’t even write your own code. You have to beg others for help and dangle rewards so they’ll give you theirs. Seriously, who’s the ass here? My code worked perfectly and ran at the proper speed, which just proves you don’t know the first thing about programming. And no, it wasn’t generated by AI, I never touch AI for coding because it’s way too limited. I’m running my C-bit version right now, and it’s already miles faster than your ridiculous linear one. You make me laugh, spouting claims with no evidence while I back up everything I say. Face it: you’re just frustrated like many others here.  Cheesy Cheesy Cheesy Cheesy

That’s quite disrespectful.
I don’t see why I would be frustrated, I solved 2 previous puzzles.
I did so using code I wrote myself, so I might know the first thing (or two) about programming.

Yeah, yeah, whatever. A clown’s still a clown and a liar on top of that.  Cheesy Cheesy


Again with the disrespect.
Everything I say has been backed with proof on this thread.

Respect for solving those puzzles, but how exactly did you prevent bots from stealing the rewards? How did you stop bot theft from happening?
Private mempool tx using marathon’s splitstream service.

Don’t play that game with me, you’ll be the one losing. I know more than you think  Cheesy
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 17/05/2025, 09:31:47 UTC
Much ado about nothing..

You’re being an ass with people, criticising them about their inability to code. That’s very ironic.
You conveniently deleted all your posts about your AI generated C-bit solution which was not only not working, but also displaying false speeds (Some of this is still visible in quoted posts)

So yeah, when you spur bullshit here, I will call you out. I don’t think it’s trolling. I think it’s warranted.

You little idiot, you can’t even write your own code. You have to beg others for help and dangle rewards so they’ll give you theirs. Seriously, who’s the ass here? My code worked perfectly and ran at the proper speed, which just proves you don’t know the first thing about programming. And no, it wasn’t generated by AI, I never touch AI for coding because it’s way too limited. I’m running my C-bit version right now, and it’s already miles faster than your ridiculous linear one. You make me laugh, spouting claims with no evidence while I back up everything I say. Face it: you’re just frustrated like many others here.  Cheesy Cheesy Cheesy Cheesy

That’s quite disrespectful.
I don’t see why I would be frustrated, I solved 2 previous puzzles.
I did so using code I wrote myself, so I might know the first thing (or two) about programming.

Yeah, yeah, whatever. A clown’s still a clown and a liar on top of that.  Cheesy Cheesy