lordfrs
Jr. Member
Offline
Activity: 56
Merit: 1
|
|
November 01, 2023, 10:31:03 AM |
|
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 **************************************
|
If you want to buy me a coffee
Btc = 3246y1G9YjnQQNRUrVMnaeCFrymZRgJAP7
Doge = DGNd8UTi8jVTVZ2twhKydyqicynbsERMjs
|
|
|
digaran
Copper Member
Hero Member
Offline
Activity: 1330
Merit: 899
🖤😏
|
|
November 01, 2023, 10:34:34 AM |
|
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
Member
Offline
Activity: 462
Merit: 24
|
|
November 01, 2023, 11:17:48 AM Last edit: November 01, 2023, 08:35:55 PM by 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/fastrandFast 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). 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 **************************************
|
bc1qdwnxr7s08xwelpjy3cc52rrxg63xsmagv50fa8
|
|
|
btc11235
Newbie
Offline
Activity: 7
Merit: 0
|
|
November 01, 2023, 03:44:29 PM |
|
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: #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? 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
Member
Offline
Activity: 305
Merit: 87
New ideas will be criticized and then admired.
|
|
November 01, 2023, 03:51:21 PM |
|
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
|
BTC bc1qxs47ttydl8tmdv8vtygp7dy76lvayz3r6rdahu
|
|
|
nomachine
Member
Offline
Activity: 462
Merit: 24
|
|
November 01, 2023, 04:01:57 PM Last edit: November 01, 2023, 04:52:50 PM by nomachine |
|
can you explain more about what exactly is happening here: #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? 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. 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..
|
bc1qdwnxr7s08xwelpjy3cc52rrxg63xsmagv50fa8
|
|
|
digaran
Copper Member
Hero Member
Offline
Activity: 1330
Merit: 899
🖤😏
|
|
November 01, 2023, 06:21:26 PM |
|
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 : 75836588, 65836588, 55836588, 45836588, 35836588, 25836588, 15836588 Now we'd need to store 15, 836, 588 keys to look up.
|
🖤😏
|
|
|
nomachine
Member
Offline
Activity: 462
Merit: 24
|
|
November 01, 2023, 06:28:17 PM |
|
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.
|
bc1qdwnxr7s08xwelpjy3cc52rrxg63xsmagv50fa8
|
|
|
mcdouglasx
Member
Offline
Activity: 305
Merit: 87
New ideas will be criticized and then admired.
|
|
November 01, 2023, 07:56:32 PM |
|
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 : 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
|
BTC bc1qxs47ttydl8tmdv8vtygp7dy76lvayz3r6rdahu
|
|
|
LuckyRandomFisher
Newbie
Offline
Activity: 3
Merit: 0
|
|
November 01, 2023, 11:03:12 PM |
|
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
Jr. Member
Offline
Activity: 40
Merit: 11
|
|
November 02, 2023, 02:45:15 AM |
|
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
Copper Member
Hero Member
Offline
Activity: 1330
Merit: 899
🖤😏
|
|
November 02, 2023, 03:08:42 AM |
|
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
Full Member
Offline
Activity: 1162
Merit: 237
Shooters Shoot...
|
|
November 02, 2023, 03:18:55 AM |
|
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
Jr. Member
Offline
Activity: 40
Merit: 11
|
|
November 02, 2023, 03:19:51 AM Last edit: November 02, 2023, 03:35:41 AM by 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
Copper Member
Hero Member
Offline
Activity: 1330
Merit: 899
🖤😏
|
|
November 02, 2023, 03:38:12 AM |
|
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
Full Member
Offline
Activity: 1162
Merit: 237
Shooters Shoot...
|
|
November 02, 2023, 03:41:17 AM |
|
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
Jr. Member
Offline
Activity: 40
Merit: 11
|
|
November 02, 2023, 03:44:27 AM |
|
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
Full Member
Offline
Activity: 1162
Merit: 237
Shooters Shoot...
|
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
Member
Offline
Activity: 462
Merit: 24
|
|
November 02, 2023, 04:01:31 AM Last edit: November 02, 2023, 04:24:42 AM by nomachine |
|
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) 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])
|
bc1qdwnxr7s08xwelpjy3cc52rrxg63xsmagv50fa8
|
|
|
Kamoheapohea
Jr. Member
Offline
Activity: 40
Merit: 11
|
|
November 02, 2023, 04:08:38 AM |
|
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.
|
|
|
|
|