Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Bram24732]

I suppose finding two "aa" in 256 is just as likely as finding one "aa" in 256.  After all, hashes don’t "understand" that... lol.

No, but finding one “aa” after you found an “aa” is just as likely as finding “aa” if you didn’t find any “aa”

2 "aa" is about 0.0015/256,  1  "aa" is  about  1/256.

and finding "aa" twice in 256 samples is much rarer than finding just one. But, as you correctly pointed out earlier, hashes themselves don’t "care". each search is statistically fair and unaffected by prior results.

Probability paradoxes, right?

I don’t see the paradox

[kTimesG]

It's faster to simply do Pt - j*Pb = R and look for x in the precomputed [startRange, startRange + 1 billion] table.

This is basically how BSGS works.

what is j* here and why are we storing {ps+pb , ps+2pb......}.

My method is to start with that dB in hands then take ps+pr(random scalar pub key between {1...2^133})=R     then       pt+(-pr)=Q
Then Q + (-R)=T  then look for X,T in dB if not found we store that x of PR and its scalar then  take another random scalar , if random scalars sum reach 2^133 we restart from orginal

j is the loop index, from 1 to 1 billion or until you find the key. Maybe you should first familiarize with BSGS basic concepts, you seem to want to double the number of operations for no reason.

Sorry but your 135 algorithm is nothing more than basically a linear search, which is like the worst possible way of searching. It already is a huge, huge task to do 2**68 operations using something like Kangaroo to solve it, your strategy runs in 2**109 steps or so, which is like 1 trillion times slower.

I don’t see the paradox

It's safer to let it go. He's right.

[farou9]

j is the loop index, from 1 to 1 billion or until you find the key. Maybe you should first familiarize with BSGS basic concepts, you seem to want to double the number of operations for no reason.

Sorry but your 135 algorithm is nothing more than basically a linear search, which is like the worst possible way of searching. It already is a huge, huge task to do 2**68 operations using something like Kangaroo to solve it, your strategy runs in 2**109 steps or so, which is like 1 trillion times slower.

so j is how many billion until we reach the tp ,actually we both know not bags nor kangaroo can help with my cpy , unless I invent something new that work I am not gonna get anything except for wasting my time.

Not exactly linear ,its random

[kTimesG]

It's paradoxical, because while I went straight to the point with what I wanted to show, you don’t accept it because the math turned it into an ego race. Your proposal is total distance / simulations.

It's like saying Usain Bolt runs 10 races of 100 meters against Pepe, wins 7, and then concluding that both are equal by adding up 100m x 10 = 1000m. Since both have covered the same distance, both runners must be equal.

That’s magnificently absurd.

Except you forgot that your code counts EXECUTED checks, not FULL RANGE checks. So they are not running the same distance at all, they do not cover the entire track, only up to finding the solution.

So what is absurd, is your method of comparation by dividing actual work by number of wins, without caring about relative effort, and even ties.

By your judgement, if Usain wins by 1 millisecond, than Pepe didn't even compete.

And also by your judgement, the time (ops) quantity does not even matter, all wins are equal.

And I think you forgot that somehow, magically, prefix method "wins" even when not even looking for a prefix - simply by breaking itself up once every whatever chances.

[kTimesG]

You're obviously failing.

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

I have the ultimate answers for you, just so we end this here hopefully.

1. You are right.
2. Python is rigged.
3. We're all in error, making fatal fallacies.
4. You are right.
5. Prefix working better no matter if no prefix is searched definitely doesn't have anything to do with basic statistics.
6. Keep on drawing tic-tac-toe as replies to posts trying to explain you things.
7. If Pepe loses, it makes sense to add his run time to the next round as a punishment - he needs to catch up!
8. You are right.
9000. You are right.

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