Bitcoin puzzle transaction ~32 BTC prize to who solves it

[nomachine]

In gambling you can be just lucky ... this shit is something far worse. People don't realize how low is the chance to "win" here. 

I have discovered a multitude of scripts and programs on GitHub, numbering at least 96, all claiming to provide solutions for a specific puzzle. This abundance of solutions may give rise to unrealistic expectations, fostering a misleading belief that the puzzle is easily solvable. While some Python scripts may effectively tackle the puzzle within the 1-30 range, attempting to extend the solution beyond 40 seem to be practically unfeasible.

The widespread use of such scripts not only generates false hope but also implies a certain level of promotion for the developers themselves rather than a genuine commitment to solving the puzzle.

[1715319835]

1715319835

[1715319835]

1715319835

[AlanJohnson]

In gambling you can be just lucky ... this shit is something far worse. People don't realize how low is the chance to "win" here. 

I have discovered a multitude of scripts and programs on GitHub, numbering at least 96, all claiming to provide solutions for a specific puzzle. This abundance of solutions may give rise to unrealistic expectations, fostering a misleading belief that the puzzle is easily solvable. While some Python scripts may effectively tackle the puzzle within the 1-30 range, attempting to extend the solution beyond 40 seem to be practically unfeasible.

The widespread use of such scripts not only generates false hope but also implies a certain level of promotion for the developers themselves rather than a genuine commitment to solving the puzzle.

You are right. I also tested many programs from github until i started slowly realize how incredibly big are the numbers i'm dealing with a what is the probability to solve puzzles.

Some of programs that can be find on github are utterly stupid - i saw  programs that load the list of so called "dormant bitcoin addresses" a then they are trying to guess the private key to them randomly in 256 bit range. If you think for a moment you can clearly see how stupid it is since there was a big struggle to hit even 64bit puzzle.

Now the 66  is even more difficult. I think even if i had two of first HEX numbers i wouldn't be able to solve it anyway.

[nomachine]

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.

[AlanJohnson]

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.

Well it depends ... There is small luck factor.  I can often see people calulating it in a way "how much time it will take to scan the whole range with your currents keys generating speed"...  But you can do it randomly or the right key can be close to to point in which you started your search. Anyway it's still incredibly hard to solve 66bit.

I was also wondering what who will be able to solve anything if somehow 66 and 130 will be solved ? Maybe we are already at point where it will take years to wait for faster hardware...

[MrlostinBTC]

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!

[AlanJohnson]

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!

Let's say you are sailing thorugh ocean and drop a key into the water.  Come back to that place after a while and try to find it ... there is a chance 

[nomachine]

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!

Let's say you are sailing thorugh ocean and drop a key into the water.  Come back to that place after a while and try to find it ... there is a chance  

If you have one hell of a big magnet.  The question is, what other items might be attracted along the way?  

You may not catch the right key, but you will learn a lot about the of ECDSA's depths

[WanderingPhilospher]

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.

Fuzzy math?

17 characters minus 2, = 15.
15x4 = 60.
You’d be dealing with a 2^60 search space.

[zahid888]

Edit:

GPU

[GR Sasa]

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!

[rosengold]

share with us sir

[citb0in]

share with us sir

why are you interested? he enters a pubkey and searches for a match of n real matches (which are not even sequential). He finds n matches in the pubkey and gets a priv key that has nothing to do with the address he is looking for (puzzle #130 in that example).

Some people just don't get it yet, no matter how many times you say it. The hash value is based on an avalanche effect. Even if you guess n-1 characters correctly it's useless, it doesn't tell you anything.

But some people are really good at it and you have to give them credit for that: Playing window dressing and obviously putting a lot of time and effort into animated graphics. *facepalm*

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

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