Bitcoin puzzle transaction ~32 BTC prize to who solves it

[kTimesG]

Yes, you can replace any key by other key.

A logical speedup is to ignore the rest of the elements in the range/set, and choose a new range/set, to maximize chances to find another new element.

Then the new set has exactly the same odds to find a match as the set you were about to run when finishing the range.
It feels counter intuitive, I know. If you want to be convinced just run the odds of both cases by taking a range of size 1000 with 5% probability.

Then how do you explain this: if I have some 32 bits mask, and jump keys based on how many bits the mask matched, then I hash less keys overall, but the total matches are, on average, much better finds than if I traverse linearly?.

Or are you saying that this does not happen?

[Bram24732]

Yes, you can replace any key by other key.

A logical speedup is to ignore the rest of the elements in the range/set, and choose a new range/set, to maximize chances to find another new element.

Then the new set has exactly the same odds to find a match as the set you were about to run when finishing the range.
It feels counter intuitive, I know. If you want to be convinced just run the odds of both cases by taking a range of size 1000 with 5% probability.

Then how do you explain this: if I have some 32 bits mask, and jump keys based on how many bits the mask matched, then I hash less keys overall, but the total matches are, on average, much better finds than if I traverse linearly?.

Or are you saying that this does not happen?

Oh this can clearly happen on a small enough subset because of the huge deviations that may happen.It would not work as well on a bigger scale because everything would even out.

[nomachine]

I made this Python script that helps me automate a task.
The script creates pairs of numbers with a 30-bit jump between them. A 30-bit jump means the difference between the two numbers is exactly 2^30 (which is 1,077,958,656 in decimal). And runs Cyclone to process those numbers.                                                        

Code:

#!/usr/bin/python3

import random
import subprocess

puzzle = 68
add = "1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ"

# Constants
LOWER_BOUND = 2 ** (puzzle - 1)
UPPER_BOUND = (2**puzzle) - 1
BIT_GAP = 2**30  # 30-bit gap (1,077,958,656 in decimal)

count = 0

while True:
    # Generate the first random number within the valid range
    first_number = random.randrange(LOWER_BOUND, UPPER_BOUND - BIT_GAP)
   
    # Calculate the second number with a 30-bit gap
    second_number = first_number + BIT_GAP
   
    # Ensure the second number is within the upper bound
    if second_number > UPPER_BOUND:
        second_number = UPPER_BOUND  # Set second_number to UPPER_BOUND if it exceeds
   
    # Format both numbers as hexadecimal strings without leading zeros
    first_hex = f"{first_number:X}"  # No leading zeros
    second_hex = f"{second_number:X}"  # No leading zeros
   
    # Prepare the command with the generated random values
    command = [
        "./Cyclone",
        "-a", f"{add}",
        "-r", f"{first_hex}:{second_hex}"
    ]
   
    # Print the generated numbers
    print(f"Iteration {count + 1}:")
    print(f"First Number (Hex): {first_hex}")
    print(f"Second Number (Hex): {second_hex}")
    print("Executing Cyclone command...")
    print("-" * 50)
   
    # Execute the command and stream output/error to the terminal in real-time
    process = subprocess.Popen(
        command,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
        text=True
    )
   
    # Flag to track if "FOUND MATCH!" has been found
    found_match = False
    lines_after_match = 0
    lines_to_save = []  # List to store lines 1-10

    # Stream stdout and stderr to the terminal
    while True:
        # Read stdout line by line
        stdout_line = process.stdout.readline()
        if stdout_line:
            print(stdout_line, end="")  # Print stdout in real-time
           
            # Check if "FOUND MATCH!" is in the output
            if "FOUND MATCH!" in stdout_line:
                found_match = True
                lines_to_save.append(stdout_line) 
           
            # If "FOUND MATCH!"
            if found_match:
                lines_after_match += 1
                if lines_after_match <= 8:
                    lines_to_save.append(stdout_line) 
                else:
                    break 
        else:
            break
   
    if found_match:
        with open("found_match.txt", "w") as file:
            file.writelines(lines_to_save)  # Write all 9 lines to the file
        print("================== FOUND MATCH! ==================")
        break  # Exit the script after saving the lines
   
    # Wait for the process to complete
    process.wait()
   
    # Check the return code of the process
    if process.returncode != 0:
        print(f"Cyclone command failed with return code: {process.returncode}")
    else:
        print("Cyclone command completed successfully.")
   
    # Increment counter
    count += 1

Essentially, this is nothing new. Keyhunt does this automatically in random mode.
I don't understand why there's such a big debate about this method. There's nothing special about it. It doesn't mean anything at such large numbers. Without 2,000 GPUs, it doesn’t matter what we do—we could stand on our heads upside down, and it still wouldn't help.  It's like searching for a needle in a galaxy-sized haystack.

 If someone happens to guess the right range, even a potato PC could solve the key. But the challenge is in reducing the reliance on pure luck.

[Desyationer]

Simple funny fact:

Code:

3444afe6 1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ
41a5b0d6 1MVDYgVaSN6iKKEsbzRUAYFrYJaAVVtoQq
238a7f85 1MVDYgVaSN6iKKEsbzRUAYFrYJaZGYdi2Q
3eb9356c 1MVDYgVaSN6iKKEsbzRUAYFrYJ18tqL37q
29998498 1MVDYgVaSN6iKKEsbzRUAYFrYJm6spAMqH
278fe9ef 1MVDYgVaSN6iKKEsbzRUAYFrYJTAzxpd1x
42a96e3a 1MVDYgVaSN6iKKEsbzRUAYFrYJUNAuqgCZ
2311b3eb 1MVDYgVaSN6iKKEsbzRUAYFrYJCuTCDtVQ
466496cf 1MVDYgVaSN6iKKEsbzRUAYFrYJNrmwYeEr
1e8df1f1 1MVDYgVaSN6iKKEsbzRUAYFrYJ1mD4oBCk
4a924cfd 1MVDYgVaSN6iKKEsbzRUAYFrYJyRW7u3K2
4fe774a8 1MVDYgVaSN6iKKEsbzRUAYFrYJFqihogSs
512432d4 1MVDYgVaSN6iKKEsbzRUAYFrYJCvboqqCw
173de50a 1MVDYgVaSN6iKKEsbzRUAYFrYJPR8mCT7o
57a8bef5 1MVDYgVaSN6iKKEsbzRUAYFrYJh7qbpyEk
5aa05368 1MVDYgVaSN6iKKEsbzRUAYFrYJTQSxnH6o
60ac4189 1MVDYgVaSN6iKKEsbzRUAYFrYJzp4rC93E
8ddbbd3e 1MVDYgVaSN6iKKEsbzRUAYFrYJVxqAj7aD
bba161aa 1MVDYgVaSN6iKKEsbzRUAYFrYJEv4gVhoo
be8dec70 1MVDYgVaSN6iKKEsbzRUAYFrYJNfS71CuV
d49aa56b 1MVDYgVaSN6iKKEsbzRUAYFrYJwJMz5iy8
dfe58efe 1MVDYgVaSN6iKKEsbzRUAYFrYJ2Lv1qZxh
fd858113 1MVDYgVaSN6iKKEsbzRUAYFrYJUP3Vb6ze

[nomachine]

Simple funny fact:

Code:

3444afe6 1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ
34e40700 1MVDYgVaSN6iKKEsbzRUAYFrY6jfrk4SPy
317c7db6 1MVDYgVaSN6iKKEsbzRUAYFrY5rSbA3bgy
382be903 1MVDYgVaSN6iKKEsbzRUAYFrYA7364QFRt
3881cc29 1MVDYgVaSN6iKKEsbzRUAYFrYGtXkWfArk
389da227 1MVDYgVaSN6iKKEsbzRUAYFrYMbkmnDf9G
2f3aa840 1MVDYgVaSN6iKKEsbzRUAYFrYjfUggL3eF
39b25964 1MVDYgVaSN6iKKEsbzRUAYFrY3inJcMtGb
3a35629f 1MVDYgVaSN6iKKEsbzRUAYFrY1A618BVkr
3b844a10 1MVDYgVaSN6iKKEsbzRUAYFrYoMVCYRVod
2ca9d027 1MVDYgVaSN6iKKEsbzRUAYFrYHYXwT3Niz
3c588cea 1MVDYgVaSN6iKKEsbzRUAYFrY8wJXpQ9hs
3d253d62 1MVDYgVaSN6iKKEsbzRUAYFrYNqr41oWED
3eb9356c 1MVDYgVaSN6iKKEsbzRUAYFrYJ18tqL37q
3ee5a73a 1MVDYgVaSN6iKKEsbzRUAYFrYA2ZiPLHeZ
29998498 1MVDYgVaSN6iKKEsbzRUAYFrYJm6spAMqH
2929494a 1MVDYgVaSN6iKKEsbzRUAYFrY1RQoYUkMF
28e6dcd8 1MVDYgVaSN6iKKEsbzRUAYFrY35V4HURdy
278fe9ef 1MVDYgVaSN6iKKEsbzRUAYFrYJTAzxpd1x
41a5b0d6 1MVDYgVaSN6iKKEsbzRUAYFrYJaAVVtoQq
42a96e3a 1MVDYgVaSN6iKKEsbzRUAYFrYJUNAuqgCZ
25adfdf0 1MVDYgVaSN6iKKEsbzRUAYFrY2BAwtevaB
433586ef 1MVDYgVaSN6iKKEsbzRUAYFrYNcZ2tAN6a
238a7f85 1MVDYgVaSN6iKKEsbzRUAYFrYJaZGYdi2Q
450862a2 1MVDYgVaSN6iKKEsbzRUAYFrYPW7Fm8j1b
2311b3eb 1MVDYgVaSN6iKKEsbzRUAYFrYJCuTCDtVQ
466496cf 1MVDYgVaSN6iKKEsbzRUAYFrYJNrmwYeEr
481a04a3 1MVDYgVaSN6iKKEsbzRUAYFrYTwy6qMDHL
481f05cd 1MVDYgVaSN6iKKEsbzRUAYFrYKTp23k3Kz
48acb90e 1MVDYgVaSN6iKKEsbzRUAYFrYb1YEYEtqj
1fc98938 1MVDYgVaSN6iKKEsbzRUAYFrYCDUWnHwVR
1e8df1f1 1MVDYgVaSN6iKKEsbzRUAYFrYJ1mD4oBCk
4a924cfd 1MVDYgVaSN6iKKEsbzRUAYFrYJyRW7u3K2
4d2de585 1MVDYgVaSN6iKKEsbzRUAYFrY5ypsYsi5S
4d8d0419 1MVDYgVaSN6iKKEsbzRUAYFrYGFA7x8zsz
4e0dc661 1MVDYgVaSN6iKKEsbzRUAYFrY3F97uBPSG
4fe774a8 1MVDYgVaSN6iKKEsbzRUAYFrYJFqihogSs
512432d4 1MVDYgVaSN6iKKEsbzRUAYFrYJCvboqqCw
513f653b 1MVDYgVaSN6iKKEsbzRUAYFrYKYMgnWczn
173de50a 1MVDYgVaSN6iKKEsbzRUAYFrYJPR8mCT7o
53f04271 1MVDYgVaSN6iKKEsbzRUAYFrYQMJdXj8wA
12b6b83c 1MVDYgVaSN6iKKEsbzRUAYFrYG4QRAVEvw
57a8bef5 1MVDYgVaSN6iKKEsbzRUAYFrYJh7qbpyEk
580394a8 1MVDYgVaSN6iKKEsbzRUAYFrYKcAUsnqvX
58281434 1MVDYgVaSN6iKKEsbzRUAYFrY8FKPK36DR
5aa05368 1MVDYgVaSN6iKKEsbzRUAYFrYJTQSxnH6o
0b055c7e 1MVDYgVaSN6iKKEsbzRUAYFrYLc9YVhFH7
0aab0513 1MVDYgVaSN6iKKEsbzRUAYFrYP5c8VApUJ
60ac4189 1MVDYgVaSN6iKKEsbzRUAYFrYJzp4rC93E
06a7fc93 1MVDYgVaSN6iKKEsbzRUAYFrY3iKt6JodU
6224d89c 1MVDYgVaSN6iKKEsbzRUAYFrYRwnxhWqhd
63e7e50e 1MVDYgVaSN6iKKEsbzRUAYFrY3jiUe5mkH
049867e0 1MVDYgVaSN6iKKEsbzRUAYFrY9CfTaRAj9
03cb65a8 1MVDYgVaSN6iKKEsbzRUAYFrYNcB7o2U5m
65ba760b 1MVDYgVaSN6iKKEsbzRUAYFrYGHGmWnE5x
02079091 1MVDYgVaSN6iKKEsbzRUAYFrYKYFDmmXvx
66956ad0 1MVDYgVaSN6iKKEsbzRUAYFrYRGhUaxLAK
6bd50fd7 1MVDYgVaSN6iKKEsbzRUAYFrY1zaKtm65k
6e1b9f29 1MVDYgVaSN6iKKEsbzRUAYFrYKFy4kSGxY
70301cd9 1MVDYgVaSN6iKKEsbzRUAYFrYK1QNWnaRE
704313d3 1MVDYgVaSN6iKKEsbzRUAYFrYEBQPj6kuQ
712235c1 1MVDYgVaSN6iKKEsbzRUAYFrYGwYecWvtg
7143e1af 1MVDYgVaSN6iKKEsbzRUAYFrYMVMGzoTq8
7685fd45 1MVDYgVaSN6iKKEsbzRUAYFrY5oAWsjJkL
79c50162 1MVDYgVaSN6iKKEsbzRUAYFrY7xHJuXr2u
7ea1e504 1MVDYgVaSN6iKKEsbzRUAYFrYPiHf1aW3M
83e17057 1MVDYgVaSN6iKKEsbzRUAYFrYK37SLggeJ
869199e1 1MVDYgVaSN6iKKEsbzRUAYFrYTRNZQAp6C
892a6f72 1MVDYgVaSN6iKKEsbzRUAYFrYHfqxqkkdf
8ddbbd3e 1MVDYgVaSN6iKKEsbzRUAYFrYJVxqAj7aD
92165705 1MVDYgVaSN6iKKEsbzRUAYFrY4gr5soyaU
93cc9937 1MVDYgVaSN6iKKEsbzRUAYFrYHRAAaJFMY
95dd4861 1MVDYgVaSN6iKKEsbzRUAYFrYK1DSk5mdS
99ec9178 1MVDYgVaSN6iKKEsbzRUAYFrYHf1LxW1f5
9d6c4d98 1MVDYgVaSN6iKKEsbzRUAYFrYRAqEM6RM9
9e34b88f 1MVDYgVaSN6iKKEsbzRUAYFrY6Lm6MZxTG
9f47c7a0 1MVDYgVaSN6iKKEsbzRUAYFrY7amrkmVTV
a7938159 1MVDYgVaSN6iKKEsbzRUAYFrYB4AGnhXNp
af25933e 1MVDYgVaSN6iKKEsbzRUAYFrYRKef9u3L9
b37e22f5 1MVDYgVaSN6iKKEsbzRUAYFrYHn4SspLz8
bba161aa 1MVDYgVaSN6iKKEsbzRUAYFrYJEv4gVhoo
bcb7862f 1MVDYgVaSN6iKKEsbzRUAYFrYKMmRNY3Wn
be6b0f9d 1MVDYgVaSN6iKKEsbzRUAYFrYD3FFjLWtc
be8dec70 1MVDYgVaSN6iKKEsbzRUAYFrYJNfS71CuV
c76cc27b 1MVDYgVaSN6iKKEsbzRUAYFrYHSUuaHqwp
c8e50a18 1MVDYgVaSN6iKKEsbzRUAYFrY8456pjr1M
cffc46cf 1MVDYgVaSN6iKKEsbzRUAYFrYUxnzkUyCi
d45348be 1MVDYgVaSN6iKKEsbzRUAYFrYRB41BZ8Zb
d49aa56b 1MVDYgVaSN6iKKEsbzRUAYFrYJwJMz5iy8
d49d17de 1MVDYgVaSN6iKKEsbzRUAYFrY7dqEjSKjj
d8b30109 1MVDYgVaSN6iKKEsbzRUAYFrYPvcRKVUeU
db8f4353 1MVDYgVaSN6iKKEsbzRUAYFrYNJpxWzQpS
df70c50b 1MVDYgVaSN6iKKEsbzRUAYFrYwVsXLrLnN
dfe58efe 1MVDYgVaSN6iKKEsbzRUAYFrYJ2Lv1qZxh
e03840c3 1MVDYgVaSN6iKKEsbzRUAYFrYRr9ViLB4e
e2019fc9 1MVDYgVaSN6iKKEsbzRUAYFrYHsTtKRovG
e411ac0b 1MVDYgVaSN6iKKEsbzRUAYFrYM1agpZS5G
f6495f3b 1MVDYgVaSN6iKKEsbzRUAYFrYQmNkmr4FU
f9687c77 1MVDYgVaSN6iKKEsbzRUAYFrYE9BGkoDv6
fb0803f5 1MVDYgVaSN6iKKEsbzRUAYFrYHwNSbtNzY
fd858113 1MVDYgVaSN6iKKEsbzRUAYFrYJUP3Vb6ze

Dude, you can speed up this Python code 100 times in Cyclone.

P.S. --> I saw the code before you deleted it.

[Desyationer]

Dude, you can speed up this Python code 100 times in Cyclone.

This is a pointless activity in terms of practical use, but it's still very exciting to try this code or the program called "Cyclone."

I Use Python for 5800x time is about 30min for 100 Prefix "1MVDYgVaSN6iKKEsbzRUAYFrYJ"

Code:

import random
import base58
import hashlib
import concurrent.futures


def base58_check_encode(version, payload):
    """ Кoдиpoвaниe base58 c кoнтpoльнoй cyммoй """
    data = version + payload
    checksum = hashlib.sha256(hashlib.sha256(data).digest()).digest()[:4]
    return base58.b58encode(data + checksum).decode()


def base58_check_decode(address):
    """ Дeкoдиpoвaниe base58 и пpoвepкa кoнтpoльнoй cyммы """
    data = base58.b58decode(address)
    payload, checksum = data[:-4], data[-4:]
    if hashlib.sha256(hashlib.sha256(payload).digest()).digest()[:4] != checksum:
        raise ValueError("Invalid checksum")
    return payload


def modify_address(original_address, prefix, changes=4):
    """ Гeнepиpyeт нoвый aдpec, измeняя 4 cлyчaйныx бaйтa, пpoвepяeт пpeфикc """
    while True:
        decoded = base58_check_decode(original_address)
        version, payload = decoded[:1], bytearray(decoded[1:])

        modified_indices = random.sample(range(len(payload)), changes)
        for idx in modified_indices:
            payload[idx] = random.randint(0, 255)

        new_address = base58_check_encode(version, payload)
        if new_address.startswith(prefix):
            return new_address


def find_addresses(original_address, prefix, num_addresses, num_threads=8):
    """ Зaпycкaeт мнoгoпoтoчный пoиcк aдpecoв """
    found_addresses = []
    with concurrent.futures.ThreadPoolExecutor(max_workers=num_threads) as executor:
        futures = {executor.submit(modify_address, original_address, prefix): i for i in range(num_addresses)}
        for future in concurrent.futures.as_completed(futures):
            found_addresses.append(future.result())
            print(f"Haйдeн aдpec: {future.result()}")
    
    return found_addresses


# === ПAPAMETPЫ ===
original_address = "1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ"
prefix = "1MVDYgVaSN6iKKEsbzRUAYFrYJ"  # Фильтp пo пepвым cимвoлaм
num_addresses = 1  # Кoличecтвo нyжныx aдpecoв
num_threads = 8  # Кoличecтвo пoтoкoв

# === ЗAПУCК ПOИCКA B 8 ПOTOКAX ===
found_addresses = find_addresses(original_address, prefix, num_addresses, num_threads)

# === COXPAHEHИE B ФAЙЛ ===
with open("ModAdr.txt", "w") as file:
    file.write("\n".join(found_addresses))

print(f"\nГoтoвo! Haйдeнo {len(found_addresses)} aдpecoв, зaпиcaнo в ModAdr.txt")

[nomachine]

Dude, you can speed up this Python code 100 times in Cyclone.

This is a pointless activity in terms of practical use, but it's still very exciting to try this code or the program called "Cyclone."

https://bitcointalk.org/index.php?topic=5532654.msg65157153#msg65157153

We can easily make 'Cyclone' run on a GPU since it is based on JLP (JeanLucPons) code.

However, everything is pointless without enormous amount of hardware known as GPUs..

[Akito S. M. Hosana]

everything is pointless without enormous amount of hardware known as GPUs..

You mean you need a couple of million dollars for GPUs?

Everything becomes clear when it turns into cash

import random
import base58
import hashlib
import concurrent.futures

Your code is generating random Base58Check-encoded strings, but these are not valid Bitcoin addresses because they are not derived from valid private and public keys.

To generate valid Bitcoin addresses, you must:

Start with a valid private key.

Use the private key to derive the public key using ecdsa.SigningKey.

import ecdsa is missing

private_key = ecdsa.SigningKey.generate(curve=ecdsa.SECP256k1)
private_key_bytes = private_key.to_string()

In your code, the payload is being modified randomly, but it doesn't correspond to a valid private key. I've been learning Python for a while  

[nomachine]

private_key = ecdsa.SigningKey.generate(curve=ecdsa.SECP256k1)
private_key_bytes = private_key.to_string()

It would be nice if this could be skipped.

Without scalar multiplication, none of this will work for deriving public keys from private keys.

[Akito S. M. Hosana]

you can speed up this Python code 100 times in Cyclone.

How do you think prefixes can be generated in Cyclone?

[WanderingPhilospher]

I've done a decent amount of work in "vanity" searches, which are basically prefix searches. However, that is normally over the entire curve, not a super small subset such as 66 or 67 bits.
And yes, my script was pretty good at it. For those who didn't know, I helped LoyceV find some crazy, some difficult, prefixes, for his project: https://bitcointalk.org/index.php?topic=5532768.0

But again, that was over the entire range and it wasn't for a prize, or the fastest to a prize. And when dealing with the whole curve, you can use some tricks. When I was helping Loyce, I kept modifying my code and eventually, it became good at looking for the types of prefixes he was looking for.
But these challenges / puzzles, and their smaller range sizes, are more problematic lol. Especially since we are looking for a complete address and we can't use more tricks (symm, endos).

Yes, everyone can talk about averages and probabilities, but at the end of the day, I do not know how or what base you would use, to say if I found x amount of h160 matching characters, I can jump x amount, because the probabilities say it will not be closer than y.

And anyone who says they can truly narrow it down, without the possibility of skipping the address we are looking for...I would not trust them lol. I don't care who they are. If I told you that, do not trust me either lol. I don't even know how you can say, well there is a x amount of chance we skip the key, but it is very low.

Old sayings I like, "Math never lies, people do" and "Facts don't care about your feelings". Which thanks to Bram, everyone can study the same data. So I did the math...it will tell you the truth.

Look at these numbers:

Code:

First Run:
- Average difference: 282602011632656
- Smallest difference: 194903573833
- Largest difference: 1946984192923367

Second Run (Excluding Smallest and Largest Differences):
- Average difference: 281241799946404

For reference, 2^48 = 281474976710656

Those numbers are from a data set of (12 matching, leading characters of the h160) prefixes found, over a range size of 2^58. Anything stick out to you?

Without removing the smallest and largest differences, the average distance is greater than 2^48, when removed, just below it. But, did you see the largest and smallest differences?

- Smallest difference: 194903573833
- Largest difference: 1946984192923367

the smallest gap between 2 prefixes was less than 38 bits and the largest gap was over 51 bits.
So, someone tell me how you can say you can widdle searches down or jump x amount, and not miss the actual key that we are looking for... (for vanity address, this is fine, but we are looking for 100% address, not just x leading prefixes)
For those that claim they have a really good formula, please explain it here. I am genuinely curious.

[kTimesG]

Yes, you can replace any key by other key.

A logical speedup is to ignore the rest of the elements in the range/set, and choose a new range/set, to maximize chances to find another new element.

Then the new set has exactly the same odds to find a match as the set you were about to run when finishing the range.
It feels counter intuitive, I know. If you want to be convinced just run the odds of both cases by taking a range of size 1000 with 5% probability.

Then how do you explain this: if I have some 32 bits mask, and jump keys based on how many bits the mask matched, then I hash less keys overall, but the total matches are, on average, much better finds than if I traverse linearly?.

Or are you saying that this does not happen?

Oh this can clearly happen on a small enough subset because of the huge deviations that may happen.It would not work as well on a bigger scale because everything would even out.

Yeah, seems I hurried a bit. I only averaged the best matches; if all the possible prefix lengths are included, then on average there is only a 1.0000... bits prefix match, long-term.

This is identical to simply not even doing a prefix match at all. Because, on average, a H160 hash has a length of 159 bits. Zero improvement trying to break the hash distribution.

It also doesn't matter whether the hash inputs are random data or produced by EC scalar-mul.

It is just placebo to think that, by "skipping" a number of hashes (no matter in what way you do that) you maximize chances to obtain, in a faster way, some prefix. The same exact thing would happen if the keys are hashed in continuation, or the hashing is done on random inputs. Or if you simply wait it out, drink a coffee, and hash a bit more from where you left off. Or simply ignore the results of a couple of hashes and then go as usual.

Set/range A: keys 1 to N
Set/range B: keys N + 1 to 2N (or some other M to M + size)

After A is scanned (fully or not), we can simply swap keys from B into A (or not), there is no correlation between the way we split the sets, and what the hashing produces. Unless there is a link between the private key and the H160, this is where conspiracy theories begin.

[aby3er]

Hey everyone /
if someone needs for 69:
19vkiEajfh i9pMP9v4vtttK8BtkwqLjafX
(WIF): p2pkh: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qhGYQWpyawGq7TeLoEkQ
(HEX): 17353DBA52F00471D3

 

[kTimesG]

Hey everyone /
if someone needs for 69:
19vkiEajfh i9pMP9v4vtttK8BtkwqLjafX
(WIF): p2pkh: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qhGYQWpyawGq7TeLoEkQ
(HEX): 17353DBA52F00471D3

 

Thank you for your contribution.

This is what seems really strange: the moment when some serious users post thoughtful things, immediately there appears some fresh created account user, posting exactly something against what was being discusses. Meanwhile, the people that are bothered by the thoughtful discussions, are really happy to quickly interact and engage with all of these new-born users, who are seemingly total experts now, having lots of prefixes and so on, or wanting such prefixes.

And sure way, at the same time, everyone else is an AI / robot / clone / troll / child / clueless. But no one sees the 0-day noobs with zero activity signing the Large Prefix Catalog. Of course it makes complete sense.

[nomachine]

you can speed up this Python code 100 times in Cyclone.

How do you think prefixes can be generated in Cyclone?

There is already a search in the script using AVX2 instructions to compare two 128-bit values.
However, the search focus on the last 4 bytes of the hashes rather than just the beginning.

Code:

// 8 keys are ready - time to use avx2
                if (localBatchCount == HASH_BATCH_SIZE) {
                    computeHash160BatchBinSingle(localBatchCount, localPubKeys, localHashResults);
                    // Results check
                    for (int j = 0; j < HASH_BATCH_SIZE; j++) {
                        __m128i cand16 = _mm_loadu_si128(reinterpret_cast<const __m128i*>(localHashResults[j]));
                        __m128i cmp = _mm_cmpeq_epi8(cand16, target16);
                        if (_mm_movemask_epi8(cmp) == 0xFFFF) {
                            // Checking last 4 bytes (20 - 16)

A Bitcoin address is derived from a RIPEMD-160 hash (20 bytes).
To match 1MVDYgVaSN, you need to match the first 10 bytes.

Code:

// Modify the comparison logic to check only the first 10 bytes
if ((_mm_movemask_epi8(cmp) & 0x03FF) == 0x03FF) {
    // Check the first 10 bytes of the hash160 result
    if (!matchFound && std::memcmp(localHashResults[j], targetHash160.data(), 10) == 0) {
        #pragma omp critical
        {
            if (!matchFound) {
                matchFound = true;
                auto tEndTime = std::chrono::high_resolution_clock::now();
                globalElapsedTime = std::chrono::duration<double>(tEndTime - tStart).count();
                mkeysPerSec = (double)(globalComparedCount + localComparedCount) / globalElapsedTime / 1e6;

                // Recovering private key
                Int matchingPrivateKey;
                matchingPrivateKey.Set(&currentBatchKey);
                int idx = pointIndices[j];
                if (idx < 256) {
                    Int offset; offset.SetInt32(idx);
                    matchingPrivateKey.Add(&offset);
                } else {
                    Int offset; offset.SetInt32(idx - 256);
                    matchingPrivateKey.Sub(&offset);
                }
                foundPrivateKeyHex = padHexTo64(intToHex(matchingPrivateKey));

                // Print the partial match and private key
                std::string first10(reinterpret_cast<char*>(localHashResults[j]), 10);
                std::cout << "Partial Match Found! First 10 bytes: " << first10 << "\n";
                std::cout << "Private Key: " << foundPrivateKeyHex << "\n";
            }
        }
        #pragma omp cancel parallel
    }
    localComparedCount++;
} else {
    localComparedCount++;
}

Something like this, but I don't believe in prefixes anymore either. I did that in the beginning, and I don't even know what I haven't tried. The pattern doesn't exist. This is just useless fun....

[teguh54321]

Hey everyone /
if someone needs for 69:
19vkiEajfh i9pMP9v4vtttK8BtkwqLjafX
(WIF): p2pkh: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qhGYQWpyawGq7TeLoEkQ
(HEX): 17353DBA52F00471D3

 

It looks so close 🙃😅.........

Any hints for Puzzle 68's first 3-digit range? Hehe.

[bibilgin]

I've done a decent amount of work in "vanity" searches, which are basically prefix searches. However, that is normally over the entire curve, not a super small subset such as 66 or 67 bits.
And yes, my script was pretty good at it. For those who didn't know, I helped LoyceV find some crazy, some difficult, prefixes, for his project: https://bitcointalk.org/index.php?topic=5532768.0

But again, that was over the entire range and it wasn't for a prize, or the fastest to a prize. And when dealing with the whole curve, you can use some tricks. When I was helping Loyce, I kept modifying my code and eventually, it became good at looking for the types of prefixes he was looking for.
But these challenges / puzzles, and their smaller range sizes, are more problematic lol. Especially since we are looking for a complete address and we can't use more tricks (symm, endos).

Yes, everyone can talk about averages and probabilities, but at the end of the day, I do not know how or what base you would use, to say if I found x amount of h160 matching characters, I can jump x amount, because the probabilities say it will not be closer than y.

And anyone who says they can truly narrow it down, without the possibility of skipping the address we are looking for...I would not trust them lol. I don't care who they are. If I told you that, do not trust me either lol. I don't even know how you can say, well there is a x amount of chance we skip the key, but it is very low.

Old sayings I like, "Math never lies, people do" and "Facts don't care about your feelings". Which thanks to Bram, everyone can study the same data. So I did the math...it will tell you the truth.

Look at these numbers:

Code:

First Run:
- Average difference: 282602011632656
- Smallest difference: 194903573833
- Largest difference: 1946984192923367

Second Run (Excluding Smallest and Largest Differences):
- Average difference: 281241799946404

For reference, 2^48 = 281474976710656

Those numbers are from a data set of (12 matching, leading characters of the h160) prefixes found, over a range size of 2^58. Anything stick out to you?

Without removing the smallest and largest differences, the average distance is greater than 2^48, when removed, just below it. But, did you see the largest and smallest differences?

- Smallest difference: 194903573833
- Largest difference: 1946984192923367

the smallest gap between 2 prefixes was less than 38 bits and the largest gap was over 51 bits.
So, someone tell me how you can say you can widdle searches down or jump x amount, and not miss the actual key that we are looking for... (for vanity address, this is fine, but we are looking for 100% address, not just x leading prefixes)
For those that claim they have a really good formula, please explain it here. I am genuinely curious.

Thanks for the nice article and information.

Actually, as everyone knows, there is no fixed jump or pattern. But there is a jump PROBABILITY range of prefixes and hash160s.

But serious differences occur with very short prefixes. As the prefix or hash160 gets shorter, the hash decreases to fewer differences.

For example;

1MVDYgVaSN6Qy3d7W5nqGAUziqwJpKyhGu
I don't know the hex code of the wallet you shared. I think it starts with D. Because when I calculate the hash160 and the PROBABILITY with what I found, it shows that it starts with D.

But if I try to guess the 2nd hex code with low probability.
I think it is between D6 and DC. True? or False?

I have a request from you.
1MVDYgVaSN6Qy3d7W5nqGAUziqwJpKyhGu
can you make a change for this?

[teguh54321]

I've done a decent amount of work in "vanity" searches, which are basically prefix searches. However, that is normally over the entire curve, not a super small subset such as 66 or 67 bits.
And yes, my script was pretty good at it. For those who didn't know, I helped LoyceV find some crazy, some difficult, prefixes, for his project: https://bitcointalk.org/index.php?topic=5532768.0

But again, that was over the entire range and it wasn't for a prize, or the fastest to a prize. And when dealing with the whole curve, you can use some tricks. When I was helping Loyce, I kept modifying my code and eventually, it became good at looking for the types of prefixes he was looking for.
But these challenges / puzzles, and their smaller range sizes, are more problematic lol. Especially since we are looking for a complete address and we can't use more tricks (symm, endos).

Yes, everyone can talk about averages and probabilities, but at the end of the day, I do not know how or what base you would use, to say if I found x amount of h160 matching characters, I can jump x amount, because the probabilities say it will not be closer than y.

And anyone who says they can truly narrow it down, without the possibility of skipping the address we are looking for...I would not trust them lol. I don't care who they are. If I told you that, do not trust me either lol. I don't even know how you can say, well there is a x amount of chance we skip the key, but it is very low.

Old sayings I like, "Math never lies, people do" and "Facts don't care about your feelings". Which thanks to Bram, everyone can study the same data. So I did the math...it will tell you the truth.

Look at these numbers:

Code:

First Run:
- Average difference: 282602011632656
- Smallest difference: 194903573833
- Largest difference: 1946984192923367

Second Run (Excluding Smallest and Largest Differences):
- Average difference: 281241799946404

For reference, 2^48 = 281474976710656

Those numbers are from a data set of (12 matching, leading characters of the h160) prefixes found, over a range size of 2^58. Anything stick out to you?

Without removing the smallest and largest differences, the average distance is greater than 2^48, when removed, just below it. But, did you see the largest and smallest differences?

- Smallest difference: 194903573833
- Largest difference: 1946984192923367

the smallest gap between 2 prefixes was less than 38 bits and the largest gap was over 51 bits.
So, someone tell me how you can say you can widdle searches down or jump x amount, and not miss the actual key that we are looking for... (for vanity address, this is fine, but we are looking for 100% address, not just x leading prefixes)
For those that claim they have a really good formula, please explain it here. I am genuinely curious.

Does this mean we can safely jump to the smallest possible difference? 🤔

[bibilgin]

Thank you for your contribution.

This is what seems really strange: the moment when some serious users post thoughtful things, immediately there appears some fresh created account user, posting exactly something against what was being discusses. Meanwhile, the people that are bothered by the thoughtful discussions, are really happy to quickly interact and engage with all of these new-born users, who are seemingly total experts now, having lots of prefixes and so on, or wanting such prefixes.

And sure way, at the same time, everyone else is an AI / robot / clone / troll / child / clueless. But no one sees the 0-day noobs with zero activity signing the Large Prefix Catalog. Of course it makes complete sense.

I don't plan on getting into a new argument with you.

But leaving people under suspicion is a serious psychological problem.
If you think that I created or know about these accounts. I promise you. If you show the slightest proof, I will not enter the forum again.

[citb0in]

Stay focused on your path and don’t let distractions or negativity shake your determination. Success is built through consistency, patience, and resilience - every step forward matters. As the saying goes: "Do not be deceived: God cannot be mocked. A man reaps what he sows."

Stay committed, and let your vision be stronger than any obstacle.