Bitcoin puzzle transaction ~32 BTC prize to who solves it

[kTimesG]

Adding suspense—if Bram divides bit69 and randomizes the order...

Why doesn’t Bram’s ordering introduce rigged prefix searching in its order to achieve a higher success rate?

Wouldn’t the creator know that Bram manipulated his search...? LOL.

There is a perfectly valid explanation for why you see the prefix method as winning, and it has nothing to do with the order of blocks, which is shuffled at random before every simulation.

But because you are not bothering to actually read or understand what we're trying to transmit to you, because you're too busy "lol"-ing and accusing everyone of being in complete error, here it is:

Both methods traverse the same blocks in the same order

Now, I won't even attempt to bother to explain the consequences of this. You would just skip through, and the other guys don't really need the explanation anyway, if they just think a little.

For you, it's called "same conditions". For us, this is exactly the reason the prefix one wins more, but when it loses, it loses in a big style - making both methods do equal work per simulation, on average.

It also has to do a lot with the way you chose your parameters, for the number of blocks and so on.

Maybe go ask your beloved AI what's going on there.

Oh, and also I forgot: you are right.

[fixedpaul]

Now, to play around with your theory: if both follow the same order, and that order changes in each simulation, why on earth does it favor prefixes? Where’s the magic?

Does it prove that prefix-based search is better? Or is Python rigged?

No magic here — all the scripts made by you, me, and others only prove that all the methods are equivalent. As the number of total checks are the same.

I specifically made you a Python script (with AI, as you like), with no prefixes, no hashes, just to show how easy it is to introduce a bias in the number of wins and that what matters is the total number of checks. Or do you seriously think that counting from 1 to 20 first and then from 50 to 21 somehow increases your chances of finding a uniform random number?

And on top of that, having your method search using random prefixes doesn’t change the result. Have you asked yourself why?

Honestly, I don’t know how to make it any more basic than this — but maybe you’re just a troll and should simply be agreed with. I will give up

[Menowa*]

Why people keep sending sats to puzzle wallets?

[kTimesG]

Why people keep sending sats to puzzle wallets?

So people get more motivated to solve them. Sometimes to send a "f**k you, you're contributing to global warming" to the solver.
But most who try to grab that 1 extra satoshi in the pot, remain with Bitcoin dust in their eyes, and actual dust in their wallets.

[fantom06]

Why people keep sending sats to puzzle wallets?

Coздaтeль дocылaeт нa aдpecc биткoинa,этo пoдcкaзкa,гдe в диaпaзoнe нaxoдитcя ключ

This is your theory, but I don't see any proof

[7^k*G]

It's funny to watch the proponents of the prefix theory. the point coordinates themselves are hashes, and applying sha256 and rmd160 to them produces a set of bits that is in no way related to the private key. In your theory, the match of the first m bits in the hash should be repeated every 2^m iterations, but this is not at all the case. In a 120-bit field, it will indeed be found approximately 2^(120-m) times, but to understand the pattern in the puzzle range, you need to go through at least half of it, which is impossible. Here is a simple code (m=12) proving that the distance from identical prefixes is unpredictable, although it averages 2^m steps:

Code:

from os import urandom
from hashlib import sha256, new

p = 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

Gx = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
Gy = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

def add(x, y, z, w):
    y = (pow(x - z, -1, p) * (y - w) if x != z else pow(y + y, -1, p) * x * x * 3) % p
    x = (y * y - x - z) % p
    return x, (y * (z - x) - w) % p

def multiply(k, z, w):
    x, y = z, w
    for i in bin(k % n)[3:]:
        x, y = add(x, y, x, y)
        if i == '1':
            x, y = add(x, y, z, w)
    return x, y

def hash160(x, y):
    return new('ripemd160', sha256((b'\x03' if y & 1 else b'\x02') + x.to_bytes(32, 'big')).digest()).digest()

def random_key():
    return 1 + int.from_bytes(urandom(32), 'little') % ((n - 1) // 2)

x, y = multiply(random_key(), Gx, Gy)

i, s, c = 0, 0, 0

while 1:
    h = hash160(x, y)
    
    i += 1
    
    if h[0] == 0 and h[1] >> 4 == 0:
        s += i
        c += 1
        
        print(h.hex(), i, s / c)
        
        i = 0
    
    x, y = add(x, y, Gx, Gy)

[nomachine]

@nomachine
I repeat request for add function in cyclone
Where we could check list of hash160 instead of only 1 hash160
Example switch -f hash160.txt
More default -b 4 should be ended, if need apply -b, if no need then user don't apply -b switch for buildup speed
Thankx

I don't work with Cyclone anymore. Warpseed GPU scripts live in my head now.

[Akito S. M. Hosana]

Warpseed GPU scripts live in my head now.

Can we please have a piece of that? 

[FrozenThroneGuy]

@nomachine
I repeat request for add function in cyclone
Where we could check list of hash160 instead of only 1 hash160
Example switch -f hash160.txt
More default -b 4 should be ended, if need apply -b, if no need then user don't apply -b switch for buildup speed
Thankx

I don't work with Cyclone anymore. Warpseed GPU scripts live in my head now.

Switch it to VSL synthesis, right now GPU speed up looks like a “penny hunting”. I have done a few work trying to speed up present realization of secp256k1 via GPU and have no idea how to do it. +/- 5-10 percent ax from present levels of speed. OR, that more efficient, try to develop “index-calculus” for Secp

[Akito S. M. Hosana]

TNX for sharing,very well i look later what you have here 

We can review the code until the next New Year. Someone needs to convert it to C, and we have a couple of people here who can do it in two days 

[nomachine]

I have done a few work trying to speed up present realization of secp256k1 via GPU and have no idea how to do it.

I'm not even considering secp256k1 warpseeding through the GPU—just SHA-256 and Base58 

[Akito S. M. Hosana]

I have done a few work trying to speed up present realization of secp256k1 via GPU and have no idea how to do it.

I'm not even considering secp256k1 warpseeding through the GPU—just SHA-256 and Base58 

Wait, are you actually just processing WIFs using a bunch of GPUs? 

[nomachine]

I have done a few work trying to speed up present realization of secp256k1 via GPU and have no idea how to do it.

I'm not even considering secp256k1 warpseeding through the GPU—just SHA-256 and Base58 

Wait, are you actually just processing WIFs using a bunch of GPUs? 

Yep, I've been writing about it for the last five pages, if you haven't noticed. And let me tell you a secret: only WIFs starting with "5HpHagT65TZzG1PH3CSu63k8DbpvD8s5i". 

[fecell]

Did U know, 0.5G point has extremly low X coordinate 

Code:

Qx: 0x00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63
Qy: 0xc0c686408d517dfd67c2367651380d00d126e4229631fd03f8ff35eef1a61e3c

[papiro08]

🔮 Curvature in Bitcoin's key space?
In physics, the curvature of space-time allows a ship (hypothetically) to take a shortcut, like in a warp drive. In Bitcoin's key space (a space of 2²⁵⁶ possible private keys), finding a specific key is like searching for a grain of sand in an entire universe. But... what if we could "curve" that space somehow? A lot of Netflix, right?

[Bram24732]

I suggest we stop engaging with McDouglas.
We took enough time and created enough resources for anyone with half a brain to understand why prefix theory is flawed. We’re just polluting the thread for other people at this point.

[nomachine]

🔮 Curvature in Bitcoin's key space?
In physics, the curvature of space-time allows a ship (hypothetically) to take a shortcut, like in a warp drive. In Bitcoin's key space (a space of 2²⁵⁶ possible private keys), finding a specific key is like searching for a grain of sand in an entire universe. But... what if we could "curve" that space somehow? A lot of Netflix, right?

You aren’t fighting the entire 2²⁵⁶ universe—just a 2⁶⁹ keyspace.

My approach:

Instead of using secp256k1 for key derivation, I propose:

Generating all possible uncompressed Wallet Import Formats (WIFs) within the 69-bit keyspace (specifically, from 0x10000000000000000 to 0x1FFFFFFFFFFFFFFFF).

Optimizing the process using warpseeding—a custom acceleration method combining SHA-256 hashing and Base58 encoding for faster WIF generation.

Checking each WIF against the Puzzle #69 address to identify the correct private key.

Bypassing curve operations entirely

P.S. Converting each WIF to a Bitcoin address (which does require secp256k1, but only after filtering).

[Akito S. M. Hosana]

🔮 Curvature in Bitcoin's key space?
In physics, the curvature of space-time allows a ship (hypothetically) to take a shortcut, like in a warp drive. In Bitcoin's key space (a space of 2²⁵⁶ possible private keys), finding a specific key is like searching for a grain of sand in an entire universe. But... what if we could "curve" that space somehow? A lot of Netflix, right?

You aren’t fighting the entire 2²⁵⁶ universe—just a 2⁶⁹ keyspace.

My approach:

Instead of using secp256k1 for key derivation, I propose:

Generating all possible uncompressed Wallet Import Formats (WIFs) within the 69-bit keyspace (specifically, from 0x10000000000000000 to 0x1FFFFFFFFFFFFFFFF).

Optimizing the process using warpseeding—a custom acceleration method combining SHA-256 hashing and Base58 encoding for faster WIF generation.

Checking each WIF against the Puzzle #69 address to identify the correct private key.

Bypassing curve operations entirely

P.S. Converting each WIF to a Bitcoin address (which does require secp256k1, but only after filtering).

How do you filter characters after "5HpHagT65TZzG1PH3CSu63k8DbpvD8s5i" ? 

[nomachine]

🔮 Curvature in Bitcoin's key space?
In physics, the curvature of space-time allows a ship (hypothetically) to take a shortcut, like in a warp drive. In Bitcoin's key space (a space of 2²⁵⁶ possible private keys), finding a specific key is like searching for a grain of sand in an entire universe. But... what if we could "curve" that space somehow? A lot of Netflix, right?

You aren’t fighting the entire 2²⁵⁶ universe—just a 2⁶⁹ keyspace.

My approach:

Instead of using secp256k1 for key derivation, I propose:

Generating all possible uncompressed Wallet Import Formats (WIFs) within the 69-bit keyspace (specifically, from 0x10000000000000000 to 0x1FFFFFFFFFFFFFFFF).

Optimizing the process using warpseeding—a custom acceleration method combining SHA-256 hashing and Base58 encoding for faster WIF generation.

Checking each WIF against the Puzzle #69 address to identify the correct private key.

Bypassing curve operations entirely

P.S. Converting each WIF to a Bitcoin address (which does require secp256k1, but only after filtering).

How do you filter characters after "5HpHagT65TZzG1PH3CSu63k8DbpvD8s5i" ? 

You just have to know everything, don’t you?   

[Akito S. M. Hosana]

🔮 Curvature in Bitcoin's key space?
In physics, the curvature of space-time allows a ship (hypothetically) to take a shortcut, like in a warp drive. In Bitcoin's key space (a space of 2²⁵⁶ possible private keys), finding a specific key is like searching for a grain of sand in an entire universe. But... what if we could "curve" that space somehow? A lot of Netflix, right?

You aren’t fighting the entire 2²⁵⁶ universe—just a 2⁶⁹ keyspace.

My approach:

Instead of using secp256k1 for key derivation, I propose:

Generating all possible uncompressed Wallet Import Formats (WIFs) within the 69-bit keyspace (specifically, from 0x10000000000000000 to 0x1FFFFFFFFFFFFFFFF).

Optimizing the process using warpseeding—a custom acceleration method combining SHA-256 hashing and Base58 encoding for faster WIF generation.

Checking each WIF against the Puzzle #69 address to identify the correct private key.

Bypassing curve operations entirely

P.S. Converting each WIF to a Bitcoin address (which does require secp256k1, but only after filtering).

How do you filter characters after "5HpHagT65TZzG1PH3CSu63k8DbpvD8s5i" ?  

You just have to know everything, don’t you?  

Well, I’m just asking because it’s impossible to break through the 51 – 33 = 18 missing Base58 characters—unless there’s some trick. If the missing characters follow a predictable structure (e.g., repeated segments, checksums, or known prefixes/suffixes), then maybe. But there is no pattern here—only the first 33 characters are repeated. Checksum + segments = lol?  

5HpHagT65TZzG1PH3CSu63k8DbpvD8s5iq4NLznbSoMvfzUuhdh
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ipfXCoMnmssNNsN77qV
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ipGvCSgayELk4Uxq4ZA

I've been staring at last 10 WIFs for 20 minutes now.