bestie1549
Jr. Member
Offline
Activity: 75
Merit: 5
|
|
September 30, 2023, 02:33:04 PM |
|
Based on the information provided, it appears that the pattern for generating the private key (PVK) values for these Bitcoin addresses involves incrementing the PVK values by a specific sequence of integers. Let's calculate the PVK value for Address 15 and beyond based on the observed pattern:
Address 15: PVK value = Address 14's PVK value + 27 Address 15: PVK value = 10544 + 27 Address 15: PVK value = 10571
So, the PVK value for Address 15 is 10571.
You can continue this pattern to calculate the PVK values for addresses beyond Address 15 by adding the next integer in the sequence to the PVK value of the previous address.
What is for 66 then ? I can even help you further how to program this import math # Given list of numbers numbers = [ 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 ] Give me math formula that can calculate pattern for WIF 66 here ? Whoever succeeds in doing this will receive a greater prize than the Nobel Prize. p.s. It doesn't even have to be an exact number. That it is accurate to approximately +/- 8 decimal places. you must be a very big joker if you think there is a pattern in the numbers you see up there, the only pattern you can ever find is the puzzle numbers 1 to 65, anything apart from that then you must be joking. if you like turn it to ASCII or WIF or HEX or DEC or Base 9 or Base 2 or any format you want. a Random number will forever remain a random number the only problem we are having here is the fact that we cannot generate a defined public key range (e.g 66 bit range public keys) without having to involve the private key. what would be the usage of the curve if we could do that then?
|
|
|
|
nomachine
Member
Offline
Activity: 392
Merit: 21
|
|
September 30, 2023, 03:06:18 PM |
|
Based on the information provided, it appears that the pattern for generating the private key (PVK) values for these Bitcoin addresses involves incrementing the PVK values by a specific sequence of integers. Let's calculate the PVK value for Address 15 and beyond based on the observed pattern:
Address 15: PVK value = Address 14's PVK value + 27 Address 15: PVK value = 10544 + 27 Address 15: PVK value = 10571
So, the PVK value for Address 15 is 10571.
You can continue this pattern to calculate the PVK values for addresses beyond Address 15 by adding the next integer in the sequence to the PVK value of the previous address.
What is for 66 then ? I can even help you further how to program this import math # Given list of numbers numbers = [ 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 ] Give me math formula that can calculate pattern for WIF 66 here ? Whoever succeeds in doing this will receive a greater prize than the Nobel Prize. p.s. It doesn't even have to be an exact number. That it is accurate to approximately +/- 8 decimal places. you must be a very big joker if you think there is a pattern in the numbers you see up there Tell that to him.
|
|
|
|
unclevito
Jr. Member
Offline
Activity: 74
Merit: 4
|
|
September 30, 2023, 03:43:29 PM Last edit: September 30, 2023, 11:31:53 PM by unclevito |
|
Based on the information provided, it appears that the pattern for generating the private key (PVK) values for these Bitcoin addresses involves incrementing the PVK values by a specific sequence of integers. Let's calculate the PVK value for Address 15 and beyond based on the observed pattern:
Address 15: PVK value = Address 14's PVK value + 27 Address 15: PVK value = 10544 + 27 Address 15: PVK value = 10571
So, the PVK value for Address 15 is 10571.
You can continue this pattern to calculate the PVK values for addresses beyond Address 15 by adding the next integer in the sequence to the PVK value of the previous address.
What is for 66 then ? I can even help you further how to program this import math # Given list of numbers numbers = [ 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 ] Give me math formula that can calculate pattern for WIF 66 here ? Whoever succeeds in doing this will receive a greater prize than the Nobel Prize. p.s. It doesn't even have to be an exact number. That it is accurate to approximately +/- 8 decimal places. you must be a very big joker if you think there is a pattern in the numbers you see up there Tell that to him. somewhat of a visual pattern, but reminds me of random noise in a AM radio IF too. [1.0986122886681098, 0.8472978603872034, 0.13353139262452252, 0.9650808960435873, 0.8472978603872034, 0.4389130421757046, 1.0809127115687085, 0.7346832058138579, 0.095894007786268, 0.8096323575007283, 0.8428352274697302, 0.6647952531808645, 0.7038261531358003, 0.9353417899552472, 0.6508771958620958, 0.6207267760911943, 0.7291373836260231, 0.5875931361451538, 0.8815486874877241, 0.7412742883673946, 0.5068092100595862, 0.621442479911261, 0.9466649690007394, 0.8328956894510604, 0.4968002070443873, 0.7191383042437529, 0.7096890523067678, 0.565494345222092, 0.9471441493574098, 0.7104500196844334, 0.3862202442339999, 0.8360595282539585, 0.6831637178413494, 0.3528424038245319, 0.7454998789960143, 0.8608227563358781, 0.38255630630651183, 0.7896553545955527, 1.1315057477074362, 0.37359383611238073, 0.6858758829076486, 0.9396904576187914, 0.7318717272660606, 0.26087874561462243, 0.9442514298159388, 0.8449031946466405, 0.46864644180339354, 0.7606493566316814, 0.4013210422240192, 1.2145368832080123, 0.7168958843120095, 0.47256334190535654, 0.38845964139438394, 1.1026819053976311, 0.38643947837596926, 1.1398842299982945, 0.3691677366484285, 0.9653316192351014, 0.7708920423038066, 0.22805524036508018, 1.0083967352657979, 0.8333510086282203, 0.682707702906626, 0.540786284089215]
|
|
|
|
Baskentliia
Jr. Member
Offline
Activity: 60
Merit: 1
34Sf4DnMt3z6XKKoWmZRw2nGyfGkDgNJZZ
|
|
September 30, 2023, 07:14:18 PM |
|
Hi all,
to what extent can the performance and the hit probability of these two tools be compared and what significance do they then have?
For example:
- we run Kangaroo in multi-GPU mode on several modern GPUs and achieve a displayed speed of 15 GKey/s
- we run keyhunt in BSGS mode on 8 CPU threads with about 16GB RAM allocation and get about 80 PKey/s.
Is Kangaroo with multi-GPU usage more advantageous and more likely to get a hit, even though keyhunt with CPU usage in BSGS can process 80 PKey/s?
From this numerical example, one would think that keyhunt with the 80 PKey/s would have to be worlds better. But is that the case or is it not possible to compare this at all and the given speed rates are completely useless for the comparison?
|
34Sf4DnMt3z6XKKoWmZRw2nGyfGkDgNJZZ
|
|
|
citb0in
|
|
September 30, 2023, 07:24:37 PM |
|
From this numerical example, one would think that keyhunt with the 80 PKey/s would have to be worlds better. But is that the case ... ?
No. ... or is it not possible to compare this at all and the given speed rates are completely useless for the comparison?
Correct. You cannot compare the performance rate displayed by those two programs as they heavily differ.
|
|
|
|
mcdouglasx
Member
Offline
Activity: 245
Merit: 53
New ideas will be criticized and then admired.
|
|
September 30, 2023, 10:33:47 PM |
|
Hi all,
to what extent can the performance and the hit probability of these two tools be compared and what significance do they then have?
For example:
- we run Kangaroo in multi-GPU mode on several modern GPUs and achieve a displayed speed of 15 GKey/s
- we run keyhunt in BSGS mode on 8 CPU threads with about 16GB RAM allocation and get about 80 PKey/s.
Is Kangaroo with multi-GPU usage more advantageous and more likely to get a hit, even though keyhunt with CPU usage in BSGS can process 80 PKey/s?
From this numerical example, one would think that keyhunt with the 80 PKey/s would have to be worlds better. But is that the case or is it not possible to compare this at all and the given speed rates are completely useless for the comparison?
through the scientific method. Test different keys in different ranges, x number of times, and you will know which method finds those keys faster and under what circumstances.
|
I'm not dead, long story... BTC bc1qxs47ttydl8tmdv8vtygp7dy76lvayz3r6rdahu
|
|
|
bestie1549
Jr. Member
Offline
Activity: 75
Merit: 5
|
|
October 01, 2023, 07:37:09 AM |
|
Hi all,
to what extent can the performance and the hit probability of these two tools be compared and what significance do they then have?
For example:
- we run Kangaroo in multi-GPU mode on several modern GPUs and achieve a displayed speed of 15 GKey/s
- we run keyhunt in BSGS mode on 8 CPU threads with about 16GB RAM allocation and get about 80 PKey/s.
Is Kangaroo with multi-GPU usage more advantageous and more likely to get a hit, even though keyhunt with CPU usage in BSGS can process 80 PKey/s?
From this numerical example, one would think that keyhunt with the 80 PKey/s would have to be worlds better. But is that the case or is it not possible to compare this at all and the given speed rates are completely useless for the comparison?
the easiest example I can give to you for this question is a "web" and a "gunshot" now picture both having the same momentum Kangaroo would be considered a "web" moving at the same momentum as the "gunshot" from BSGS and what do webs do? it spreads, covering so much area and what do gunshots do? it moves on a straight line Now the preference is you choice and your available resources they're both super fast like I've explained earlier. let's say you have a single 4090 and 16 cpu threads and you combined both and you got the speed of 5GKey/s and you choose not to use the 4090 but you rather use the 16 cpu thread on your machine and you have 128GB RAM and you chose -k 7000 and you achieved the speed of 1 EKey/s you got so much momentum on both processes but based on my calculations, you would be 90% slower using the latter compared to the former because they are both having ETAs which can easily be calculated Mind you this has nothing to do with what I am saying, it has everything to do with your preference and resources
|
|
|
|
BarryWood
Newbie
Offline
Activity: 4
Merit: 0
|
|
October 01, 2023, 04:56:14 PM |
|
Hey all, correct me if I'm wrong please: Since the rewards got multiplied by 10X nothing has been found! Correct?
|
|
|
|
mcdouglasx
Member
Offline
Activity: 245
Merit: 53
New ideas will be criticized and then admired.
|
|
October 01, 2023, 07:47:08 PM Merited by albert0bsd (1) |
|
Hey all, correct me if I'm wrong please: Since the rewards got multiplied by 10X nothing has been found! Correct?
only #125
|
I'm not dead, long story... BTC bc1qxs47ttydl8tmdv8vtygp7dy76lvayz3r6rdahu
|
|
|
nomachine
Member
Offline
Activity: 392
Merit: 21
|
|
October 02, 2023, 02:49:17 PM Last edit: October 02, 2023, 03:06:01 PM by nomachine |
|
- we run keyhunt in BSGS mode on 8 CPU threads with about 16GB RAM allocation and get about 80 PKey/s.
Is Kangaroo with multi-GPU usage more advantageous and more likely to get a hit, even though keyhunt with CPU usage in BSGS can process 80 PKey/s?
Try changing the random generator in both. Play what works best in your environment. example keyhunt.cpp replace to replace seed random generator with minstd_rand rng #if defined(_WIN64) && !defined(__CYGWIN__) // Any Windows secure random source goes here rseed(clock() + time(NULL) + rand()); #else std::random_device rd; std::minstd_rand rng(rd()); // Seed the random number generator rseed(rng()); #endif I have from 80 to ~177 Pkeys/s (177940438134284990 keys/s) These apps can't get better if we don't all work on them and test them.
|
|
|
|
WanderingPhilospher
Full Member
Offline
Activity: 1120
Merit: 234
Shooters Shoot...
|
|
October 02, 2023, 06:08:05 PM |
|
Alek, for the win. Long time no hear/see. Glad you’ve made it back.
What does your new program do exactly? The VanitySearch one.
Myself, no one wanted to combine forces to attack 130, so I’ve just been tinkering on different things. Nothing new, not any closer than I was months ago.
|
|
|
|
Kostelooscoin
Member
Offline
Activity: 205
Merit: 16
|
|
October 02, 2023, 06:32:13 PM |
|
- we run keyhunt in BSGS mode on 8 CPU threads with about 16GB RAM allocation and get about 80 PKey/s.
Is Kangaroo with multi-GPU usage more advantageous and more likely to get a hit, even though keyhunt with CPU usage in BSGS can process 80 PKey/s?
Try changing the random generator in both. Play what works best in your environment. example keyhunt.cpp replace to replace seed random generator with minstd_rand rng #if defined(_WIN64) && !defined(__CYGWIN__) // Any Windows secure random source goes here rseed(clock() + time(NULL) + rand()); #else std::random_device rd; std::minstd_rand rng(rd()); // Seed the random number generator rseed(rng()); #endif I have from 80 to ~177 Pkeys/s (177940438134284990 keys/s) These apps can't get better if we don't all work on them and test them. An windows version ?
|
|
|
|
nomachine
Member
Offline
Activity: 392
Merit: 21
|
|
October 02, 2023, 07:51:40 PM |
|
- we run keyhunt in BSGS mode on 8 CPU threads with about 16GB RAM allocation and get about 80 PKey/s.
Is Kangaroo with multi-GPU usage more advantageous and more likely to get a hit, even though keyhunt with CPU usage in BSGS can process 80 PKey/s?
Try changing the random generator in both. Play what works best in your environment. example keyhunt.cpp replace to replace seed random generator with minstd_rand rng #if defined(_WIN64) && !defined(__CYGWIN__) // Any Windows secure random source goes here rseed(clock() + time(NULL) + rand()); #else std::random_device rd; std::minstd_rand rng(rd()); // Seed the random number generator rseed(rng()); #endif I have from 80 to ~177 Pkeys/s (177940438134284990 keys/s) These apps can't get better if we don't all work on them and test them. An windows version ? #if defined(_WIN64) && !defined(__CYGWIN__) // On Windows, use a combination of clock, time, and rand as the seed return std::minstd_rand(static_cast<unsigned>(clock() + time(nullptr) + rand())); #else // On non-Windows platforms (including Linux), use std::random_device to seed std::random_device rd; return std::minstd_rand(rd()); This code should work on both Windows and Linux. I also use -O3 flag during compilation. Aggressive optimizations can greatly improve performance, they may also increase compilation time, and in some cases, they can make debugging more challenging because the optimized code may differ significantly from the original source code.
|
|
|
|
albert0bsd
|
|
October 02, 2023, 08:47:07 PM |
|
@nomachine what is the problem with the original code? if a non-deterministic source (e.g. a hardware device) is not available to the implementation. In this case each std::random_device object may generate the same number sequence.
For Linux the best source of entropy is the internal RNG. I strongly advice not use that code provide by @nomachine if you are using the program to generate your vanity addresses.If the code is not going to be used for that and you are pretty sure that your machine have a RNG Hardware device the it is ok to use it
|
|
|
|
digaran
Copper Member
Hero Member
Offline
Activity: 1330
Merit: 899
🖤😏
|
|
October 03, 2023, 12:22:21 AM |
|
WP, for the android, no lung no ear, glad you made it back from where ever you were. Lol.
Ahhh, Joes? Jules? Sup. Try this, I just messed up when trying to divide each target by different scalar, so I can't tell whether this is dividing 1 target by odd and the other target by even values or not, if you could try it with scalar mod n instead of points, do try and also share it with us, I have no time to do it right now. import gmpy2 as mpz from gmpy2 import powmod
# Define the EllipticCurve class class EllipticCurve: def __init__(self, a, b, p): self.a = mpz.mpz(a) self.b = mpz.mpz(b) self.p = mpz.mpz(p)
def contains(self, point): x, y = point.x, point.y return (y * y) % self.p == (x * x * x + self.a * x + self.b) % self.p
def __str__(self): return f"y^2 = x^3 + {self.a}x + {self.b} mod {self.p}"
# Define the Point class class Point: def __init__(self, x, y, curve): self.x = mpz.mpz(x) self.y = mpz.mpz(y) self.curve = curve
def __eq__(self, other): return self.x == other.x and self.y == other.y and self.curve == other.curve
def __ne__(self, other): return not self == other
def __add__(self, other): if self.curve != other.curve: raise ValueError("Cannot add points on different curves")
# Case when one point is zero if self == Point.infinity(self.curve): return other if other == Point.infinity(self.curve): return self
if self.x == other.x and self.y != other.y: return Point.infinity(self.curve)
p = self.curve.p s = 0 if self == other: s = ((3 * self.x * self.x + self.curve.a) * powmod(2 * self.y, -1, p)) % p else: s = ((other.y - self.y) * powmod(other.x - self.x, -1, p)) % p
x = (s * s - self.x - other.x) % p y = (s * (self.x - x) - self.y) % p
return Point(x, y, self.curve)
def __sub__(self, other): if self.curve != other.curve: raise ValueError("Cannot subtract points on different curves")
# Case when one point is zero if self == Point.infinity(self.curve): return other if other == Point.infinity(self.curve): return self
return self + Point(other.x, (-other.y) % self.curve.p, self.curve)
def __mul__(self, n): if not isinstance(n, int): raise ValueError("Multiplication is defined for integers only")
n = n % (self.curve.p - 1) res = Point.infinity(self.curve) addend = self
while n: if n & 1: res += addend
addend += addend n >>= 1
return res
def __str__(self): return f"({self.x}, {self.y}) on {self.curve}"
@staticmethod def from_hex(s, curve): if len(s) == 66 and s.startswith("02") or s.startswith("03"): compressed = True elif len(s) == 130 and s.startswith("04"): compressed = False else: raise ValueError("Hex string is not a valid compressed or uncompressed point")
if compressed: is_odd = s.startswith("03") x = mpz.mpz(s[2:], 16)
# Calculate y-coordinate from x and parity bit y_square = (x * x * x + curve.a * x + curve.b) % curve.p y = powmod(y_square, (curve.p + 1) // 4, curve.p) if is_odd != (y & 1): y = -y % curve.p
return Point(x, y, curve) else: s_bytes = bytes.fromhex(s) uncompressed = s_bytes[0] == 4 if not uncompressed: raise ValueError("Only uncompressed or compressed points are supported")
num_bytes = len(s_bytes) // 2 x_bytes = s_bytes[1 : num_bytes + 1] y_bytes = s_bytes[num_bytes + 1 :]
x = mpz.mpz(int.from_bytes(x_bytes, byteorder="big")) y = mpz.mpz(int.from_bytes(y_bytes, byteorder="big"))
return Point(x, y, curve)
def to_hex(self, compressed=True): if self.x is None and self.y is None: return "00" elif compressed: prefix = "03" if self.y & 1 else "02" return prefix + hex(self.x)[2:].zfill(64) else: x_hex = hex(self.x)[2:].zfill(64) y_hex = hex(self.y)[2:].zfill(64) return "04" + x_hex + y_hex
@staticmethod def infinity(curve): return Point(-1, -1, curve)
# Define the ec_mul function def ec_mul(point, scalar, base_point): result = Point.infinity(point.curve) addend = point
while scalar: if scalar & 1: result += addend
addend += addend scalar >>= 1
return result
# Define the ec_operations function def ec_operations(start_range, end_range, target_1, target_2, curve, divide_1_by_odd=True, divide_1_by_even=True, divide_2_by_odd=True, divide_2_by_even=True): # Define parameters for secp256k1 curve n = mpz.mpz("0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141") G = Point( mpz.mpz("0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798"), mpz.mpz("0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8"), curve )
for i in range(start_range + (start_range%2), end_range, 3): # divide target 1 by odd or even numbers if i%2 == 0 and not divide_1_by_even: continue elif i%2 == 1 and not divide_1_by_odd: continue try: # calculate inverse modulo of i i_inv = powmod(i, n-2, n)
# divide the targets by i modulo n result_1 = ec_mul(target_1, i_inv, G) result_2 = ec_mul(target_2, i_inv, G)
# divide target 2 by odd or even numbers if i%2 == 0 and not divide_2_by_even: continue elif i%2 == 1 and not divide_2_by_odd: continue
# subtract the results sub_result = result_2 - result_1
# write the results to separate files print(f"{i}-{sub_result.to_hex()}")
except ZeroDivisionError: pass
if __name__ == "__main__": # Set the targets and range for the operations curve = EllipticCurve( mpz.mpz(0), mpz.mpz(7), mpz.mpz("0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F") )
target_1 = Point.from_hex("037564539e85d56f8537d6619e1f5c5aa78d2a3de0889d1d4ee8dbcb5729b62026", curve)
target_2 = Point.from_hex("03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852", curve) start_range = 0 end_range = 256 ec_operations(start_range, end_range, target_2, target_1, curve) Haters gonna keep hatin', bitches gonna keep bitchin. Beware of the old lady ahead, her whining kills.😉
|
🖤😏
|
|
|
nomachine
Member
Offline
Activity: 392
Merit: 21
|
|
October 03, 2023, 06:09:55 AM |
|
@nomachine what is the problem with the original code? if a non-deterministic source (e.g. a hardware device) is not available to the implementation. In this case each std::random_device object may generate the same number sequence.
Everything is great with the code. Even std::random_device works great for me. I am experimenting with different generators and speeds. It's not even an ordinary platform. I'm currently on an ARM machine.
There is no pattern here. But there is a time when a puzzle was created. I even went back in time and generating numbers from 2015. Every second of that year. add = "13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so" # Specify the start date and time start_datetime = datetime(2015, 1, 13, 19, 7, 14) current_datetime = start_datetime
# Specify the end date and time end_datetime = datetime(2015, 1, 15, 19, 7, 14)
while current_datetime <= end_datetime: # Convert the current datetime to a Unix timestamp timestamp = int(current_datetime.timestamp())
random.seed(timestamp) key = random.randint(start_range, end_range) public_key = private_key_to_public_key(key) bitcoin_address = public_key_to_address(public_key, compressed=True) public_key = public_key_to_hex(public_key)
# Increment the current datetime by one second for the next timestamp current_datetime += timedelta(seconds=1) you won't believe what I've tried so far.
|
|
|
|
zahid888
Member
Offline
Activity: 272
Merit: 20
the right steps towerds the goal
|
|
October 03, 2023, 11:13:24 AM |
|
There is no pattern here. But there is a time when a puzzle was created. I even went back in time and generating numbers from 2015. Every second of that year.
https://bitcointalk.org/index.php?topic=1306983.msg62144570#msg62144570Almost six months ago, I undertook various tasks of a similar stuffs..
|
1BGvwggxfCaHGykKrVXX7fk8GYaLQpeixA
|
|
|
alek76
Member
Offline
Activity: 93
Merit: 16
|
|
October 03, 2023, 08:09:08 PM |
|
Alek, for the win. Long time no hear/see. Glad you’ve made it back.
What does your new program do exactly? The VanitySearch one.
Myself, no one wanted to combine forces to attack 130, so I’ve just been tinkering on different things. Nothing new, not any closer than I was months ago.
Thanks! This is a fork, it’s not mine programm, the program is optimized for a puzzle, but I removed everything unnecessary from the code and introduced a new random generator - no predictable random, as it was before.
|
|
|
|
frozenen
Newbie
Offline
Activity: 20
Merit: 0
|
|
October 04, 2023, 10:07:38 AM |
|
Has anyone ever found a key matching: 13zb1hQbWVsc ? just would be interesting to see!
|
|
|
|
citb0in
|
|
October 04, 2023, 10:14:42 AM |
|
Has anyone ever found a key matching: 13zb1hQbWVsc ? just would be interesting to see!
what for ? why should anyone be interested in finding a partly matching string of a puzzle BTC address ? it's completely useless
|
|
|
|
|