 Show Posts
|
|
Pages: [1] 2 »
|
BTC Address(c): 1ECDLP8osCZHBB1LH5PVAUfFegeMgFb52q
minKey = 0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
maxKey = 0x659756abf6c17ca70fffffffffffffffffffff40be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
The problem I see with those keys is that, when you mod them to fit the curve, they are far than 80 bits apart. Just saying. Good luck to everybody with the challenge. I guess you just have to subtract from the target: 0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355 You look for the pk in bit 80 Then you add to the obtained key 0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355 |
|
|
|
|
Flat-earthers, who can beat their madness.
|
|
|
|
I am with Cricktor.
Why legacy? And how are you related to this bounty? And what has Core Lightning / and or Rusty Russell said about the bounty.
On a side note, it does work for me I just used it to pay a bitrefill invoice so I don't know how widespread this issue really is.
-Dave
My ignorance. I am the initiator. Nothing yet. It is the most commented ongoing issue on the Core Lightning Github page: https://github.com/ElementsProject/lightning/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-descI can suggest these changes in libplugin-pay.c. static bool payment_chanhints_apply_route(struct payment *p)
{
bool can_apply;
struct route_hop *current_hop;
struct channel_hint *current_hint;
struct payment *root = payment_root(p);
assert(p->route != NULL);
for (size_t i = 0; i < tal_count(p->route); i++) {
current_hop = &p->route[i];
current_hint = payment_chanhints_get(root, current_hop);
if (!current_hint)
continue;
can_apply = (!current_hint->local) || (current_hint->local->htlc_budget > 0);
can_apply &= amount_msat_greater_eq(current_hint->estimated_capacity, current_hop->amount);
if (!can_apply) {
paymod_log(p, LOG_DBG,
"Could not update the channel hint for %s. Could be a concurrent `getroute` call.",
fmt_short_channel_id_dir(tmpctx, ¤t_hint->scid));
paymod_log(p, LOG_DBG,
"Capacity: estimated_capacity=%s, hop_amount=%s. local=%s%s",
fmt_amount_msat(tmpctx, current_hint->estimated_capacity),
fmt_amount_msat(tmpctx, current_hop->amount),
current_hint->local ? "Y" : "N",
current_hint->local ? tal_fmt(tmpctx, " HTLC Budget: htlc_budget=%d", current_hint->local->htlc_budget) : "");
return false;
}
}
for (size_t i = 0; i < tal_count(p->route); i++) {
current_hop = &p->route[i];
current_hint = payment_chanhints_get(root, current_hop);
if (!current_hint)
continue;
if (current_hint->local) {
current_hint->local->htlc_budget--;
}
if (!amount_msat_sub(¤t_hint->estimated_capacity, current_hint->estimated_capacity, current_hop->amount)) {
// This should never happen due to the preemptive test above.
abort();
}
}
return true;
}
static void payment_chanhints_unapply_route(struct payment *p)
{
struct payment *root = payment_root(p);
for (size_t i = 0; i < tal_count(p->route); i++) {
struct route_hop *current_hop;
struct channel_hint *current_hint;
current_hop = &p->route[i];
current_hint = payment_chanhints_get(root, current_hop);
if (!current_hint)
continue;
if (current_hint->local)
current_hint->local->htlc_budget++;
if (!amount_msat_accumulate(¤t_hint->estimated_capacity, current_hop->amount)) {
// This should never happen, it'd mean that we unapply a route that would result in a msatoshi wrap-around.
abort();
}
}
}
|
|
|
|
John M. Pollard: “Randomness in these algorithms is crucial for their functioning.”
Impress me a little. First, where is that citation? Secondly, if you make claims, it is not our responsibility to prove you are wrong, but YOUR responsibility to prove you are right. But I'll make an exception for you, it is your lucky day  So, how exactly do you use randomness in your Kangaroo understanding of how the algorithm works? And how exactly you break the birthday paradox, and ruin the stuff entirely, let us understand what do you mean by "making the algorithm more deterministic" by "removing the randomness"? What randomness to remove in the first place? Where is that located, and how do you mess around with it, to be able to claim that you create determinism out of uncontrollable chaos? By applying precomputation in the Kangaroo algorithm, greater efficiency is achieved because precomputed intermediate results are reused instead of recalculating them each time. This reduces the number of necessary operations and, consequently, the computation time. However, by reducing the number of operations, the probability of collisions also decreases. This is because the birthday paradox is based on the probability that two elements in a large set will coincide. With fewer operations, there are fewer opportunities for collisions to occur. |
|
|
|
I don't understand why certain people prefer to create new accounts and troll around serious discussions. @ElonMusk, if you are who I believe to be - you may need some professional help - friendly advice. It's obvious no amount of evidence, common sense, or explanations can treat certain issues. This is like a dick contest: I show you that kangaroo with precomputed DPs can break any 80 bits or so key in a couple of seconds (random, sequential, you name it, as long as its in the range), there is always someone that brings up the "but its probabilistic" argument, however has nothing even remotely similar to offer, wtf?! Maybe I missed the day where everyone uses a super-computer and runs BSGS with a few PB of RAM (not that it would suffice). This topic was concluded already: the 4 kangaroo method remains the fastest method of the kangaroo family, 5 kangaroos or more are sub-optimal, just as suggested in the original paper. Anything else is off-topic. EOF. Stop promoting garbage. If you precompute certain values, you might lose the effect of the birthday paradox in the sense that you are reducing randomness and possible combinations. Precomputation can make the problem more deterministic and less dependent on the random coincidences that make the birthday paradox so surprising. You are leading people into a void.
Excellent!  I think now it's time for some magic circles, don't hesitate! The birthday paradox is based on probability and randomness, which allows for finding collisions more efficiently than with brute force. By modifying the kangaroo algorithm in a more deterministic way, this probabilistic advantage is lost, and it becomes an approach closer to brute force. The essence of the birthday paradox is that, with enough randomness, it is more likely to find collisions in a large set of data. By eliminating or reducing randomness, this property is lost, and the algorithm become less efficient. You are completely and utterly unaware of how Kangaroo works, please stop now. There is no randomness in the algorithm, ZERO randomness. I repeat: there is no usage of any random features, random functions, or random generators in the Kangaroo algorithm. In contrast, it is actually very well deterministic in nature, otherwise the collisions will not occur. . Having more DPs simply means there are more traps to be hit, increasing the chances. So please go back to the drawing board. John M. Pollard: “Randomness in these algorithms is crucial for their functioning.” |
|
|
|
Stop promoting garbage. If you precompute certain values, you might lose the effect of the birthday paradox in the sense that you are reducing randomness and possible combinations. Precomputation can make the problem more deterministic and less dependent on the random coincidences that make the birthday paradox so surprising. You are leading people into a void.
Excellent! I think now it's time for some magic circles, don't hesitate! The birthday paradox is based on probability and randomness, which allows for finding collisions more efficiently than with brute force. By modifying the kangaroo algorithm in a more deterministic way, this probabilistic advantage is lost, and it becomes an approach closer to brute force. The essence of the birthday paradox is that, with enough randomness, it is more likely to find collisions in a large set of data. By eliminating or reducing randomness, this property is lost, and the algorithm become less efficient. |
|
|
|
You only need to store 0.5 sqrt(N) keys (the baby steps) : from 1*G to 0.5*sqrt(N)*G
And next step is to calculate required memory for 0.5*sqrt(2^134) points. After this calculation you will lose all your interest in BSGS Or may be you are going to break a lot of <64bit points? Even so, kang is faster because you can have precomputed db of DPs and reduce time in 10 times or even more. If the goal is to retrieve a private key in a 2^134 interval, there is no doubt: BSGS is not the algorithm to use. But in a 2^64 interval, BSGS can be faster. For one 64bit point without precomputing - yes. For many points - kang with precomputed DPs is faster. Of course you can do the same for BSGS, precompute more points to speedup it, but it won't be so effective as for kang, to speedup BSGS in 10 times you will have to precompute (and store) much more points than for kang (because BSGS does not use birthday paradox sqrt). Stop promoting garbage. If you precompute certain values, you might lose the effect of the birthday paradox in the sense that you are reducing randomness and possible combinations. Precomputation can make the problem more deterministic and less dependent on the random coincidences that make the birthday paradox so surprising. You are leading people into a void. |
|
|
|
And still people believe BSGS would work faster. for whatever reason, with TB of RAM.. I let them continue believing that.
BSGS algorithm applied to secp256k1 curve only need 1.0 sqrt(N) operations (on average) and 1.5 sqrt(N) operations in the worst case: https://eprint.iacr.org/2015/605.pdfYou only need to store 0.5 sqrt(N) keys (the baby steps) : from 1*G to 0.5*sqrt(N)*G and compute in the worst case 1.0 * sqrt(N) keys (the giant steps) Only additions and subtractions, no multiplications. Conclusion
...
The new algorithms, like the original, have low overhead but high memory.
This means that our algorithms are useful only for discrete logarithm problems
small enough for the lists to fit into fast memory
Kangaroo doesn't need fast memory. Or any memory at all. I'd say it's a good trade-off. Kangaroo is only probabilistic, don't lose focus, Kangaroo doesn't need much power to play the birthday paradox puzzles. Be careful not to ruin the birthday paradox in the search for more speed. |
|
|
|
Current algorithms like Kangaroo don`t give u real keys/s information, hence your surprise, the speed of these algorithms is often related more to statistical performance than direct metrics like keys per second.
You are confusing the exakeys/s shown by some BSGS programs with the real speed (4000+ Mkeys/s) actually computed and analyzed by any real Kangaroo program. That is, there are indeed 4 billion keys (public keys, and hence by induction private keys) computed per second, and each of them is a complete key (256 bits) which is processed, checked, and then jumped further. No statistical BS there. Just a direct metric. I saw the kangaroo code and it uses the length of the jumps as a reference for speed, this is not true, nor exact. see check.h file. What's the check.h file? Is it part of the Kangaroo algorithm? RTX 4090 specs: FP32 (float) 82.58 TFLOPS That's 82580 billion raw operations/s on floating-point numbers. Once you divide by the number of instructions needed to do a single kangaroo jump (e.g. point addition under the EC modular field, P + Q = R), you're left with a few good N billion keys/s (where N is 4 or larger depending on the implementation). You can do 5600000000 (that's 5.6 billion keys/s) on a RTX 4090, just to add that 4000 is slower than what the hardware can accomplish. Stop spreading false information. the check.h file is part of kangaroo, it is public, it is not fake information, anyone can review it. |
|
|
|
Current algorithms like Kangaroo don`t give u real keys/s information, hence your surprise, the speed of these algorithms is often related more to statistical performance than direct metrics like keys per second.
You are confusing the exakeys/s shown by some BSGS programs with the real speed (4000+ Mkeys/s) actually computed and analyzed by any real Kangaroo program. That is, there are indeed 4 billion keys (public keys, and hence by induction private keys) computed per second, and each of them is a complete key (256 bits) which is processed, checked, and then jumped further. No statistical BS there. Just a direct metric. I saw the kangaroo code and it uses the length of the jumps as a reference for speed, this is not true, nor exact. see check.h file. |
|
|
|
And still people believe BSGS would work faster. for whatever reason, with TB of RAM.. I let them continue believing that.
BSGS algorithm applied to secp256k1 curve only need 1.0 sqrt(N) operations (on average) and 1.5 sqrt(N) operations in the worst case: https://eprint.iacr.org/2015/605.pdfYou only need to store 0.5 sqrt(N) keys (the baby steps) : from 1*G to 0.5*sqrt(N)*G and compute in the worst case 1.0 * sqrt(N) keys (the giant steps) Only additions and subtractions, no multiplications. BSGS is faster, but Kangaroo is very good at aiming, how good will he be? |
|
|
|
I wish I had, it was Shelby0901 who said he could access 900x RTX4090!
No 4billion per second is slow but that is the best a GPU can do for brute force as far as I know.
Ok than i have miss nothing, i was shocked to read it, also 900 x 4 b seems slow today. Current algorithms like Kangaroo don`t give u real keys/s information, hence your surprise, the speed of these algorithms is often related more to statistical performance than direct metrics like keys per second. |
|
|
|
|
What is the longest vanity address found? Because it's one thing to find a long vanity address with specific intentions and another to try your luck with a dictionary.
1ELonMUsKiaFNFxirdc64Hqro4YqLpDRp
@ELonMUsKia (10)
|
|
|
|
I can't give you prize money, but I can give you a merit.
thanks, I've updated the post! |
|
|
|
The Collatz conjecture, also known as the 3n+1 conjecture or Ulam's conjecture, was stated by mathematician Lothar Collatz in 1937. Although it has puzzled the mathematical community for decades, it has yet to be solved. The conjecture states the following: Starting with any positive integer: If the number is even, divide by 2. If the number is odd, multiply by 3 and add 1. A sequence is formed by applying this operation repeatedly, taking the result of each step as input for the next. The conjecture says that we will always reach the number 1, regardless of what number we start with. import random
def collatz(n):
while n != 1:
print(n)
if n % 2 == 0:
n = n // 2
else:
n = 3*n + 1
print(n)
return n
collatz(random.randint(1,100000000)) A conjecture is a statement that is based on observations or evidence, but that has not yet been proven or disproven. In mathematics, a conjecture is a problem that seeks a solution, and there is a prize of almost 1 million dollars for this. The prize will be given to whoever offers a mathematical solution that certifies whether or not this is true for all numbers, and that said solution is not refuted by the mathematical guild.
My solution to the problem:To understand how it works we must modify the formula 3n+13n+1= 3(ni) + i3(ni) + iwhere "i" must be an odd number. and these two rules must be followed: 1- "i" must be an odd number. The reason we apply this rule is to force 3n+i to give an even result, as we saw in the original conjecture. 2- n/i= Zwhere Z refers to an integer: Z= {... -3,-2,-1, 0,+1,+2,+3 ...}The reason we ignore this rule in the Collatz conjecture is because n/1=nIn both cases our final loop will be: ( i*4, i*2, i)Now let's take a look at the new code corresponding to 3(ni) + i and respecting the rule. import random
i=7
def collatz(n):
while n != i:
print(n)
if n % 2 == 0:
n = n // 2
else:
n = 3*n + i
print(n)
return n
collatz(i*random.randint(1,100000000))
print("final loop= "+str(i*4)+","+str( i*2)+","+str( i)) Forcing 3n+i to give an even result, as we can see in the original conjecture, statistically increases the number of times we divide by 2, leaving an approximate of 40-60% more divisions compared to multiplication by 3. as you can see in the following code. import random
i= 7
def collatz(n):
even_count = 0
odd_count = 0
while n != i:
if n % 2 == 0:
even_count += 1
n = n // 2
else:
odd_count += 1
n = 3 * n + i
return n, even_count, odd_count
random_number = i*random.randint(1, 100000000)
result, even, odd = collatz(random_number)
print(f"The Collatz sequence for {random_number} ends at {result}.")
print(f"Even numbers encountered: {even}")
print(f"Odd numbers encountered: {odd}")
How do we verify huge numbers?Suppose we use as target=10 import random
i=1
target=10
def collatz(n):
even_count = 0
odd_count = 0
while n != i:
print(n)
if n % 2 == 0:
even_count += 1
n = n // 2
else:
odd_count += 1
n = 3 * n + i
print(n)
return n, even_count, odd_count
random_number =i*target# i*random.randint(1, 10000)
result, even, odd = collatz(random_number)
print(f"The Collatz sequence for {random_number} ends at i {result}.")
print(f"Even numbers encountered: {even}")
print(f"Odd numbers encountered: {odd}")
we get the three results with i= 1,3,5. odd order We appreciate that they have the same order or sequence: even, odd, even, even, even, even, odd. (because we maintained the target) using i=1 using i=3 using i=5
10 |30 |50
5 |15 |25
16 |48 |80
8 |24 |40
4 |12 |20 |
2 |6 |10
1 |3 |5
The Collatz sequence for 10 ends at i 1. The Collatz sequence for 30 ends at i 3. The Collatz sequence for 50 ends at i 5.
Even numbers encountered: 5 Even numbers encountered: 5 Even numbers encountered: 5
Odd numbers encountered: 1 Odd numbers encountered: 1 Odd numbers encountered: 1 So if we want to search for numbers 4 to 6 using the traditional method with i=1 we obtain that the sequences are within the table. 4
2
1
The Collatz sequence for 4 ends at i 1.
Even numbers encountered: 2
Odd numbers encountered: 0
5
16
8
4
2
1
The Collatz sequence for 5 ends at i 1.
Even numbers encountered: 4
Odd numbers encountered: 1
6
3
10
5
16
8
4
2
1
The Collatz sequence for 6 ends at i 1.
Even numbers encountered: 6
Odd numbers encountered: 2 In this way we know that if we use i= 22**70 -1 it is not necessary to go through the entire section from 1 to 22**70 -1 with the original conjecture to verify that the sequence exists. import random
i=22**70 -1
target=10
def collatz(n):
even_count = 0
odd_count = 0
while n != i:
print(n)
if n % 2 == 0:
even_count += 1
n = n // 2
else:
odd_count += 1
n = 3 * n + i
print(n)
return n, even_count, odd_count
random_number =i*target# i*random.randint(1, 10000)
result, even, odd = collatz(random_number)
print(f"The Collatz sequence for {random_number} ends at i {result}.")
print(f"Even numbers encountered: {even}")
print(f"Odd numbers encountered: {odd}") 93236863968449335445326143653683496321795363944175445348633354543780733426420385752394487562230
46618431984224667722663071826841748160897681972087722674316677271890366713210192876197243781115
149178982349518936712521829845893594114872582310680712557813367270049173482272617203831180099568
74589491174759468356260914922946797057436291155340356278906683635024586741136308601915590049784
37294745587379734178130457461473398528718145577670178139453341817512293370568154300957795024892
18647372793689867089065228730736699264359072788835089069726670908756146685284077150478897512446
9323686396844933544532614365368349632179536394417544534863335454378073342642038575239448756223
The Collatz sequence for 93236863968449335445326143653683496321795363944175445348633354543780733426420385752394487562230 ends at
i 9323686396844933544532614365368349632179536394417544534863335454378073342642038575239448756223.
Even numbers encountered: 5
Odd numbers encountered: 1
So we can conclude that the Collatz conjecture is true for all numbers.
Thanks for reading, if there is a reward in BTC (I'm not sure there is) I'll leave my wallet to whoever might be interested in my profile, I also uploaded a paper on the official page for mathematicians.
|
|
|
|
|
Why search for puzzle 66? Don't you think it's a waste of time?
|
|
|
|
|
I think this puzzle thing has stalled, the creator should release all the remaining public keys if he really wants to test the robustness of bitcoin, here only sha256 and ripemd-160 are being tested at this point
|
|
|
|
hello , how are you now ? you seems to be not updating us what had happened? because we are concern about
your health and your decision making and also about that woman that abused your feeling .
hoping that you are doing better now and have living a life that you deserve .
Hello, thank you for asking. Everything is improving day by day. I still feel anxiety and stress because it’s difficult for me not to think about it every day. However, by exercising, I can control the anxiety and stress a little. Sometimes, even after midnight, I exercise to be able to sleep. Exercise helps a lot. In general, everything is much better than it was at the beginning. I just want to finish healing and then continue with my life and my goals. Cheer up, man! We’re eagerly waiting to see what you’ve got up your sleeve. Your lightweight database was the most innovative thing I’ve seen since Kangaroo and Keyhunt years ago. You’ve got talent. |
|
|
|
|
