Bitcoin puzzle transaction ~32 BTC prize to who solves it

[lordfrs]

Well, tell me how you know this?  

puzzle 80 private key is even number    105520030589234487939456
puzzle 85 private key is even number    21090315766411506144426920
puzzle 90 private key is odd number      868012190417726402719548863
puzzle 95 private key is even number    25525831956644113617013748212
puzzle 100 private key is even number   868221233689326498340379183142
puzzle 105 private key is odd number    29083230144918045706788529192435
puzzle 110 private key is even number  1090246098153987172547740458951748
puzzle 115 private key is even number  31464123230573852164273674364426950
puzzle 120 private key is odd number     ************************************
puzzle 125 private key is even number    *************************************
puzzle 130 private key is even number    **************************************

[digaran]

Fundamentally, it is not a question of a desire/idea what someone conceived for building as script.
Ceate/invent a random generator 10 times faster than all existing ones. Any programming language.
Then we talk further on ideas.

There are very fast ones especially for short keys. But we need very large keys.

I'm not sure I follow what you are talking about, who are you talking to? Hope it's not me.
What exactly does it mean to invent a random generator 10 times faster? Looks like you are confused about random, it just selects values without any pattern, the "speed" depends on other factors such as implementation and hardware. Unless you can invent a computer which operates beyond binary, there is no 10x faster invention.

Wait, they already invented such computer, it's called quantum, but where is it? No where to be found.

Cool story though about ideas, I have seen only a few useful ones, such as the one searching for rmd160 with step size, stride etc.
Have you seen a donkey with horns? What could happen if donkeys had horns? I imagine all our ancestors would have died a long time ago due to injuries caused by such creatures, that's why God didn't give them horns.
This applies to people like me, if I had programming skills/talent, we wouldn't be here chatting, read between the lines.

[nomachine]

I'm not sure I follow what you are talking about, who are you talking to? Hope it's not me.
What exactly does it mean to invent a random generator 10 times faster? Looks like you are confused about random, it just selects values without any pattern, the "speed" depends on other factors such as implementation and hardware. Unless you can invent a computer which operates beyond binary, there is no 10x faster invention.

Example:
https://github.com/lemire/fastrand

Fast random number generation in an interval in Python using PCG: Up to 10x faster than random.randint.

But try to generate 128bit number. You can't even do that with NumPy.  
Nobody cares what we doing here, and why should they?


I even use UUID to generate numbers (for testing).

Code:

import concurrent.futures, sys, os, secp256k1 as ice, multiprocessing
import uuid

def generate_h160(dec):
    h160 = ice.privatekey_to_h160(2, True, dec).hex()
    return dec, h160

if __name__ == "__main__":
    os.system("clear")
    start = 36893488147419103231
    end = 73786976294838206463
    num_cores = multiprocessing.cpu_count()
    with concurrent.futures.ProcessPoolExecutor(max_workers=num_cores) as executor:
        while True:
            future = executor.submit(
                generate_h160,
                int(str(uuid.uuid4().int)[12:]) % (end - start + 1) + start
                )
            dec, h160 = future.result()
            messages = []
            message = "[+] {}".format(dec)
            messages.append(message)
            output = "".join(messages) + "\r"
            sys.stdout.write(output)
            sys.stdout.flush()
            if h160 == "20d45a6a762535700ce9e0b216e31994335db8a5":
                print(dec)
                break

The uuid.uuid4() function in Python is very fast because it generates UUIDs (Universally Unique Identifiers) using a pseudo-random number generator (PRNG) and doesn't rely on external sources of entropy or randomness, such as system events or user input.
This makes it suitable for generating random UUIDs quickly.  It is not suitable for cryptographic purposes or when very high-quality randomness is required. It might not be the most conventional approach.

But who cares (what are you using) if you hacking cryptographic numbers ?

Instead of a conclusion:

puzzle 130 private key is even number    **************************************

[btc11235]

I managed to prove experimentally on 5 different computers that everything is in seed. You can speed up solving the puzzle by a million years if you know the correct seed. And the best thing is that you can always achieve the same result in the same time. Proof is in the pudding.

PC-1

• [Kangaroo]: Wed Oct 11 11:51:00 2023
• [Puzzle]: 50
• [Lower range limit]: 562949953421312
• [Upper range limit]: 1125899906842623
• [Xcoordinate]: f46f41027bbf44fafd6b059091b900dad41e6845b2241dc3254c7cdd3c5a16c6
• [Ycoordinate]: eb3dfcc04c320b55c529291478550be6072977c0c86603fb2e4f5283631064fb
• [Using  4 CPU cores for parallel search]:
• [Core]: 03, [Random seed]: b'\xbc\x9b\x8cd\xfc\xa1?\xcf'
• [Core]: 01, [Random seed]: b'\xbc\x9b\x8cd\xfc\xa1?\xcf'
• [Core]: 04, [Random seed]: b'\xbc\x9b\x8cd\xfc\xa1?\xcf'
• [Core]: 02, [Random seed]: b'\xbc\x9b\x8cd\xfc\xa1?\xcf'
• PUZZLE SOLVED: Wed Oct 11 11:51:18 2023, total time: 18.38 sec, Core: 04
• WIF:  -0000000000000000000000000000000000000000000000000022bd43c2e9354

--snip--

@nomachine after successfully proving to myself (I'm a bit behind the curve here) that anything I thought was a pattern/clue to solving this puzzle was just part of the maths inherent in the system, I'm now of the mind that this is correct... We can either try to brute-force the pkeys, and/or we can try to reverse-engineer (also by some amount of brute-force, I guess) and recreate the process by which the pkeys were created... Which is likely possible given that A) you appear to have done it at least once already for puzzle 50 above, and B) the person who claims to have created this said themselves that "It is just consecutive keys from a deterministic wallet"... That is, assuming the the words "consecutive" and "deterministic" apply accurately and weren't just used colloquially...

Anyway, I've looked through the code you posted (which I've snipped-out for brevity)... Is that python? I'm afraid IDK python... Which version are you using? 2.3 or newer, I assume? And can you explain more about what exactly is happening here:

Code:

#Random seed Config
#constant_prefix = b''  #back to no constant
#constant_prefix = b'\xbc\x9b\x8cd\xfc\xa1?\xcf' #Puzzle 50 seed - 10-18s
constant_prefix = b'\xbc\x9b\x8cd\xfc\xa1?\xcf'
prefix_length = len(constant_prefix)
length = 8
ending_length = length - prefix_length
with open("/dev/urandom", "rb") as urandom_file:
    ending_bytes = urandom_file.read(ending_length)
random_bytes = constant_prefix + ending_bytes
print(f"[+] [Core]: {core_number+1:02}, [Random seed]: {random_bytes}")
random.seed(random_bytes)

...it looks like you start with whatever this is, a hard-coded byte string or something?

Code:

b'\xbc\x9b\x8cd\xfc\xa1?\xcf'

...and then you go on to read more, random bytes from some file on disk? As a Windows/C# guy, I just can't quite grok what's happening here    Any help would be much appreciated 

[mcdouglasx]

As I see it, the most important part of the brute force that is missing is:
Quick database implementation.

assuming you want to find the public key of
1582856285957395958375836588

if you have the ability to store 10Mk and read them quickly.
You could then change G for 10000000
and subtract 10MK from the target and you would only have to scan
158285628595739595837

[nomachine]

can you explain more about what exactly is happening here:

Code:

#Random seed Config
#constant_prefix = b''  #back to no constant
#constant_prefix = b'\xbc\x9b\x8cd\xfc\xa1?\xcf' #Puzzle 50 seed - 10-18s
constant_prefix = b'\xbc\x9b\x8cd\xfc\xa1?\xcf'
prefix_length = len(constant_prefix)
length = 8
ending_length = length - prefix_length
with open("/dev/urandom", "rb") as urandom_file:
    ending_bytes = urandom_file.read(ending_length)
random_bytes = constant_prefix + ending_bytes
print(f"[+] [Core]: {core_number+1:02}, [Random seed]: {random_bytes}")
random.seed(random_bytes)

...it looks like you start with whatever this is, a hard-coded byte string or something?

Code:

b'\xbc\x9b\x8cd\xfc\xa1?\xcf'

...and then you go on to read more, random bytes from some file on disk? As a Windows/C# guy, I just can't quite grok what's happening here    Any help would be much appreciated  

It is a random seed for Puzzle 50 in kangaroo.

Code:

random_bytes = b'\xbc\x9b\x8cd\xfc\xa1?\xcf'

random.seed(random_bytes) is a function in Python (i use 3.9) used to initialize the random number generator with a specific seed value. In this context, random_bytes is typically a sequence of bytes or an integer used as the seed. When you provide a seed value to the random number generator, it ensures that the sequence of random numbers generated will be reproducible. In other words, if you use the same seed value, you will get the same sequence of random numbers every time you run kangaroo program.

Every time you request a random number using functions like random.randint(), random.random(), or others from the random module, it generates the next number in the sequence based on the seed value and an algorithm.

Because the generator is initialized with the same seed each time you run program, you get the same sequence of random numbers - same kangaroo jumps - and same time for solving Puzzle  

Theoretically, in the same way, every puzzle could be solved in 10-18 seconds if you know what a seed is.

The problem is how to reverse engineer a random seed for the private keys we don't have access to..

[digaran]

But try to generate 128bit number. You can't even do that with NumPy.  

Well, I wasn't aware of the fact that when you generate random keys you have to pay the price by computing units, now I see you want even a faster RNG than the one you posted a link to.
I don't know anything about RNG or seeds used to feed RNG, but it looks like a waste of time looking for a drop in an ocean, while there is a better way, to shatter the crust and let the ocean drain, meaning you should try to work out public keys.

As I see it, the most important part of the brute force that is missing is:
Quick database implementation.

assuming you want to find the public key of
1582856285957395958375836588

if you have the ability to store 10Mk and read them quickly.
You could then change G for 10000000
and subtract 10MK from the target and you would only have to scan
158285628595739595837

Something like this you mean :

Code:

75836588, 65836588, 55836588, 45836588, 35836588, 25836588, 15836588

Now we'd need to store 15, 836, 588 keys to look up.

[nomachine]

But try to generate 128bit number. You can't even do that with NumPy.  

Well, I wasn't aware of the fact that when you generate random keys you have to pay the price by computing units, now I see you want even a faster RNG than the one you posted a link to.

It does NOT have to be faster than that. Only if it works on 128bit.

[mcdouglasx]

As I see it, the most important part of the brute force that is missing is:
Quick database implementation.

assuming you want to find the public key of
1582856285957395958375836588

if you have the ability to store 10Mk and read them quickly.
You could then change G for 10000000
and subtract 10MK from the target and you would only have to scan
158285628595739595837

Something like this you mean :

Code:

75836588, 65836588, 55836588, 45836588, 35836588, 25836588, 15836588

Now we'd need to store 15, 836, 588 keys to look up.

data base

1582856285957395958375836588-1
1582856285957395958375836588-2
.....................................................
1582856285957395958375836588-10000000

one of those keys in the database will be like this:
1582856285957395958360000000

Therefore, changing G to 10000000, we would only have to scan this range:
158285628595739595836
Once you get a match you look for the rest of the key.
scanning 1582856285957395958360000000-1582856285957395958380000000 using the official G

[LuckyRandomFisher]

hallo!

posting an upd aftr ~1 week of ma full-time rndm-forcing #66

keyhunt is performing at ~160 Mkeys/s on my i9
./keyhunt -m address -f tests/66.txt -b 66 -l compress -R -q -s 1 -t 32 -e
PS i've made a mistake while polishing it last time that's why there were G/s

bitcrack is doing better at ~3517.68 MKey/s
./bin/cuBitCrack --keyspace 20000000000000000:3ffffffffffffffff -c 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so -o KEY_IS_HERE_OPEN_ME.txt -r -b 256 -t 256 -p 2096

scripts are slightly polished without touching algos, just some minor optimisation. it helped me to get a sense of the code as reading the code without changing it - bad digesting in the end of the day

just some ideas about algo thing, what if we go bannanna and ML sequences (bithex -> pubkey -> r160h) + (binary -> pubkey -> r160h) + different variations of data representations to find patterns and regularity. even patterns of probabilities could be a great source of clues for optimisations the random-forcing attack i strongly believe that there is a polynomial solution out there that our math guys didn't find it yet, so patterns might help) anyway it's fascinating. wha do u say?

P.S. and I think i need more gpus think about to rig +5 4090 to get ~20 Bkeys/s for my random-forcing fun will my chances go up a bit?

[Kamoheapohea]

This thread is so funny.
Some guys think they can bring up something better than the best mathematicians that dedicated most of their lives to this and similar problems.
E.g. https://en.wikipedia.org/wiki/John_Pollard_(mathematician)

You think you are smarter by doing your elementary school division?

[digaran]

This thread is so funny.
Some guys think they can bring up something better than the best mathematicians that dedicated most of their lives to this and similar problems.
E.g. https://en.wikipedia.org/wiki/John_Pollard_(mathematician)

You think you are smarter by doing your elementary school division?

Cool story bro! Where is this mathematician right now? Is he working on these puzzles? I wonder where are the BIG GUNS of mathematics, there are millions of $ for the grab, why don't they join the party?
I don't think the world knows about this puzzle, at least  they should spread the word so everyone can join, I mean come on, the most active member here is a notorious but harmless forum troll.
Maybe they are already working on this but silently? Well they should know that keeping knowledge to yourself won't give you more knowledge, that's why they won't get anything promising.😉

[WanderingPhilospher]

hallo!

posting an upd aftr ~1 week of ma full-time rndm-forcing #66

keyhunt is performing at ~160 Mkeys/s on my i9
./keyhunt -m address -f tests/66.txt -b 66 -l compress -R -q -s 1 -t 32 -e
PS i've made a mistake while polishing it last time that's why there were G/s

bitcrack is doing better at ~3517.68 MKey/s
./bin/cuBitCrack --keyspace 20000000000000000:3ffffffffffffffff -c 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so -o KEY_IS_HERE_OPEN_ME.txt -r -b 256 -t 256 -p 2096

scripts are slightly polished without touching algos, just some minor optimisation. it helped me to get a sense of the code as reading the code without changing it - bad digesting in the end of the day

just some ideas about algo thing, what if we go bannanna and ML sequences (bithex -> pubkey -> r160h) + (binary -> pubkey -> r160h) + different variations of data representations to find patterns and regularity. even patterns of probabilities could be a great source of clues for optimisations the random-forcing attack i strongly believe that there is a polynomial solution out there that our math guys didn't find it yet, so patterns might help) anyway it's fascinating. wha do u say?

P.S. and I think i need more gpus think about to rig +5 4090 to get ~20 Bkeys/s for my random-forcing fun will my chances go up a bit?

I'm not sure where to start. It looks like you are running keyhunt, CPU only, and comparing that to running a GPU on Bitcrack. Is that correct?

There is a keyhunt for GPU, which is better than bitcrack, speed wise, and for the fact that all GPUs can work together.

Yes, 5 GPUs bump your chances up, but why stop at 5? 

[Kamoheapohea]

Cool story bro! Where is this mathematician right now? Is he working on these puzzles? I wonder where are the BIG GUNS of mathematics, there are millions of $ for the grab, why don't they join the party?

It is so simple: They did not find something better so they stopped wasting their time. The secret is to know when you have to stop.
Noone here will find something better than BSGS, Pollard-*. I am 100% sure.

Prove me wrong .

[digaran]

Ok, since I just learned THE SECRET, I'm gonna continue as usual. 😉 because if you stop, you can never know what could have happened if you had continued to work harder.
So, does anyone here knows a way to always find 2 keys 1 being +n, the other 1 being -n without their last digit ever changing?
For example, if +n is 23785778 and -n is something like 678789915549,  do you know how to get 2 other keys ending with 8 and 9? And only by subtraction, not division.

Lets mind storm about this idea, and discuss how could knowing your target's last digit help in solving a key.

[WanderingPhilospher]

data base

1582856285957395958375836588-1
1582856285957395958375836588-2
.....................................................
1582856285957395958375836588-10000000

one of those keys in the database will be like this:
1582856285957395958360000000

Therefore, changing G to 10000000, we would only have to scan this range:
158285628595739595836
Once you get a match you look for the rest of the key.
scanning 1582856285957395958360000000-1582856285957395958380000000 using the official G

The problem with this, is that 1582856285957395958375836588 is such a small number in the scheme of what we are dealing with.

I have done something similar to speed up search times for a different project.

[Kamoheapohea]

Ok, since I just learned THE SECRET, I'm gonna continue as usual. 😉 because if you stop, you can never know what could have happened if you had continued to work harder.
So, does anyone here knows a way to always find 2 keys 1 being +n, the other 1 being -n without their last digit ever changing?
For example, if +n is 23785778 and -n is something like 678789915549,  do you know how to get 2 other keys ending with 8 and 9? And only by subtraction, not division.

Lets mind storm about this idea, and discuss how could knowing your target's last digit help in solving a key.

1 person claims to understand what you mean but you should write this in your personal diary instead of here.

[WanderingPhilospher]

Ok, since I just learned THE SECRET, I'm gonna continue as usual. 😉 because if you stop, you can never know what could have happened if you had continued to work harder.
So, does anyone here knows a way to always find 2 keys 1 being +n, the other 1 being -n without their last digit ever changing?
For example, if +n is 23785778 and -n is something like 678789915549,  do you know how to get 2 other keys ending with 8 and 9? And only by subtraction, not division.

Lets mind storm about this idea, and discuss how could knowing your target's last digit help in solving a key.

Sure, for the example you provided:

23785778
         -10
23785768

But none of this matters when you do not know the ending of the actual private key; nor does knowing the last digit of a private key help you in determining anything with regards to what a public key will look like when subtracting from it.

[nomachine]

E.g. https://en.wikipedia.org/wiki/John_Pollard_(mathematician)

You are right. To be more precise, we use the van Oorschot and Weiner Method of kangaroos.
The van Oorshot and Weiner method of was the fastest kangaroo method for
over 15 years. In this method, there is one ’Tame’ kangaroo (labelled T), and one ’Wild’
kangaroo (labelled W).
I don't even use files (for Tame & Wild) in my script. Everything happens in RAM. (with a bunch of caching and memoization)

Code:

    t = [
        mpz(
            lower_range_limit
            + mpz(random.randint(0, upper_range_limit - lower_range_limit))
        )
        for _ in range(Nt)
    ]
    T = [mulk(ti) for ti in t]
    dt = [mpz(0) for _ in range(Nt)]
    w = [
        mpz(random.randint(0, upper_range_limit - lower_range_limit)) for _ in range(Nw)
    ]
    W = [add_points(W0, mulk(wk)) for wk in w]
    dw = [mpz(0) for _ in range(Nw)]

    Hops, Hops_old = 0, 0

    oldtime = time.time()
    starttime = oldtime

    while True:
        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:
                STOP_EVENT.set()
                break
            t[k] = mpz(t[k]) + dt[k]  # Use mpz here
            T[k] = add_points(POINTS_TABLE[pw], T[k])

        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:
                STOP_EVENT.set()
                break
            w[k] = mpz(w[k]) + dw[k]  # Use mpz here
            W[k] = add_points(POINTS_TABLE[pw], W[k])

[Kamoheapohea]

You are right. To be more precise, we use the van Oorschot and Weiner Method of kangaroos.

I imagined if you use Gaudry Schost method (re-place a kangaroo at a new random point as soon as you hit a distinguished point) that you could have an advantage.
Especially when using tame points in the target bitrange and wild points where one or many might not be in the target bit-range (e.g. when having many targets while experimenting with division).

You would kind of saturate the tame DPs more and more while the chance to hit a DP with the wild range increases.

But today I don't think it is of much use.