Bitcoin puzzle transaction ~32 BTC prize to who solves it

[citb0in]

Agreed it is an avalanche effect, up to a point. From the private key perspective, but not the public key perspective.

The avalanche effect refers to the property where a small change in the input data results in a significantly different output (hash value). In other words, even a slight modification to the input should cause a drastic and unpredictable change in the hash output. This is a crucial property for cryptographic for all kind of hash functions. These properties do not distinct between a pubkey or address generation, hash functions were made to fulfill this.

[WanderingPhilospher]

Agreed it is an avalanche effect, up to a point. From the private key perspective, but not the public key perspective.

The avalanche effect refers to the property where a small change in the input data results in a significantly different output (hash value). In other words, even a slight modification to the input should cause a drastic and unpredictable change in the hash output. This is a crucial property for cryptographic for all kind of hash functions. These properties do not distinct between a pubkey or address generation, hash functions were made to fulfill this.

Lol, thanks for the education on hashing and cryptographic properties. I appreciate you.

If you take a hash160 and change the last character, how does that affect the final public address? Remember, it goes through 2 more SHA256 rounds. Is the final public address changed drastically?

What if we replace the last 5-10 characters? Drastic change?

[3dmlib]

I think even if i had two of first HEX numbers i wouldn't be able to solve it anyway.

The remaining search space is 2^(66-2) = 2^64.

It would take approximately 584 years to complete the task in Python.

So your saying theres a chance?

wheew you had me going there!

64 puzzle was solved 2022-09-10 then we had 3090 maximum.
Now we have 4090 which is 2x faster.
Next year we'll have 5090 which probably even 2x faster then 4090.

66 puzzle exactly have 4x more difficulty then 64 puzzle.
So next year solving 66 with 5090 will be the same probability as solving 64 with 3090 in 2022.

[AlanJohnson]

66 puzzle exactly have 4x more difficulty then 64 puzzle.

Are you sure ?

[nomachine]

share with us sir

I can share puzzle search app in Rust. I'm sick of code in Python.

main.rs

Code:

extern crate bitcoin;
extern crate rand;
extern crate reqwest;
extern crate secp256k1;
extern crate num_cpus;
extern crate thousands;
extern crate threadpool;
extern crate chrono;

use bitcoin::network::Network;
use bitcoin::address::Address;
use bitcoin::key::PrivateKey;
use rand::Rng;
use std::env;
use std::fs::File;
use std::io::Write;
use std::sync::{Arc, Mutex};
use threadpool::ThreadPool;
use chrono::Local;

const TARGET: &str = "1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW";

fn main() {
    // Print the current time when the script starts
    let current_time = Local::now();
    println!("[+] Puzzle search\n[+] Script started at: {}", current_time);

    let args: Vec<String> = env::args().collect();
    let num_threads = if args.len() < 2 {
        num_cpus::get() as u32
    } else {
        args[1].parse().expect("Failed to parse number of threads")
    };

    let begin: u128 = 16383;
    let end: u128 = 32767;

    println!(
        "[+] concurrency:{}\n[+] from:{} to:{}\n[+] target:{}",
        num_threads,
        begin,
        end,
        TARGET
    );

    let found_flag = Arc::new(Mutex::new(false));
    let pool = ThreadPool::new(num_threads.try_into().unwrap());

    for _ in 0..num_threads {
        let pool = pool.clone();
        let found_flag = found_flag.clone();
        pool.execute(move || {
            let mut rng = rand::thread_rng();
            random_lookfor(rng.gen_range(begin..end), end, found_flag);
        });
    }

    pool.join();
}

fn random_lookfor(begin: u128, end: u128, found_flag: Arc<Mutex<bool>>) {
    let secp = bitcoin::secp256k1::Secp256k1::new();

    loop {
        let value: u128 = rand::thread_rng().gen_range(begin..end);
        let private_key_hex = format!("{:0>64x}", value);
        let private_key_bytes = hex::decode(&private_key_hex).expect("Failed to decode private key hex");

        let private_key: PrivateKey = PrivateKey {
            compressed: true,
            network: Network::Bitcoin,
            inner: bitcoin::secp256k1::SecretKey::from_slice(&private_key_bytes).unwrap(),
        };

        let public_key = private_key.public_key(&secp);
        let address = Address::p2pkh(&public_key, Network::Bitcoin).to_string();
        print!(
            "\r[+] WIF: {}",
            private_key
        );

        // Check if a match has been found by another thread
        let mut found_flag = found_flag.lock().unwrap();
        if *found_flag {
            break;
        }

        if address == TARGET {
            let current_time = Local::now();
            let line_of_dashes = "-".repeat(80);
            println!(
                "\n[+] {}\n[+] KEY FOUND! {}\n[+] decimal: {} \n[+] private key: {} \n[+] public key: {} \n[+] address: {}\n[+] {}",
                line_of_dashes,
                current_time,
                value,
                private_key,
                public_key,
                address,
                line_of_dashes          
            );

            // Set the flag to true to signal other threads to exit
            *found_flag = true;

            if let Ok(mut file) = File::create("KEYFOUNDKEYFOUND.txt") {
                let line_of_dashes = "-".repeat(130);
                writeln!(
                    &mut file,
                "\n{}\nKEY FOUND! {}\ndecimal: {} \nprivate key: {} \npublic key: {} \naddress: {}\n{}",
                line_of_dashes,
                current_time,
                value,
                private_key,
                public_key,
                address,
                line_of_dashes      
                )
                .expect("Failed to write to file");
            } else {
                eprintln!("Error: Failed to create or write to KEYFOUNDKEYFOUND.txt");
            }
            break;
        }
    }
}

Cargo.toml

Code:

[package]
name = "puzzle"
version = "0.1.0"
edition = "2021"

[dependencies]
threadpool = "1.8.0"
bitcoin_hashes = "0.13.0"                 
bitcoin = "0.31.1"
hex = "0.4.3"
rand = "0.8.5"
reqwest = "0.11.23"
secp256k1 = "0.28.1"
num_cpus = "1.16.0"
thousands = "0.2.0"
chrono = "0.4"

• --------------------------------------------------------------------------------
• KEY FOUND!
• decimal: 26867
• private key: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFY5iMZbuRxj
• public key: 02fea58ffcf49566f6e9e9350cf5bca2861312f422966e8db16094beb14dc3df2c
• address: 1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW
• --------------------------------------------------------------------------------

Install Rust:

Code:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Configure Rust Environment:

Code:

source $HOME/.cargo/env

Code:

export PATH="$HOME/.cargo/bin:$PATH"

Create a Puzzle Rust Project:

Code:

cargo new puzzle

copy/paste above main.rs & Cargo.toml

Code:

cd  puzzle

Build program

Code:

cargo build --release

Start

Code:

cargo run

or directly as a bin application

Code:

./target/release/puzzle

p.s.
You can remove :      

Code:

        print!(
            "\r[+] WIF: {}",
            private_key
        );

for more speed....

I have similar levels of performance in Rust and C. But much less bugs in Rust  

[3dmlib]

66 puzzle exactly have 4x more difficulty then 64 puzzle.

Are you sure ?

Yes.

[zahid888]

Agreed it is an avalanche effect, up to a point. From the private key perspective, but not the public key perspective.

Meaning, normally, if you have the same number of leading public key characters, they often will hash to the same leading characters in an address.

I was recently reading this, somewhere.

However, the private key is the wildcard. Trying to match the first x amount of characters and it hash to same public key or address is not the norm.

People like to tinker. Nothing wrong with that. Their idea may spawn something that helps solve quicker. Maybe, maybe not, but it doesn’t hurt anyone from a person tinkering out their ideas.

Thank you, I felt very good hearing this, look at the jump which I want, in sequence still challenging but far better then blindly random..

[Feron]

It's not that easy in the 66 bit range there is only one address, those numbers must be 100% exactly one bit different and you will get a completely different address

[rosengold]

share with us sir

I can share puzzle search app in Rust. I'm sick of code in Python.

main.rs

Code:

extern crate bitcoin;
extern crate rand;
extern crate reqwest;
extern crate secp256k1;
extern crate num_cpus;
extern crate thousands;
extern crate threadpool;
extern crate chrono;

use bitcoin::network::Network;
use bitcoin::address::Address;
use bitcoin::key::PrivateKey;
use rand::Rng;
use std::env;
use std::fs::File;
use std::io::Write;
use std::sync::{Arc, Mutex};
use threadpool::ThreadPool;
use chrono::Local;

const TARGET: &str = "1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW";

fn main() {
    // Print the current time when the script starts
    let current_time = Local::now();
    println!("[+] Puzzle search\n[+] Script started at: {}", current_time);

    let args: Vec<String> = env::args().collect();
    let num_threads = if args.len() < 2 {
        num_cpus::get() as u32
    } else {
        args[1].parse().expect("Failed to parse number of threads")
    };

    let begin: u128 = 16383;
    let end: u128 = 32767;

    println!(
        "[+] concurrency:{}\n[+] from:{} to:{}\n[+] target:{}",
        num_threads,
        begin,
        end,
        TARGET
    );

    let found_flag = Arc::new(Mutex::new(false));
    let pool = ThreadPool::new(num_threads.try_into().unwrap());

    for _ in 0..num_threads {
        let pool = pool.clone();
        let found_flag = found_flag.clone();
        pool.execute(move || {
            let mut rng = rand::thread_rng();
            random_lookfor(rng.gen_range(begin..end), end, found_flag);
        });
    }

    pool.join();
}

fn random_lookfor(begin: u128, end: u128, found_flag: Arc<Mutex<bool>>) {
    let secp = bitcoin::secp256k1::Secp256k1::new();

    loop {
        let value: u128 = rand::thread_rng().gen_range(begin..end);
        let private_key_hex = format!("{:0>64x}", value);
        let private_key_bytes = hex::decode(&private_key_hex).expect("Failed to decode private key hex");

        let private_key: PrivateKey = PrivateKey {
            compressed: true,
            network: Network::Bitcoin,
            inner: bitcoin::secp256k1::SecretKey::from_slice(&private_key_bytes).unwrap(),
        };

        let public_key = private_key.public_key(&secp);
        let address = Address::p2pkh(&public_key, Network::Bitcoin).to_string();
        print!(
            "\r[+] WIF: {}",
            private_key
        );

        // Check if a match has been found by another thread
        let mut found_flag = found_flag.lock().unwrap();
        if *found_flag {
            break;
        }

        if address == TARGET {
            let current_time = Local::now();
            let line_of_dashes = "-".repeat(80);
            println!(
                "\n[+] {}\n[+] KEY FOUND! {}\n[+] decimal: {} \n[+] private key: {} \n[+] public key: {} \n[+] address: {}\n[+] {}",
                line_of_dashes,
                current_time,
                value,
                private_key,
                public_key,
                address,
                line_of_dashes           
            );

            // Set the flag to true to signal other threads to exit
            *found_flag = true;

            if let Ok(mut file) = File::create("KEYFOUNDKEYFOUND.txt") {
                let line_of_dashes = "-".repeat(130);
                writeln!(
                    &mut file,
                "\n{}\nKEY FOUND! {}\ndecimal: {} \nprivate key: {} \npublic key: {} \naddress: {}\n{}",
                line_of_dashes,
                current_time,
                value,
                private_key,
                public_key,
                address,
                line_of_dashes       
                )
                .expect("Failed to write to file");
            } else {
                eprintln!("Error: Failed to create or write to KEYFOUNDKEYFOUND.txt");
            }
            break;
        }
    }
}

Cargo.toml

Code:

[package]
name = "puzzle"
version = "0.1.0"
edition = "2021"

[dependencies]
threadpool = "1.8.0"
bitcoin_hashes = "0.13.0"                 
bitcoin = "0.31.1"
hex = "0.4.3"
rand = "0.8.5"
reqwest = "0.11.23"
secp256k1 = "0.28.1"
num_cpus = "1.16.0"
thousands = "0.2.0"
chrono = "0.4"

• --------------------------------------------------------------------------------
• KEY FOUND!
• decimal: 26867
• private key: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFY5iMZbuRxj
• public key: 02fea58ffcf49566f6e9e9350cf5bca2861312f422966e8db16094beb14dc3df2c
• address: 1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW
• --------------------------------------------------------------------------------

Install Rust:

Code:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Configure Rust Environment:

Code:

source $HOME/.cargo/env

Code:

export PATH="$HOME/.cargo/bin:$PATH"

Create a Puzzle Rust Project:

Code:

cargo new puzzle

copy/paste above main.rs & Cargo.toml

Code:

cd  puzzle

Build program

Code:

cargo build --release

Start

Code:

cargo run

or directly as a bin application

Code:

./target/release/puzzle

p.s.
You can remove :      

Code:

        print!(
            "\r[+] WIF: {}",
            private_key
        );

for more speed....

I have similar levels of performance in Rust and C. But much less bugs in Rust  

amazing, thanks.

I will study your code and implement some own logic of mine.

[nomachine]

amazing, thanks.

I will study your code and implement some own logic of mine.

It has incredible possibilities for compiling. I was able to run this on an ARM processor as well on Amd Zen 2, 3 and 4

 on almost everything.....

https://doc.rust-lang.org/rustc/platform-support.html

example

Code:

RUSTFLAGS="-C target-cpu=znver4" cargo build --release --target=x86_64-unknown-linux-gnu

run

Code:

./target/x86_64-unknown-linux-gnu/release/puzzle

[Tepan]

is worth it to search the address by this method?

[2024-01-27 14:30:18] : Found address 13zCn8PenSN9QLGdeyccJv7kb8m8RnkDGY
[2024-01-27 14:30:18] : Private key HEX 0000000000000000000000000000000000000000000000030011c37937e0887a
[2024-01-27 14:30:18] : Found address 13zoZpGGwVs6ysE9wJbxWvyrWg5CLkVifw
[2024-01-27 14:30:18] : Private key HEX 0000000000000000000000000000000000000000000000030011c37937e0890d
[2024-01-27 14:30:19] Thread: Searched 3000 keys in 9.97 seconds
[2024-01-27 14:30:20] Thread: Searched 2000 keys in 11.07 seconds
[2024-01-27 14:30:20] Thread: Searched 3000 keys in 11.07 seconds
[2024-01-27 14:30:20] : Found address 13zb2pSKyRk7vbagvGvueczkrJ1aKJYpmR
[2024-01-27 14:30:20] : Private key HEX 0000000000000000000000000000000000000000000000030011c37937e08ad8

i only use Thread, any code to use with GPU or something else ? like pool scanning for faster ?

[MrlostinBTC]

Agreed it is an avalanche effect, up to a point. From the private key perspective, but not the public key perspective.

Meaning, normally, if you have the same number of leading public key characters, they often will hash to the same leading characters in an address.

I was recently reading this, somewhere.

However, the private key is the wildcard. Trying to match the first x amount of characters and it hash to same public key or address is not the norm.

People like to tinker. Nothing wrong with that. Their idea may spawn something that helps solve quicker. Maybe, maybe not, but it doesn’t hurt anyone from a person tinkering out their ideas.

bx sha256 1234 - hash 1234
3a103a4e5729ad68c02a678ae39accfbc0ae208096437401b7ceab63cca0622f - Produced EC key from hash
bx ec-to-public 3a103a4e5729ad68c02a678ae39accfbc0ae208096437401b7ceab63cca0622f
03b57de06f5c674af0d789530249bb658b0e317d4d179e1b1b1b0aa2ba668bb5f5 - Public key
bx ec-to-public 3a103a4e5729ad68c02a678ae39accfbc0ae208096437401b7ceab63cca0622a - Only last digit of public key has been changed
02e70d3902ef877ba400f15ec109e1933956da79b14d6d33054f50cad9c30e5d5d - Public key

Changing f to a on the EC key resulted in two very different pub keys.
03b57de06f5c674af0d789530249bb658b0e317d4d179e1b1b1b0aa2ba668bb5f5
02e70d3902ef877ba400f15ec109e1933956da79b14d6d33054f50cad9c30e5d5d

Resulting in the following addresses
bx ec-to-address 03b57de06f5c674af0d789530249bb658b0e317d4d179e1b1b1b0aa2ba668bb5f5
16sxaRqyfABv4LBsH1hEgj6tr1g5u2yNtC
bx ec-to-address 02e70d3902ef877ba400f15ec109e1933956da79b14d6d33054f50cad9c30e5d5d
1CQttaNNbyei9SPeo2WSc6fsc6asWmcvkP

However I have noticed public keys working towards address do somewhat share similar conversion traits. Not sure how it would be useful. Much like all the EC keys we are looking for all start the same. Just too many of possible values.

[WanderingPhilospher]

Agreed it is an avalanche effect, up to a point. From the private key perspective, but not the public key perspective.

Meaning, normally, if you have the same number of leading public key characters, they often will hash to the same leading characters in an address.

I was recently reading this, somewhere.

However, the private key is the wildcard. Trying to match the first x amount of characters and it hash to same public key or address is not the norm.

People like to tinker. Nothing wrong with that. Their idea may spawn something that helps solve quicker. Maybe, maybe not, but it doesn’t hurt anyone from a person tinkering out their ideas.

bx sha256 1234 - hash 1234
3a103a4e5729ad68c02a678ae39accfbc0ae208096437401b7ceab63cca0622f - Produced EC key from hash
bx ec-to-public 3a103a4e5729ad68c02a678ae39accfbc0ae208096437401b7ceab63cca0622f
03b57de06f5c674af0d789530249bb658b0e317d4d179e1b1b1b0aa2ba668bb5f5 - Public key
bx ec-to-public 3a103a4e5729ad68c02a678ae39accfbc0ae208096437401b7ceab63cca0622a - Only last digit of public key has been changed
02e70d3902ef877ba400f15ec109e1933956da79b14d6d33054f50cad9c30e5d5d - Public key

Changing f to a on the EC key resulted in two very different pub keys.
03b57de06f5c674af0d789530249bb658b0e317d4d179e1b1b1b0aa2ba668bb5f5
02e70d3902ef877ba400f15ec109e1933956da79b14d6d33054f50cad9c30e5d5d

Agreed; did you see my follow up explanation/question?
Now do hash160 effect. Compare changing characters in hash160 to final BTC address.

[brainless]

I'm very exciting to see the results of @mcdouglasx, as he said that he developed a new method and will solve #130 before the end of January.

It's 10 days left, so ! let's go!

3 days left


Any one seen PK for #120 #125
Any updates regarding above solved addresses ?

[zahid888]

In the spirit of trying and testing new ideas I have created a gui slider bar with the min:max decimal representations of puzzle #66. You can slide the bar and it will print to the terminal. This idea doesn't really work and I imagine it's because of memory and cpu limitations.

UPDATE:
This code is a working example. It still has many limitations.

problem 1:   every number printed to the terminal is a multiple of 2.

problem 2:   the hexadecimal output is limited to 14 characters, I always have 000 at the end of the string.


slider_code.py

Code:

import tkinter as tk
from bitcoin import *

def update_bitcoin_key(value):
    decimal_value = int(value)
    hex_private_key = hex(int(decimal_value))[2:]
    private_key = '0' * 47 + hex_private_key + "21"
    public_key = privtopub(private_key)
    address = pubtoaddr(public_key)
    print(hex_private_key)
    #print(public_key)
    print(address)

root = tk . Tk ()    #remove spaces

value_slider = tk.Scale(root, from_=0x20000000000000000, to=0x3ffffffffffffffff, orient=tk.HORIZONTAL, length=400, command=update_bitcoin_key)
value_slider.pack(pady=20)

root.mainloop()

The default behavior of Tkinter's Scale widget is to increment in steps based on the range of values it's handling. With such a large range a slider might not be the best UI element.

[mabdlmonem]

Anyone know how to get the private key for 58.5?

[citb0in]

Anyone know how to get the private key for 58.5?

Sure, nothing could be easier

Just generate it from decimal 58.5 or HEX 3a.8  

Jokes aside - if you want to derive a private key from a floating-point decimal for experimental or educational purposes, you could devise your own method. Bitcoin private key from a floating-point decimal isn't standard practice, as Bitcoin private keys are typically generated using cryptographic algorithms that rely on random numbers.

good luck in whatever you're trying to achieve

[mabdlmonem]

Anyone know how to get the private key for 58.5?

Sure, nothing could be easier

Just generate it from decimal 58.5 or HEX 3a.8  

Jokes aside - if you want to derive a private key from a floating-point decimal for experimental or educational purposes, you could devise your own method. Bitcoin private key from a floating-point decimal isn't standard practice, as Bitcoin private keys are typically generated using cryptographic algorithms that rely on random numbers.

good luck in whatever you're trying to achieve

I know already how to get private key that has floating 0.5 , I just curious if anyone got it

[mcdouglasx]

Anyone know how to get the private key for 58.5?

Code:

import bitcoin

target= 585

Div=10

N=115792089237316195423570985008687907852837564279074904382605163141518161494337

a=bitcoin.inv(Div,N)

b= target*a % N

print("target r:",target/Div)
print("pk:",b)

[brainless]

Anyone know how to get the private key for 58.5?

Code:

import bitcoin

target= 585

Div=10

N=115792089237316195423570985008687907852837564279074904382605163141518161494337

a=bitcoin.inv(Div,N)

b= target*a % N

print("target r:",target/Div)
print("pk:",b)

58.5

PK 0.5
57896044618658097711785492504343953926418782139537452191302581570759080747169

pk 58
58

58.5
57896044618658097711785492504343953926418782139537452191302581570759080747169
+
58
=
57896044618658097711785492504343953926418782139537452191302581570759080747227

in hex
0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20db