kTimesG
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 116
Merit: 24
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 05, 2024, 03:33:23 PM |
|
You and I are probably talking about different things. I mean, it is extremely unlikely that among the remaining undisclosed keys there are patterns such as ffff or 8888 or more repetitions of the same digits. At the same time, I doubt that such combinations as, for example, c5ec5e or dd4dd4, etc., can be considered unlikely. Therefore, I think it is possible to discard numbers containing patterns of more than three identical digits. Without any calculations, I roughly assumed that there could not be more than 20% of such numbers in the range.
Sorry to ruin your intuition, but we were talking about the exact same thingThe effort to discard unlikely patterns is massively submined by the fact that such unlikely patterns are close to 0% of the total possible different patterns (e.g. the ones your mind sees as without a pattern). 42 is a totally random number, isn't it? Until you find a gazillion corelations, starting with the fact that it's now no longer random, because I mentioned it in this thread. What's the chance a key will contain c5ec5e? Lower now, because you mentioned it? This a classic fallacy. A random number generator does NOT care about any patterns, repetitions, weirdnesses of the human perception. Just because a found key doesn't contain a sequence of 30 consecutive same digits is not because it was impossible, it is because there's billions over billions of other possible combinations that had exactly the same equal chance of being selected by this thing called nature / reality. Repeat the experiment many billions times and it WILL appear. It can appear the first time or the Nth time, the chances are the same at any time... There are algorithms that are actually getting the uniform real randomness (not some deterministic PRNG bullshit like someone mentioned earlier, I mean really lol? Haven't they heard about os.urandom and how it works?) as a benefit to speed up results, not as something that cripples the search. So if you're working against randomness, it's a lost battle on all possible fronts. You need to embrace it instead.
|
|
|
|
k3ntINA
Newbie
Offline
Activity: 20
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 05, 2024, 06:33:12 PM |
|
Discovered keys up to number 65 in hex format without spaces and back to back. In the setting of 180 degrees and the distance between each character of 550, we see a special order. -Professors and elders of science, can we know the reason for this? -If these keys are random, why should this order occur? -Write a script that will give us the same output from the keys? Friends, the shape of a circle is not an omen, nor imagination, nor nonsense! The circle is mathematics. The formula in the formula... https://www.talkimg.com/images/2024/05/05/roBa2.gif
|
|
|
|
nomachine
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 396
Merit: 21
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 05, 2024, 06:33:21 PM Last edit: May 05, 2024, 09:57:46 PM by nomachine |
|
There are algorithms that are actually getting the uniform real randomness (not some deterministic PRNG bullshit like someone mentioned earlier, I mean really lol? Haven't they heard about os.urandom and how it works?)
import os, sys, random import time
min_range = 18446744073709551615 max_range = 36893488147419103231 counter = 0 # Initialize counter start_time = time.time()
while True: random_bytes = os.urandom(9) initial_bytes = b'\x00' * 23 full_bytes = initial_bytes + random_bytes dec = int.from_bytes(full_bytes, byteorder='big') counter += 1 # Increment counter message = "\rPrivate Keys per second: {:.2f}".format(counter / (time.time() - start_time)) messages = [] messages.append(message) output = "\033[01;33m" + ''.join(messages) + "\r" sys.stdout.write(output) sys.stdout.flush() if min_range <= dec <= max_range: if dec == 30568377312064202855: print("\nSeed :", random_bytes) print("Generated number:", dec) break
This is Python script that will test os.urandom speed. The example works for Puzzle 65. There is no hash or secp256k1 operations here - just numbers. Result is (on my PC) : Private Keys per second: 170893.39 Do you know how many numbers need to be generated per second to find Puzzle 65 in 10 minutes? 30744573456182586 Private Keys per second ! It's an mission impossible . Even in C++ We need Grey aliens hardware to solve this. From Zeta Reticuli ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
viljy
Legendary
Offline
Activity: 1848
Merit: 1063
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2024, 12:04:04 PM |
|
are close to 0% of the total possible different patterns
Interestingly, the content of such numbers increases with the growth and height of the range. ============================= RESTART: D:\NumHex.py ============================ In the range from 0x1000 to 0x2000, 1 hexadecimal numbers were found with repeating digits occurring four or more times in a row. This accounts for 0.02% of the total hexadecimal numbers in the range.
============================= RESTART: D:\NumHex.py ============================ In the range from 0x10000 to 0x20000, 32 hexadecimal numbers were found with repeating digits occurring four or more times in a row. This accounts for 0.05% of the total hexadecimal numbers in the range.
============================= RESTART: D:\NumHex.py ============================ In the range from 0x100000 to 0x200000, 737 hexadecimal numbers were found with repeating digits occurring four or more times in a row. This accounts for 0.07% of the total hexadecimal numbers in the range.
============================= RESTART: D:\NumHex.py ============================ In the range from 0x1000000 to 0x2000000, 15617 hexadecimal numbers were found with repeating digits occurring four or more times in a row. This accounts for 0.09% of the total hexadecimal numbers in the range.
============================= RESTART: D:\NumHex.py ============================ In the range from 0x10000000 to 0x20000000, 311282 hexadecimal numbers were found with repeating digits occurring four or more times in a row. This accounts for 0.12% of the total hexadecimal numbers in the range.
============================= RESTART: D:\NumHex.py ============================ In the range from 0x100000000 to 0x200000000, 5963072 hexadecimal numbers were found with repeating digits occurring four or more times in a row. This accounts for 0.14% of the total hexadecimal numbers in the range.
Anyone who wishes can calculate independently in the 130 range, but it will be a very long time: def count_repeated_digits_hex(start, end): count = 0 total_nums = int(end, 16) - int(start, 16) + 1
def has_repeated_digits(num_str): prev_digit = None consecutive_count = 0
for digit in num_str: if digit == prev_digit: consecutive_count += 1 else: consecutive_count = 1
if consecutive_count >= 4: return True
prev_digit = digit
return False
for num in range(int(start, 16), int(end, 16) + 1): num_str = hex(num)[2:] # Remove '0x' prefix if has_repeated_digits(num_str): count += 1
percentage = (count / total_nums) * 100
return count, percentage
start = "0x100000000" end = "0x200000000" result, percentage = count_repeated_digits_hex(start, end) print(f"In the range from {start} to {end}, {result} hexadecimal numbers were found with repeating digits occurring four or more times in a row.") print(f"This accounts for {percentage:.2f}% of the total hexadecimal numbers in the range.")
|
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
| ██▄▄██████████▄▄█████████ █▄██████████████▄████████ ███████▀▀▀▀███████▄▄▄▄███ █████████████████████████ █████████████████████████ ████████████▀▀▀▀▀████████ █████████████████████████ █████████████████████████ ████████████▄▄▄▄▄████████ █████████████████████████ █████████████████████████ ███████▄▄▄▄███████▀▀▀▀███ █▀██████████████▀████████ ██▀▀██████████▀▀█████████ | | | I © I |
|
|
|
albert0bsd
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2024, 12:25:59 PM |
|
Private Keys per second: 170893.39
Can you guys write a decent code atleast.... It's an mission impossible . Even in C++
I took that personal I write a C program to do the same tha your python script I get at least 100 times more numbers per second in a single thread in my laptop core i5 Total 639630811 numbers in 39 seconds: 16400790.000000 numbers/s Total 650116562 numbers in 40 seconds: 16252914.000000 numbers/s Total 671088064 numbers in 41 seconds: 16368001.000000 numbers/s Total 681573815 numbers in 42 seconds: 16227947.000000 numbers/s
I know it is still far away for the required number, but is 100x Times faster.... ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif)
|
|
|
|
citb0in
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2024, 01:18:00 PM |
|
Private Keys per second: 170893.39
Can you guys write a decent code atleast.... It's an mission impossible . Even in C++
I took that personal I write a C program to do the same tha your python script I get at least 100 times more numbers per second in a single thread in my laptop core i5 Total 639630811 numbers in 39 seconds: 16400790.000000 numbers/s Total 650116562 numbers in 40 seconds: 16252914.000000 numbers/s Total 671088064 numbers in 41 seconds: 16368001.000000 numbers/s Total 681573815 numbers in 42 seconds: 16227947.000000 numbers/s
I know it is still far away for the required number, but is 100x Times faster.... ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) I would have been very surprised if it had been the other way around ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) C is of course more performant and much more efficient in these computing areas. Python can hardly keep up.
|
|
|
|
albert0bsd
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2024, 01:27:48 PM |
|
I would have been very surprised if it had been the other way around ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) C is of course more performant and much more efficient in these computing areas. Python can hardly keep up. agree, on the other hand the only advantage of python is that is easy to use and easy to write it, there are external packages for almost everything. Any way guys good luck finding the puzzles, I am still here but focusing in another life projects and family.
|
|
|
|
citb0in
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2024, 01:36:49 PM |
|
Any way guys good luck finding the puzzles, I am still here but focusing in another life projects and family.
Dito! ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) there are more important things in my life, too. The BTC puzzle ist just 4 fun and education purposes. Nothing more
|
|
|
|
nomachine
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 396
Merit: 21
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2024, 01:55:40 PM Last edit: May 06, 2024, 02:23:47 PM by nomachine |
|
I know it is still far away for the required number, but is 100x Times faster.... ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) I have not tried the same script in C++ ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) I also deal with other things. More with hardware than software. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) p.s. i have almost the same result Total 653409355 numbers in 39 seconds: 16754086 numbers/s Total 670648654 numbers in 40 seconds: 16766216 numbers/s Total 687812315 numbers in 41 seconds: 16775910 numbers/s Total 705075122 numbers in 42 seconds: 16787502 numbers/s #include <iostream> #include <gmp.h> #include <gmpxx.h> #include <cstdlib> #include <ctime> #include <iomanip>
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; }
|
|
|
|
hongpeng945
Newbie
Offline
Activity: 1
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2024, 02:17:22 PM |
|
My answer was a general answer to a general question about the two forms of Bitcoin address and was not meant to be a technical paper or exact description of how to create Bitcoin addresses (that is what the wiki is for).
So, I started out with "Leaving out some small details:".
Thanks for filling in a few of the technical details.
Ok, but anyway I don't understand "257 bit", this value is not correct at all. Or 512 bit and 256 bit, or 8+512 bit and 8+256 bit. BTW, even with the additional details, the description is still incomplete because you left out the checksum in the hashing description.
No, the address in the blockchain's blocks (and in the UTXO data set) are stored exactly this way: ripemd160(sha256('02' or '03' + 'x'), 160 bit, no checksum, no base58 encode. Example: private key = 01 address = 91B24BF9F5288532960AC687ABB035127B1D28A5 (step 3, address for the blockchain) address = 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm (checksum + base58) (step 9, address for human people) Check with http://gobittest.appspot.com/Address or https://www.blockchain.com/it/btc/address/91B24BF9F5288532960AC687ABB035127B1D28A5Now if we look at a tx that funds the address 91B24BF9F5288532960AC687ABB035127B1D28A5 / 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm : https://www.blockchain.com/btc/tx/6797afc4d9b91fb9b283fedddec4e35b00d54063d73bb0d3e97f3537ed8fff3c?show_adv=trueoutput script: DUP HASH160 PUSHDATA(20)[ 91b24bf9f5288532960ac687abb035127b1d28a5] EQUALVERIFY CHECKSIG The address in the "1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm" format is only for human people. Hi, I have a question for you pls. Does it means that a miner could hack the bitcoins from who really worked out the puzzles? Because once he signed the transaction, the miners knows the public key and if they know this is for the puzzles, they can utilize your method to find corresponding private key and hacked the funds.
|
|
|
|
pbies
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2024, 03:59:35 PM |
|
Hi, I have a question for you pls. Does it means that a miner could hack the bitcoins from who really worked out the puzzles? Because once he signed the transaction, the miners knows the public key and if they know this is for the puzzles, they can utilize your method to find corresponding private key and hacked the funds.
For what all guys are saying here - seems like each and every random transaction should be possible to be stolen just knowing the public key. At any time when it is still in mempool. Not only puzzle addresses.
|
BTC: bc1qmrexlspd24kevspp42uvjg7sjwm8xcf9w86h5k
|
|
|
citb0in
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2024, 05:42:21 PM |
|
Hi, I have a question for you pls. Does it means that a miner could hack the bitcoins from who really worked out the puzzles? Because once he signed the transaction, the miners knows the public key and if they know this is for the puzzles, they can utilize your method to find corresponding private key and hacked the funds.
For what all guys are saying here - seems like each and every random transaction should be possible to be stolen just knowing the public key. At any time when it is still in mempool. Not only puzzle addresses. No, it isn't! Read carefully the details to understand. If you have further questions don't hesitate to put them. This is true only for low-bit ranges. Let's say I make an outgoing transaction from my own bitcoin address which I generated using a 256bit key. You will know the pubkey but you won't be able to bruteforce because you'll never survive it ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) But if I used a 66bit key then you can crack the privkey in less than 10 seconds.
|
|
|
|
kTimesG
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 116
Merit: 24
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 06, 2024, 11:19:52 PM |
|
are close to 0% of the total possible different patterns
Interestingly, the content of such numbers increases with the growth and height of the range. Anyone who wishes can calculate independently in the 130 range, but it will be a very long time: 1. Sounds normal, as you increase bit length each existing constraint gets factorized, and new ones also appear. Do you want to exclude 99.97% of the search space because they have 2 consecutive hex digits out of, let's say, 32 hex digits? Because that is where this series will end up. 2. It's computed wrong anyways. Something like 0x7f80 has 2 consecutive hex characters. And I didn't make a typo, maybe think about it in bits. Or should we only exclude byte-aligned bit patterns? See, any seemingly random string can be made into a pattern depending on how you look at it. Do you know how many numbers need to be generated per second to find Puzzle 65 in 10 minutes?
It's an mission impossible . Even in C++
It is very funny that you fell into the same trap as everyone else. Here's the reality: /dev/urandom is not a secure random number generator. It falls back to a PRNG when too much data gets read from it.
|
|
|
|
nomachine
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 396
Merit: 21
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2024, 03:50:38 AM Last edit: May 07, 2024, 05:03:19 AM by nomachine |
|
Here's the reality: /dev/urandom is not a secure random number generator.
What kind of security are you talking about when we a brute-force BTC here? I want to crack the random number generator not to improve it ! ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) To break down random.seed. Here is example: import random import os import time import secp256k1 as ice
puzzle = 30 target = "d39c4704664e1deb76c9331e637564c257d68a08" lower_range_limit = 2 ** (puzzle - 1) upper_range_limit = (2 ** puzzle) - 1
start_time = time.time()
for x in range(10000000): #Random seed Config #constant_prefix = b'' #back to no constant constant_prefix = b'yx\xcb\x08\xb70l' prefix_length = len(constant_prefix) length = 8 ending_length = length - prefix_length ending_bytes = os.urandom(ending_length) random_bytes = constant_prefix + ending_bytes random.seed(random_bytes) dec = random.randint(lower_range_limit, upper_range_limit) h160 = ice.privatekey_to_h160(0, True, dec).hex() if h160 == target: HEX = "%064x" % dec caddr = ice.privatekey_to_address(0, True, dec) wifc = ice.btc_pvk_to_wif(HEX) print("Bitcoin address Compressed: " + caddr) print("Private Key (decimal): " + str(dec)) print("Private key (wif) Compressed : " + wifc) print(f"Random seed: {random_bytes}") break
end_time = time.time() execution_time_ms = (end_time - start_time) * 1000
print("Execution Time (ms):", execution_time_ms) This is a millisecond puzzle 30 solver. Bitcoin address Compressed: 1LHtnpd8nU5VHEMkG2TMYYNUjjLc992bps Private Key (decimal): 1033162084 Private key (wif) Compressed : KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M8diLSC5MyERoW Random seed: b'yx\xcb\x08\xb70l\xf1' Execution Time (ms): 2.8727054595947266
|
|
|
|
k3ntINA
Newbie
Offline
Activity: 20
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2024, 04:52:37 AM Last edit: May 07, 2024, 08:52:27 PM by Mr. Big |
|
1 3 7 8 21 49 76 224 467 514 1155 2683 5216 10544 26867 51510 95823 198669 357535 863317 1811764 3007503 5598802 14428676 33185509 54538862 111949941 227634408 400708894 1033162084 2102388551 3093472814 7137437912 14133072157 20112871792 42387769980 100251560595 146971536592 323724968937 1003651412950 1458252205147 2895374552463 7409811047825 15404761757071 19996463086597 51408670348612 119666659114170 191206974700443 409118905032525 611140496167764 2058769515153876 4216495639600700 6763683971478124 9974455244496707 30045390491869460 44218742292676575 138245758910846492 199976667976342049 525070384258266191 1135041350219496382 1425787542618654982 3908372542507822062 8993229949524469768 17799667357578236628 30568377312064202855 ******************** ********************* ********************* ********************* 970436974005023690481
1 3 7 8 15 31 4C E0 1D3 202 483 A7B 1460 2930 68F3 C936 1764F 3080D 5749F D2C55 1BA534 2DE40F 556E52 DC2A04 1FA5EE5 340326E 6AC3875 D916CE8 17E2551E 3D94CD64 7D4FE747 B862A62E 1A96CA8D8 34A65911D 4AED21170 9DE820A7C 1757756A93 22382FACD0 4B5F8303E9 E9AE4933D6 153869ACC5B 2A221C58D8F 6BD3B27C591 E02B35A358F 122FCA143C05 2EC18388D544 6CD610B53CBA ADE6D7CE3B9B 174176B015F4D 22BD43C2E9354 75070A1A009D4 EFAE164CB9E3C 180788E47E326C 236FB6D5AD1F43 6ABE1F9B67E114 9D18B63AC4FFDF 1EB25C90795D61C 2C675B852189A21 7496CBB87CAB44F FC07A1825367BBE 13C96A3742F64906 363D541EB611ABEE 7CCE5EFDACCF6808 F7051F27B09112D4 1A838B13505B26867
|
|
|
|
kTimesG
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 116
Merit: 24
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2024, 10:57:28 AM Last edit: May 07, 2024, 11:41:55 AM by kTimesG |
|
1 3 7 8 15 31 4C E0 // rest of crap
Do you honestly want someone to waste their time explaining to you again how (hexa)decimal numbers work, and why they start with either a 1 2 3 6 7 .. E F (hint: the Nth left-most bit in any solution in range N is always 1, so the first digit in any base you'd use is biased)) and so on and why they magically get aligned in your horoscope circle (another hint: every solution is 1 bit longer than the previous one) Send me 0.1 BTC and I will happily waste 6h explaining to you in detail (a 2nd time) why those arms get aligned in your circle and why you see those patterns. But you refuse to want to understand that there's nothing magical or unexpected in what you are doing there. You're the kid playing in the sand while the teenagers are trying to break down the building using resonance pulse generators. The adults are laughing their ass off watching us and don't even bother while waiting for the quantum bulldozer to arrive. What kind of security are you talking about when we a brute-force BTC here? I want to crack the random number generator not to improve it ! ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) You only do around 128 loops on average, 2 milliseconds is very slow in this case. A regular single threaded C code can do around 20000 EC point additions in the same amount of time, and find any 30-bit private key. We need to know - what OS the creator was using in 2015 (break down kernel's code, emulate it) - the code he used, search for vulnerabilities in it - exact entropy state at the moment the presumed RNG was initialized and at every step of getting a next value For example /dev/urandom reseeds itself from new entropy every now and then, that's yet another issue after potentially cracking its previous state somehow. I doubt the creator blindly used some simple deterministic 32-bit RNG such as the textbook merseinne twister one in the lowest level libc of the OS. Or that the higher level framework (deterministic wallet?) did such a nooby mistake as well.
|
|
|
|
Tepan
Jr. Member
Offline
Activity: 49
Merit: 1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2024, 12:53:58 PM |
|
There are algorithms that are actually getting the uniform real randomness (not some deterministic PRNG bullshit like someone mentioned earlier, I mean really lol? Haven't they heard about os.urandom and how it works?)
import os, sys, random import time
min_range = 18446744073709551615 max_range = 36893488147419103231 counter = 0 # Initialize counter start_time = time.time()
while True: random_bytes = os.urandom(9) initial_bytes = b'\x00' * 23 full_bytes = initial_bytes + random_bytes dec = int.from_bytes(full_bytes, byteorder='big') counter += 1 # Increment counter message = "\rPrivate Keys per second: {:.2f}".format(counter / (time.time() - start_time)) messages = [] messages.append(message) output = "\033[01;33m" + ''.join(messages) + "\r" sys.stdout.write(output) sys.stdout.flush() if min_range <= dec <= max_range: if dec == 30568377312064202855: print("\nSeed :", random_bytes) print("Generated number:", dec) break
This is Python script that will test os.urandom speed. The example works for Puzzle 65. There is no hash or secp256k1 operations here - just numbers. Result is (on my PC) : Private Keys per second: 170893.39 Do you know how many numbers need to be generated per second to find Puzzle 65 in 10 minutes? 30744573456182586 Private Keys per second ! It's an mission impossible . Even in C++ We need Grey aliens hardware to solve this. From Zeta Reticuli ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) Experiments with your python codes on rust language use std::time::{Instant, Duration}; use std::io::{self, Write}; const UPDATE_INTERVAL: u64 = 1000000; // Update progress every 1 million iterations fn main() { // Input minimum and maximum ranges in hexadecimal format let min_range_hex = "100000000"; let max_range_hex = "1ffffffff"; // Convert hexadecimal strings to u128 values let min_range: u128 = u128::from_str_radix(min_range_hex, 16).unwrap(); let max_range: u128 = u128::from_str_radix(max_range_hex, 16).unwrap(); let start_time = Instant::now(); let mut counter = 0u64; let stdout = io::stdout(); let mut handle = stdout.lock(); for num in min_range..=max_range { counter += 1; if counter % UPDATE_INTERVAL == 0 || num == max_range { print_progress(&mut handle, num, counter, start_time.elapsed()); } // Break the loop if the generated number matches a specific value if num == 0x1a96ca8d8 { writeln!(&mut handle, "\nGenerated number (decimal): {}", num).unwrap(); break; } } } // Function to print progress to stdout fn print_progress(handle: &mut io::StdoutLock, num: u128, counter: u64, elapsed_time: Duration) { let private_keys_per_second = counter as f64 / elapsed_time.as_secs_f64(); let hex_representation = format!("{:#X}", num); // Move cursor to the beginning of the line and clear it print!("\r\x1B[K"); // Write the output to stdout in a single line print!("{} | {:.2} keys/s", hex_representation, private_keys_per_second); handle.flush().unwrap(); } Result0x1A96CA8D8 | 82762283.93 keys/s Generated number (decimal): 7137437912single thread, M2 Proc.
|
|
|
|
mochi86_
Newbie
Offline
Activity: 24
Merit: 3
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 07, 2024, 03:31:46 PM |
|
I'm getting brainrot trying to understand this conspiracy theorist LMFAO
Rotating the keys in a circle ain't gonna do crap, that's simply not how it works. If this "theory" were to be even the slightest bit true, why haven't you solved anything with it? Why keep trying to persuade the rest who hardly believe by presenting the same dam spiral-y weird thing and say "CoInCiDeNcE? I tHiNk NoT!!"?
If you think your "theory" is worth the time, waste your own time trying to use your "theory" and see where it takes you cuz clearly, everyone else believes you're just a delusional guy. Wanna prove them wrong? Then do something with it, solve a puzzle with it or something. Show the evidence it works to solve anything. Otherwise, you really are just wasting time yapping and yapping about something that never was.
|
|
|
|
|
Tepan
Jr. Member
Offline
Activity: 49
Merit: 1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
May 08, 2024, 06:36:17 AM |
|
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.
|
|
|
|
|