Pages:
Author

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

member
Activity: 165
Merit: 26
Im not understand what this code doing

while rnd(817190); return;

Your code samples 14 elements from a set of 23, and stops when it matches the desired combination, what is not to understand here, or do you not understand your own posted code?

comb(23, 14) = 817190

so on average the loop will run 817190 times until it finds the match.
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
this code is very good, but, too  slow for 65 pcs, maybe nomachine modify to fast RND gen in rust ?

After removing all redundancy, first one is literally equivalent to:

Code:
while rnd(817190); return;

so yeah it's fast assuming rnd() returns 0 sooner or later.

Forget sqrt bounds, let's use factorial complexity and infinite recursive loops. Ok...

There are no patterns in the bits of the keys, if you exclude some patterns than that would mean there is a pattern in the keys. Does that make sense? Maybe reflect on it for a few minutes.

There is no RND magic generator, neural network, magic circle that can ever predict the next unknown sequence. There are an infinite amount of RND generator equations, neural network matrice states, and magic circles that can FIT any amount of KNOWN random bits. But that does not make them crystal balls, they will all fail to predict any other sequence other than what is already known.

I talk what rng is faster, , second rnd not generate chaos, he generate sequence. Bit is unknown, but next bit in privkey has restriction and generated sequence too, because he is next bit , nec bit not same to previous bit what's why this is sequence. Yes,  sequense for what transform 130 bit to 0 bit 65 bit long, but you not know, exact what bit first in generated sequence is first of 120 bit in priv  130 or not.


Im not understand what this code doing

while rnd(817190); return;


Can you explain ? This is summ of parts of puzzle ?

factorial complexity, this is nothing , not joke too...

abount factorial complexity:


inpuT  0x272a396ed18748cd2442bd57161ca6eb5 ---- this is inlut privkey 120 bit
result -W; 0xcf4a324de92c2b1f8cf 66 i 1 input 0x67a51926f496158fc67a zGood 2 Zz 66
zzzzzGOOD 2 resultGood 0xcf4a324de92c2b1f8cf valid 66 1 zzTotal 66 one 0 5 thre 50 66 ddd-Fake 48 zGood 2
input -W: 0x67a51926f496158fc67a PP 66
Iiiii 1 s 0x1 0xcf4a324de92c2b1f8cf 0xcf4a324de92c2b1f8cf 0xcf4a324de92c2b1f8cf
OДИH 232476502045627352 18


this is result after manipulation

0xcf4a324de92c2b1f8cf

this is a number need get, for take result:

232476502045627352


and if operations is  too mach, and need save many data to disk, more as
adecvate is go to final result without intermediate savings.
member
Activity: 165
Merit: 26
this code is very good, but, too  slow for 65 pcs, maybe nomachine modify to fast RND gen in rust ?

After removing all redundancy, first one is literally equivalent to:

Code:
while rnd(817190); return;

so yeah it's fast assuming rnd() returns 0 sooner or later.

Forget sqrt bounds, let's use factorial complexity and infinite recursive loops. Ok...

There are no patterns in the bits of the keys, if you exclude some patterns than that would mean there is a pattern in the keys. Does that make sense? Maybe reflect on it for a few minutes.

There is no RND magic generator, neural network, magic circle that can ever predict the next unknown sequence. There are an infinite amount of RND generator equations, neural network matrice states, and magic circles that can FIT any amount of KNOWN random bits. But that does not make them crystal balls, they will all fail to predict any other sequence other than what is already known.
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
because "^" part only from 1 to 130

Oh, COBRAS broke the square root bound! We only have 130 parts in a 130-bit puzzle, guess no one figured this out. Let's now reduce the range from 130 to 32, because why not. Maybe divide everything by zero (n) and call it a day? I'd say the magic astrological chart would work better though. But in base 112. Add parity to each letter in the puzzle addresses and solve using bubble sort. Spin the wheel until we reduce the checksums to zero, than split circle in 256. Convert each digit from cartesian to polar and compute corresponding point on the curve. Make lattice from points, to compute correct font size to use. Unspin, rejoin, set font size, get all keys. There, ECDLP solved.


no, puzzle is, this,

Thanks to nomachine for code


this code is very good, but, too  slow for 65 pcs, maybe nomachine modify to fast RND gen in rust ?

import random as A

tri = [40,38,35,34,33,32,29,27,25,24,22,20,19,18]

B=list(range(40,17,-1))

C =[]
count = 0

while tri != C:
    count=count+1
    C=A.sample(B,k=A.randint(14,14))
    C.sort(reverse=True);
    
    if tri == C:
        print(C,"yes")
    if count % 60000 ==0:
        print(C,count)
        print(len(tri))
        



and this



speed is very difference, but


from collections import deque

tri = [41,40,39,38,37,36,35,34,33,32,31,30,29,28,27,26,25,24,23,22,21,20,19,18]#,9,8,7,6,5,4,2]
one = [40,38,35,34,33,32,29,27,25,24,22,20,19,18]

def generate_combinations(lst, r):
    if r == 0:
        yield []
    else:
        for i in range(len(lst)):
            current = lst
            rest = lst[i + 1:]
            for c in generate_combinations(rest, r - 1):
                yield [current] + c

def bfs(tri, one):
    queue = deque([(tri, [])])
    counter = 0
    while queue:
        current_tri, path = queue.popleft()
        counter += 1
        if len(current_tri) == len(one):
            print("Пpoмeжyтoчный peзyльтaт:", current_tri, flush=True)
        if set(current_tri) == set(one):
            print("Peшeниe нaйдeнo!", flush=True)
            print(path, flush=True)
            return
        for r in range(1, len(current_tri) + 1):
            for combination in generate_combinations(current_tri, r):
                counter= counter+1
                new_tri = [x for x in current_tri if x not in combination]
                if len(new_tri) <= len(one):
                    if counter % 1000 == 0:
                        print("Oбpaбaтывaeтcя кoмбинaция:", combination, "Counter:", counter, flush=True)
                    queue.append((new_tri, path + combination))

bfs(tri, one)



and you need jast 50..65 puzzle length for solve 2^120

all parts of puzzle has restriction, I don understand what sqrt you talk, but jast what total part of puzle 120 and for solve need  aproximately  120 / 2
member
Activity: 165
Merit: 26
because "^" part only from 1 to 130

Oh, COBRAS broke the square root bound! We only have 130 parts in a 130-bit puzzle, guess no one figured this out. Let's now reduce the range from 130 to 32, because why not. Maybe divide everything by zero (n) and call it a day? I'd say the magic astrological chart would work better though. But in base 112. Add parity to each letter in the puzzle addresses and solve using bubble sort. Spin the wheel until we reduce the checksums to zero, than split circle in 256. Convert each digit from cartesian to polar and compute corresponding point on the curve. Make lattice from points, to compute correct font size to use. Unspin, rejoin, set font size, get all keys. There, ECDLP solved.
member
Activity: 503
Merit: 38
I don’t know what I missed. I tried everything imaginable.  I now have a collection of 150 useless scripts, all aimed at cracking this puzzle. From polynomial regression to geometric progressions, there is no discernible pattern here. . I even spent seven whole months targeting the last eighteen characters of the WIF, attempting to reconstruct the private key. Regardless of which method you choose, without knowing the public key, this is unsolvable. At best, it could be solved in thousands of years. The numbers involved are astronomical—comparable to the size of the entire universe. It would take advanced quantum computing, and even then, only an exceptionally powerful one, to crack this puzzles without  the public key.
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
@nomachine privkey of btc is a geometric progression. they have only summ of ^ , 2^10+2^12+2^30 etc. Random generation of 2^10 to 2^130 has 130 parts(because "^" part only from 1 to 130 fkr 130 puzzke) of puzzle or range, everyone can select what hi like more range or puzzle. And if thant ^40 in result remove1..40 first parts of puzzle
member
Activity: 503
Merit: 38
I don't need no SHA-256, no RIPEMD-160. what is needed is an optimized algorithm that works with non-compression public keys.

The fastest approach to this is not tied to a specific programming language but rather to how well ECC scalar multiplication is optimized. Libraries such as secp256k1 in C or Rust's secp256k1 crate are already highly optimized for this task.


Rng generators is more faster then simple range brute or kangaroo range brute. Kangaroo not provide result with 100% garanty, why people continue use and talk about kangaroo. I think kangaroo and  bsgs not specialisation on crack, for ex they not provide option for replace base point, replace scale of range etc

Brute force is like rolling a dice repeatedly at high speed, hoping to land on a specific number. Each roll is random, and you have no control over the outcome, so you're essentially relying on sheer luck. The faster you roll the dice, the quicker you can try different possibilities.

Bitcoin key generation, on the other hand, is more like playing a game of Craps. The game consists of multiple stages which slow down the whole process of winning: you first roll the dice to establish a target (this represents the key generation). After that, you roll again in the hopes of matching or getting closer to the target. In both cases, there's an element of randomness and strategy, but instead of relying purely on luck, Bitcoin generation involves cryptographic rules that govern each stage, making it a complex and structured process which reduce the attacks to zero..
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
I don't need no SHA-256, no RIPEMD-160. what is needed is an optimized algorithm that works with non-compression public keys.

The fastest approach to this is not tied to a specific programming language but rather to how well ECC scalar multiplication is optimized. Libraries such as secp256k1 in C or Rust's secp256k1 crate are already highly optimized for this task.


Rng generators is more faster then simple range brute or kangaroo range brute. Kangaroo not provide result with 100% garanty, why people continue use and talk about kangaroo. I think kangaroo and  bsgs not specialisation on crack, for ex they not provide option for replace base point, replace scale of range etc
jr. member
Activity: 42
Merit: 0
No major shortcuts exist for ECC due to the huge math involved.  Sad
member
Activity: 503
Merit: 38
I don't need no SHA-256, no RIPEMD-160. what is needed is an optimized algorithm that works with non-compression public keys.

The fastest approach to this is not tied to a specific programming language but rather to how well ECC scalar multiplication is optimized. Libraries such as secp256k1 in C or Rust's secp256k1 crate are already highly optimized for this task.
newbie
Activity: 23
Merit: 0
Good afternoon, friends. I have one question - in which programming language is there the fastest algorithm for obtaining a non-compression public key from a hexadecimal value? Can someone share it? it is needed for speed like kangaroo or keyhant. exactly, only obtaining a non-compression public key without any other functions. and yet - any interval can be reduced by 20-30%, perhaps more, I have succeeded so far.

There is no programming language on planet Earth or trick that can drastically speed up Bitcoin key generation or hashing (SHA-256, RIPEMD-160) .
Any perceived speed improvements, like in kangaroo or KeyHunt, come from optimization techniques for specific tasks, not from changing the core cryptographic functions.
Reducing the search interval (as mentioned above) can help focus efforts, but it doesn't change the time it takes to compute each key or hash.
Using multiple threads or GPUs (parallelization) can improve the throughput of key generation but not the speed of individual computations. In short, at least 600 GPUs are required.
I don't need no SHA-256, no RIPEMD-160. what is needed is an optimized algorithm that works with non-compression public keys.

No... What is needed is massive computational power or quantum computers. Everything else at this point is wasting time and electricity.
What does that have to do with it? I asked if there is an algorithm that is comparable in speed to kangaroo or keyhant
member
Activity: 122
Merit: 11
Good afternoon, friends. I have one question - in which programming language is there the fastest algorithm for obtaining a non-compression public key from a hexadecimal value? Can someone share it? it is needed for speed like kangaroo or keyhant. exactly, only obtaining a non-compression public key without any other functions. and yet - any interval can be reduced by 20-30%, perhaps more, I have succeeded so far.

There is no programming language on planet Earth or trick that can drastically speed up Bitcoin key generation or hashing (SHA-256, RIPEMD-160) .
Any perceived speed improvements, like in kangaroo or KeyHunt, come from optimization techniques for specific tasks, not from changing the core cryptographic functions.
Reducing the search interval (as mentioned above) can help focus efforts, but it doesn't change the time it takes to compute each key or hash.
Using multiple threads or GPUs (parallelization) can improve the throughput of key generation but not the speed of individual computations. In short, at least 600 GPUs are required.
I don't need no SHA-256, no RIPEMD-160. what is needed is an optimized algorithm that works with non-compression public keys.

No... What is needed is massive computational power or quantum computers. Everything else at this point is wasting time and electricity.
newbie
Activity: 23
Merit: 0
Good afternoon, friends. I have one question - in which programming language is there the fastest algorithm for obtaining a non-compression public key from a hexadecimal value? Can someone share it? it is needed for speed like kangaroo or keyhant. exactly, only obtaining a non-compression public key without any other functions. and yet - any interval can be reduced by 20-30%, perhaps more, I have succeeded so far.

There is no programming language on planet Earth or trick that can drastically speed up Bitcoin key generation or hashing (SHA-256, RIPEMD-160) .
Any perceived speed improvements, like in kangaroo or KeyHunt, come from optimization techniques for specific tasks, not from changing the core cryptographic functions.
Reducing the search interval (as mentioned above) can help focus efforts, but it doesn't change the time it takes to compute each key or hash.
Using multiple threads or GPUs (parallelization) can improve the throughput of key generation but not the speed of individual computations. In short, at least 600 GPUs are required.
I don't need no SHA-256, no RIPEMD-160. what is needed is an optimized algorithm that works with non-compression public keys.
member
Activity: 503
Merit: 38
Good afternoon, friends. I have one question - in which programming language is there the fastest algorithm for obtaining a non-compression public key from a hexadecimal value? Can someone share it? it is needed for speed like kangaroo or keyhant. exactly, only obtaining a non-compression public key without any other functions. and yet - any interval can be reduced by 20-30%, perhaps more, I have succeeded so far.

There is no programming language on planet Earth or trick that can drastically speed up Bitcoin key generation or hashing (SHA-256, RIPEMD-160) .
Any perceived speed improvements, like in kangaroo or KeyHunt, come from optimization techniques for specific tasks, not from changing the core cryptographic functions.
Reducing the search interval (as mentioned above) can help focus efforts, but it doesn't change the time it takes to compute each key or hash.
Using multiple threads or GPUs (parallelization) can improve the throughput of key generation but not the speed of individual computations. To make a long story short, at least 600 GPUs are required for puzzles with three digits.
newbie
Activity: 22
Merit: 1
I have more and more doubts that some geniuses are solving the puzzle. In my opinion, starting from the 120bit solution, the creator does all this. To keep the interest in his mystery alive. If you compare the sequence of events (dates of decisions, increase in the prize), then everything adds up to a logical picture. Now it is more profitable to use computing power for the inference of neural networks, for their training, rather than for searching for a needle in a haystack with an unknown result. And here you need very large computing power, which will cost a lot to rent.
I've been saying this for a long time, but people keep rushing blindly, like a donkey chasing a carrot! Puzzles 120, 125, 130 have all been emptied by the creator, and possibly Puzzle 66 as well, intercepted by him to cover his tracks. Puzzle 66 was broadcast just moments before the next block was mined.
member
Activity: 873
Merit: 22
$$P2P BTC BRUTE.JOIN NOW ! https://uclck.me/SQPJk
28cde60e3110e002321ce9000000000000 514760
27560a1669d5ee086d36112e0000000000 545000
19e90c65037689ea4cefbd10ecc0000000 800000
183a40986d2205014dc12a580000000000 88e400
175b15fd4ed7055500d81a335000000000 8e0000
15d6c33dae17744949b1ba000000000000 97dcf0
15d1b9986eb4aa08ac93fd878400000000 980000
1466f30718887001190e74800000000000 a28ec0
13ab050b34eaf704369b08970000000000 a8a000

126402baad8d039c0829e0000000000000 b4565d,  85 priv - new low



0x33d218ca06ed13d499df7a21d98,  105 priv

my target 2^60

... to be continue




newbie
Activity: 23
Merit: 0
Good afternoon, friends. I have one question - in which programming language is there the fastest algorithm for obtaining a non-compression public key from a hexadecimal value? Can someone share it? it is needed for speed like kangaroo or keyhant. exactly, only obtaining a non-compression public key without any other functions. and yet - any interval can be reduced by 20-30%, perhaps more, I have succeeded so far.
member
Activity: 165
Merit: 26
Dear
Without experiment speak is unfair,
First I explain for problem inside kangaroo where 125bit ...
Ihow to use.. for those who really want use kangaroo

Do you even understand what you are talking about? Anyway, good luck with your plan, I'm not gonna bother making drawings for you!
member
Activity: 122
Merit: 11

Dear
Without experiment speak is unfair,
First I explain for problem inside kangaroo where 125bit ...
Ihow to use.. for those who really want use kangaroo

Can you please provide a script that is solving for example a random 2^35 range and adding 100 bits to check 2^135 key for puzzle 135?
But ((2^135)-(2^134))/2^35 = 633825300114114700748351602688 ranges of 2^35

I tried with chatgpt but did not got a good script, also speed was only about 2000 hops/s from original script where I have about 180000 h/s
Or you can send me to PM if you don't want to share public and I promise to reward you if I'll be able to solve the key using your idea

Thank you
I will post script, in few hours, I am faraway from my desktop system, upon reach I will post

Digaran strikes again !
Pages:
Jump to: