Pages:
Author

Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 90. (Read 230098 times)

newbie
Activity: 3
Merit: 0
hi all i read the post since one year sorry for my english i found a interesting think but i does takes me further. in every elliptic curve like y^2= x^3+7 there is something interesting like :
if P(1,y1) - k times--> Q(-29/3 ,y2)
   P(2,y3) --k times--> Q(-3,y2)
 so on there is a simple math here where k is always too know independent from whcih curve we work .
 i don't want to give more information this operation is 10 times faster then k*G= and find the x value 
member
Activity: 499
Merit: 38
No problem, I will upload a full video of these on YouTube in an hour.
Bugs and cracks always appear somewhere and from where no one thought of it, and sometimes they are very simple and very unexpected.

Oh, it sounds like we're invited for a thrilling YouTube premiere! Who knew the drama of consecutive keys from a wallet could be so riveting? And here I was, thinking that bugs and cracks only appeared in poorly written software and manuals. Who knows what secrets lie hidden in the labyrinth of ones and zeros? Only time will tell, my friend, only time will tell. But hey, you've got a keen eye for the unexpected - who knows, maybe your next video will uncover the secret of the universe hidden in the digits of pi.  Wink
newbie
Activity: 18
Merit: 0
It is very surprising that two of my posts were deleted and these two posts were deleted because they were off topic.
there was nothing from the magic circle and nothing obscure, just a simple new arrangement of private keys in hex and decimal format that showed the relationship between the keys.
There are things in this thread that everyone knows are off topic, but they are not deleted. But this arrangement, which is not something special and is a special category, cannot be sent. They delete it
What is the reason?
No problem, I will upload a full video of these on YouTube in an hour.
 It is proven to everyone that consecutive keys from a wallet can be leaked and have bugs.
Now why don't I open a number? I do not have the knowledge of mathematics and programming or the knowledge that is needed to make this connection meaningful.
That's why I couldn't reach the keys, but there are definitely those who, by looking at the numbers, can discover things that the others failed to discover.
Bugs and cracks always appear somewhere and from where no one thought of it, and sometimes they are very simple and very unexpected.
newbie
Activity: 24
Merit: 0
I love python but blows my memory in no time (cpu). And I have been fight with eclipse all my life.
Doesn't matter how many thread I cant run more than 3 hours bc my memory goes to 100%.

Can you tell me if rust has the same memory issue?

thx

This is the puzzle script from this post :
https://bitcointalksearch.org/topic/bitcoin-puzzle-transaction-32-btc-prize-to-who-solves-it-1306983

https://i.ibb.co/xz2p58j/2024-05-10-12-29.png

It consumes all 12 cores I have. It works rock solid like this for days.
But this is a special machine just for these things. I don't use it for anything else.

Wow, you have solid 8x more memory and 3x more cores than I, kudos for you Kiss

I can't just dedicated my cpu for that; I still need to teach tho....
So to compensate I'm using statistics to reduce the range... not perfect but I already cut in half (i believe)

I will try to run your code (even if I never used rust before)

Thx anyways! Wink
member
Activity: 499
Merit: 38
I love python but blows my memory in no time (cpu). And I have been fight with eclipse all my life.
Doesn't matter how many thread I cant run more than 3 hours bc my memory goes to 100%.

Can you tell me if rust has the same memory issue?

thx

This is the puzzle script from this post :
https://bitcointalksearch.org/topic/bitcoin-puzzle-transaction-32-btc-prize-to-who-solves-it-1306983

https://i.ibb.co/xz2p58j/2024-05-10-12-29.png

It consumes all 12 cores I have. It works rock solid like this for days.
But this is a special machine just for these things. I don't use it for anything else.
newbie
Activity: 24
Merit: 0
The Bitcoin puzzle transaction involving multiple addresses generated by a formula with corresponding private key values has intrigued many. The challenge to decipher the formula behind these addresses, with the prize of approximately 32 BTC, remains unsolved, inviting the Bitcoin community's collective efforts and ingenuity to crack it.

Oh, sure! Because nothing screams "fun weekend activity" like trying to crack a cryptographic puzzle for a chance at some digital gold. Who needs Netflix when you can spend hours staring at strings of alphanumeric characters, hoping they form a magical circle that summons the secrets of the universe? It's like a high-stakes Sudoku, except instead of filling in numbers, you're filling in existential dread. But hey, at least you might end up with enough Bitcoin to buy a small tropical island, right? Totally worth it!  Grin

 Cheesy Cheesy Cheesy Cheesy dying by reading that

I had the (dis)pleasure to cross with these puzzles recently, together with k4 of kryptos.
(why Im doing this to myself?lol)

And now I'm surrounding by papers and notes... my broken casio too.

I read so much about the BTC calculation is give me headaches, literally I went to walk an hour to give me a break




newbie
Activity: 24
Merit: 0
jr. member
Activity: 77
Merit: 1
hero member
Activity: 630
Merit: 731
Bitcoin g33k
quote author=nomachine link=topic=1306983.msg64056686#msg64056686 date=1715321668]
Keeping those Digaran fake accounts on their toes is practically a full-time gig now.  Grin
[/quote]

absolutely true. Unfortunately he is not alone abusing this forum by such techniques but I am not allowed to post detailed info.
member
Activity: 499
Merit: 38
Keeping those Digaran fake accounts on their toes is practically a full-time gig now.  Grin
hero member
Activity: 630
Merit: 731
Bitcoin g33k
The Bitcoin puzzle transaction involving multiple addresses generated by a formula with corresponding private key values has intrigued many. The challenge to decipher the formula behind these addresses, with the prize of approximately 32 BTC, remains unsolved, inviting the Bitcoin community's collective efforts and ingenuity to crack it.

uninteresting output of  ChatGPT caused by non-sens input. Actually totally pointless and a waste of time. But somehow you have to keep your fake double-triple-four accounts on their toes, don't you?
member
Activity: 499
Merit: 38
The Bitcoin puzzle transaction involving multiple addresses generated by a formula with corresponding private key values has intrigued many. The challenge to decipher the formula behind these addresses, with the prize of approximately 32 BTC, remains unsolved, inviting the Bitcoin community's collective efforts and ingenuity to crack it.

Oh, sure! Because nothing screams "fun weekend activity" like trying to crack a cryptographic puzzle for a chance at some digital gold. Who needs Netflix when you can spend hours staring at strings of alphanumeric characters, hoping they form a magical circle that summons the secrets of the universe? It's like a high-stakes Sudoku, except instead of filling in numbers, you're filling in existential dread. But hey, at least you might end up with enough Bitcoin to buy a small tropical island, right? Totally worth it!  Grin
newbie
Activity: 4
Merit: 0
The Bitcoin puzzle transaction involving multiple addresses generated by a formula with corresponding private key values has intrigued many. The challenge to decipher the formula behind these addresses, with the prize of approximately 32 BTC, remains unsolved, inviting the Bitcoin community's collective efforts and ingenuity to crack it.
newbie
Activity: 18
Merit: 0

Why are you nervous?
All the keys are merged together, there is no space between the keys, and it becomes a key with a length of 561 characters like this:
137815314CE01D3202483A7B1460293068F3C9361764F3080D5749FD2C551BA5342DE40F556E52D C2A041FA5EE5340326E6AC3875D916CE817E2551E3D94CD647D4 FE747B862A62E1A96CA8D834A65911D4AED211709DE820A7C1757756A9322382FACD04B5F8303E9 E9AE4933D6153869ACC5B2A221C58D8F6BD3B27C591E02B35A358F 122FCA143C052EC18388D5446CD610B53CBAADE6D7CE3B9B174176B015F4D22BD43C2E935475070 A1A009D4EFAE164CB9E3C180788E47E326C236FB6D5AD1F436ABE1F9B6 7E1149D18B63AC4FFDF1EB25C90795D61C2C675B852189A217496CBB87CAB44FFC07A1825367BBE 13C96A3742F64906363D541EB611ABEE7CCE5EFDACCF6808F7051F27B09 112D41A838B13505B26867
  It is interesting that the number of characters in hex mode by adjusting the distance between the characters of numbers (550) is only 11 away from the length of the key.
Now this one key with the length of 561 is placed inside the spiral circle and we have magic order in setting the distance of all characters (one by one) on 550.
did you understand?

https://www.talkimg.com/images/2024/05/05/roBa2.gif
member
Activity: 165
Merit: 26
The problem is what are you going to use for the dinosaur numbers above Puzzle 128. I wrote above additionally.
Irrelevant. EC field (x, y) is always 256-bit, so this is the size of the operands always even for private key 0x1. Scalar (private key) size does not matter, beyond the initial multiplication. Jump points are precomputed, so we only have additions. The larger keyspace is only problematic due to its size, it doesn't affect the speed itself. Finding a 30-bit or 256-bit solution runs at the same speed. Actually, you don't even need to have any knowledge of the group size itself, just of the interval size.

What we need is algorithms breakthrough, or lots of coordinated "potatoes" and patience.
member
Activity: 499
Merit: 38
The problem is what are you going to use for the dinosaur numbers above Puzzle 128. I wrote above additionally. These test scripts will not work configured like this with Puzzle 130.

This will work whatever number you insert - use gmp.h
Code:
#include
#include
#include
#include
#include
#include

int main() {
    mpz_class min_range("18446744073709551615");
    mpz_class max_range("36893488147419103231");
    mpz_class counter = 0;
    mpz_class dec;
    gmp_randstate_t state;

    gmp_randinit_default(state);
    std::time_t start_time = std::time(nullptr);
    double total_time = 0;

    mpz_t range;
    mpz_sub(range, max_range.get_mpz_t(), min_range.get_mpz_t());

    while (true) {
        mpz_urandomm(dec.get_mpz_t(), state, range);
        mpz_add(dec.get_mpz_t(), dec.get_mpz_t(), min_range.get_mpz_t());
        counter++;

        std::time_t current_time = std::time(nullptr);
        double elapsed_time = difftime(current_time, start_time);

        if (elapsed_time > total_time) {
            std::cout << "Total " << counter << " numbers in " << elapsed_time << " seconds: " << std::setprecision(0) << std::fixed << counter / elapsed_time << " numbers/s" << std::endl;
            total_time = elapsed_time;
        }

    }

    gmp_randclear(state);
    mpz_clear(range);
    return 0;
}
member
Activity: 165
Merit: 26
I can't squeeze out more than 852.000 affine point additions per second

I have 249457 hops per second in python  converting this script with cpython into .so

Imagine this in Rust, how fast would it go? Grin
No idea, but I can tell you how fast it would go in C using the GMP routines, as I benchmarked a lot of tweaks and misc. formulas.

Close to 690k jumps /s, in-place point addition, no reallocs - this with using lowest level mpn_* routines (assembler optimized).
Around 638k jumps/s with the mpz_* routines.

Compare this to using the routines in libsecp256k1 field_impl.h and same formula steps:
affine + affine: 852k jumps/s (1 inversion, 2 multiplications, 1 squaring)

libsecp256k1 jacobian + affine addition -> jacobian result:
7.5M jumps/s (8M 3S) - removed safety checks since no point is the infinity and neither can be the result)
But... non-deterministic, I struggled for weeks to find a way to use a J point represented in multiple different ways to produce a stable hash, even a single one bit 50% probability hash as a base for deterministic jump). Seems we can only compare two J points for equality or non-equality, comparison result can vary its sign due to Z scaling.

It doesn't matter what Rust compiles down to, it can never ever generate machine code that runs faster than what the lowest level assembler routines can handle.

So we either need lots of threads (GPU) or some special hardware to speed things up. Sad
member
Activity: 499
Merit: 38
I can't squeeze out more than 852.000 affine point additions per second


I have 249457 hops per second in python  converting this script with cpython into .so

Code:
import time
import os
import sys
import random
import secp256k1 as ice
import gmpy2

if os.name == 'nt':
    os.system('cls')
else:
    os.system('clear')
t = time.ctime()
sys.stdout.write(f"\033[?25l")
sys.stdout.write(f"\033[01;33m[+] Kangaroo: {t}\n")
sys.stdout.flush()

modulo = gmpy2.mpz(0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F)
order = gmpy2.mpz(0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141)
Gx = gmpy2.mpz(0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798)
Gy = gmpy2.mpz(0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8)

# Define Point class
class Point:
    def __init__(self, x=0, y=0):
        self.x = gmpy2.mpz(x)
        self.y = gmpy2.mpz(y)

PG = Point(Gx, Gy)
Z = Point(0, 0)  # zero-point, infinite in real x, y - plane

def add(P, Q, p=modulo):
    if P == Z:
        return Q
    elif Q == Z:
        return P
    elif P.x == Q.x and (P.y != Q.y or P.y == 0):
        return Z
    elif P.x == Q.x:
        m = (3 * P.x * P.x) * gmpy2.invert(2 * P.y, p) % p
    else:
        m = (Q.y - P.y) * gmpy2.invert(Q.x - P.x, p) % p
  
    x = (m * m - P.x - Q.x) % p
    y = (m * (P.x - x) - P.y) % p
    return Point(x, y)

def mul2(P, p=modulo):
    if P == Z:
        return Z
    m = gmpy2.f_mod(3 * P.x * P.x * gmpy2.invert(2 * P.y, p), p)
    x = gmpy2.f_mod(m * m - 2 * P.x, p)
    y = gmpy2.f_mod(m * (P.x - x) - P.y, p)
    return Point(x, y)

def mulk(k, P=PG, p=modulo):
    if k == 0:
        return Z
    elif k == 1:
        return P
    elif k % 2 == 0:
        return mulk(k // 2, mul2(P, p), p)
    else:
        return add(P, mulk((k - 1) // 2, mul2(P, p), p), p)

def X2Y(X, y_parity, p=modulo):
    X_cubed = gmpy2.powmod(X, 3, p)
    X_squared = gmpy2.powmod(X, 2, p)
    tmp = gmpy2.f_mod(X_cubed + 7, p)
    Y = gmpy2.powmod(tmp, gmpy2.f_div(gmpy2.add(p, 1), 4), p)
    if y_parity == 1:
        Y = gmpy2.f_mod(-Y, p)
    return Y


def comparator(A, Ak, B, Bk):
    result = set(A).intersection(set(B))
    if result:
        sol_kt = A.index(next(iter(result)))
        sol_kw = B.index(next(iter(result)))
        HEX = "%064x" % abs(Ak[sol_kt] - Bk[sol_kw])
        dec = int(HEX, 16)
        wifc = ice.btc_pvk_to_wif(HEX)
        wifu = ice.btc_pvk_to_wif(HEX, False)
        caddr = ice.privatekey_to_address(0, True, dec)
        uaddr = ice.privatekey_to_address(0, False, dec)
        total_time = time.time() - starttime
        print('\n[+] total time: %.2f sec' % (total_time))
        t = time.ctime()
        print(f"\033[32m[+] PUZZLE SOLVED: {t} \033[0m")
        print(f"\033[32m[+] Private key (wif) Compressed : {wifc} \033[0m")
        with open("KEYFOUNDKEYFOUND.txt", "a") as file:
            file.write("\n\nSOLVED " + t)
            file.write(f"\nTotal Time: {total_time:.2f} sec")
            file.write(f"\nRandom seed: {seed}")
            file.write("\nPrivate Key (decimal): " + str(dec))
            file.write("\nPrivate Key (hex): " + HEX)
            file.write("\nPrivate key (wif) Compressed : " + wifc)
            file.write("\nPrivate key (wif) Uncompressed: " + wifu)
            file.write("\nBitcoin address Compressed: " + caddr)
            file.write("\nBitcoin address Uncompressed: " + uaddr)
            file.write(
                "\n-------------------------------------------------------------------------------------------------------------------------------------------\n"
            )
        file.close()
        return True
    else:
        return False

def check(P, Pindex, DP_rarity, A, Ak, B, Bk):
    if P.x % DP_rarity == 0:
        A.append(gmpy2.mpz(P.x))
        Ak.append(gmpy2.mpz(Pindex))
        return comparator(A, Ak, B, Bk)
    else:
        return False

# Generate a list of powers of two for faster access

def generate_powers_of_two(hop_modulo):
    return [gmpy2.mpz(1 << pw) for pw in range(hop_modulo)]

def search(P, W0, DP_rarity, Nw, Nt, hop_modulo, upper_range_limit, lower_range_limit, powers_of_two):
    solved = False
    t = [gmpy2.mpz(lower_range_limit + gmpy2.mpz(random.randint(0, upper_range_limit - lower_range_limit))) for _ in range(Nt)]
    T = [mulk(ti) for ti in t]
    dt = [gmpy2.mpz(0) for _ in range(Nt)]
    w = [gmpy2.mpz(random.randint(0, upper_range_limit - lower_range_limit)) for _ in range(Nw)]
    W = [add(W0, mulk(wk)) for wk in w]
    dw = [gmpy2.mpz(0) for _ in range(Nw)]
    print('[+] tame and wild herds are prepared')
    Hops, Hops_old = 0, 0
    t0 = time.time()  
    while not solved:
        for k in range(Nt):
            Hops += 1
            pw = T[k].x % hop_modulo
            dt[k] = powers_of_two[pw]
            solved = check(T[k], t[k], DP_rarity, T, t, W, w)
            if solved: break
            t[k] += dt[k]
            T[k] = add(P[int(pw)], T[k])
        if solved: break
        for k in range(Nw):
            Hops += 1
            pw = W[k].x % hop_modulo
            dw[k] = powers_of_two[pw]
            solved = check(W[k], w[k], DP_rarity, W, w, T, t)
            if solved: break
            w[k] += dw[k]
            W[k] = add(P[int(pw)], W[k])
        if solved: break
        t1 = time.time()
        if (t1 - t0) > 5:
            print('\r[+] Hops: %.0f h/s' % ((Hops - Hops_old) / (t1 - t0)), end='', flush=True)
            t0 = t1
            Hops_old = Hops
    print('[+] Hops:', Hops)
    return 'sol. time: %.2f sec' % (time.time() - starttime)

puzzles = [\
    ('0209c58240e50e3ba3f833c82655e8725c037a2294e14cf5d73a5df8d56159de69',32),\
    ('03a2efa402fd5268400c77c20e574ba86409ededee7c4020e4b9f0edbee53de0d4',40),\
    ('025e466e97ed0e7910d3d90ceb0332df48ddf67d456b9e7303b50a3d89de357336',44),\
    ('026ecabd2d22fdb737be21975ce9a694e108eb94f3649c586cc7461c8abf5da71a',45),\
    ('03f46f41027bbf44fafd6b059091b900dad41e6845b2241dc3254c7cdd3c5a16c6',50),\
    ('0230210c23b1a047bc9bdbb13448e67deddc108946de6de639bcc75d47c0216b1b',65),\
    ('03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852',130)]

puzzle = 40
for elem in puzzles:
    s, n = elem
    if puzzle == n: break

kangaroo_power = 4
DP_rarity = 1 << int(((puzzle -  2*kangaroo_power)/2 - 2))
hop_modulo = ((puzzle - 1) // 2) + kangaroo_power
Nt = Nw = 2**kangaroo_power

X = gmpy2.mpz(s[2:66], 16)
Y = X2Y(X, gmpy2.mpz(s[:2]) - 2)

W0 = Point(X,Y)
starttime = oldtime = time.time()
search_range = 2**(puzzle-1)

lower_range_limit = 2 ** (puzzle - 1)
upper_range_limit = (2 ** puzzle) - 1

print(f"[+] [Puzzle]: {puzzle}")
print(f"[+] [Lower range limit]: {lower_range_limit}")
print(f"[+] [Upper range limit]: {upper_range_limit}")

# Precompute powers of two for faster access
powers_of_two = generate_powers_of_two(hop_modulo)

# Initialize variables
T, t, dt = [], [], []
W, w, dw = [], [], []

#Random seed Config
seed = os.urandom(9)
print(f"[+] [Random seed]: {seed}")
random.seed(seed)

Hops = 0
N_tests = 1

P = [PG]
for k in range(255): P.append(mul2(P[k]))  
print('[+] P-table prepared')

for k in range(N_tests):
    solved = False
    search(P, W0, DP_rarity, Nw, Nt, hop_modulo, upper_range_limit, lower_range_limit, powers_of_two)

print('[+] Average time to solve: %.2f sec' % ((time.time()-starttime)/N_tests))

It normally goes to 207301 h/s

Imagine this in Rust, how fast would it go? Grin


u128
const uint64_t
uint64 in C & u128 in Rust not work for Puzzle 130 (try to deal with dinosaur numbers)

BigUint/BIGINT from SSL works or GMP can be used Wink
member
Activity: 165
Merit: 26
Result
0x1A96CA8D8 | 82762283.93 keys/s
Generated number (decimal): 7137437912


single thread, M2 Proc.
Here's the ultimate private key cracking tool.
Code:
int main() {
   const uint64_t minRange = 0x100000000;
   const uint64_t maxRange = 0x1ffffffff;
   const uint64_t magic_number = 0x1a96ca8d8 - minRange;
   uint64_t max = maxRange - minRange + 1;      // range size
   uint64_t speed;
   uint64_t count = 0;

   struct timespec start, ticks;
   clock_gettime(CLOCK_MONOTONIC, &start);

   while (max--) {
        if (count == magic_number) {
            printf("Generated number: %16llx\n", count + minRange);
//            break;
        }

        ++count;
    }

    clock_gettime(CLOCK_MONOTONIC, &ticks);
    uint64_t ns = (ticks.tv_sec - start.tv_sec) * 1000000000ULL + ticks.tv_nsec - start.tv_nsec;
    // avoid 64-bit overflow
    speed = count * 1000000ULL / (ns / 1000);
    printf("Ops: %llu speed: %llu ops/s\n", count, speed);

    return 0;
}


Generated number:        1a96ca8d8
Ops: 4294967296 speed: 3099732241 ops/s


Apple M1, single thread.

I would like someone to make a Pollard's kangaroo for SECPK1 in Rust. Maybe it could work faster, Rust programs also optimize quite well, sometimes better than C. Enforces thread-safety of all code and data, even in 3rd party libraries.
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

We're bounded by secp256k1 field operations, it can't work faster than what a CPU is capable of. I made a kangaroo in plain C, and the bottleneck is the EC point addition, I can't squeeze out more than 852.000 affine point additions per second (the only speed up would be some assembler code). If someone finds a magical way to find an scale-invariant hash of a Jacobian point it would run 10x faster though. Otherwise we're stuck with having to compute a modular inverse at every kangaroo jump, and no programming language can save you from this limitation.
member
Activity: 499
Merit: 38
Experiments with your python codes on rust language


You have here my full Puzzle sctipt in Rust:
https://bitcointalksearch.org/topic/m.63539973
It's very fast. Same as C++
But when you put Puzzle 66 and above as a test, everything is slow. Without a public key, I can only scratch my head.

ahahah soo hilarious.

Try test with custom script address build then, it's faster.
private key > Compresssed public key > custom script > address format.

i try that method it's faster enough.

I would like someone to make a Pollard's kangaroo for SECPK1 in Rust. Maybe it could work faster, Rust programs also optimize quite well, sometimes better than C. Enforces thread-safety of all code and data, even in 3rd party libraries.
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.....on potatoe  Grin

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


It's a pity that I don't have more time to deal with this.
Pages:
Jump to: