Bitcoin puzzle transaction ~32 BTC prize to who solves it

[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

[1715294160]

1715294160

[1715294160]

1715294160

[1715294160]

1715294160

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

[VinIVaderr]

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()

[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

[mabdlmonem]

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

What about 58.51?)

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

58.5

PK 0.5
57896044618658097711785492504343953926418782139537452191302581570759080747169

pk 58
58

58.5
57896044618658097711785492504343953926418782139537452191302581570759080747169
+
58
=
57896044618658097711785492504343953926418782139537452191302581570759080747227

in hex
0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20db

What about 58.51?)

5851/100

Code:

import bitcoin

target= 5851

Div=100

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

What about 58.51?)

5851/100

Code:

import bitcoin

target= 5851

Div=100

N=115792089237316195423570985008687907852837564279074904382605163141518161494337

a=bitcoin.inv(Div,N)

b= target*a % N

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

If your script giving you result, then ok, other word, it's simple solutions, for play with every floating points, I am not at laptop at this time, later explain if your script not working...

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

Today is the day for mcdouglasx to reveal his secret?

[WanderingPhilospher]

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!

Today is the day for mcdouglasx to reveal his secret?

Sometimes calculations are off, could be +/- hours or days. And that's barring no down time via power outages, equipment failure, etc.

Hopefully he is close.

[albert0bsd]

Well, we're waiting  

puzzle 66 is still there @mcdouglasx