Search content
Sort by
Showing 20 of 25 results by ElonMusk_ia
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Code:
BTC Address(c): 1ECDLP8osCZHBB1LH5PVAUfFegeMgFb52q
minKey = 0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
maxKey = 0x659756abf6c17ca70fffffffffffffffffffff40be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
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: 0x659756abf6c17ca70e0000000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5 c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
You look for the pk in bit 80
Then you add to the obtained key
0x659756abf6c17ca70e0000000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5 c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
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.
What mental institution did you ask ChatGPT to pretend to come out from before producing these paragraphs? I cannot find a single phrase in this quote that makes common sense. Did you even provide the correct tokens to GPT, to begin with? Seems like you asked something related to some birthday paradox, and made GPT hallucinate a little about what precomputing means for kangaroo, while this topic discusses totally different things. Maybe read some actual real-life studies before making a shame of yourself again.
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
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-desc
I can suggest these changes in libplugin-pay.c.
Code:
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();
}
}
}
{
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.
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.
@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!
[/quote
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.pdf
You 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.
Quote
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
...
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.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves 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.
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.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves 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.pdf
You 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?
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
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.
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)
1ELonMUsKiaFNFxirdc64Hqro4YqLpDRp
@ELonMUsKia (10)
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Off topic:
White Hat Recovery reward 10%, i.e., up to $23 Million
https://x.com/WazirXIndia/status/1815004031561220352
https://www.talkimg.com/images/2024/07/26/4BbTH.gif
Good luck.White Hat Recovery reward 10%, i.e., up to $23 Million
https://x.com/WazirXIndia/status/1815004031561220352
https://www.talkimg.com/images/2024/07/26/4BbTH.gif
Re: Solution to the Collatz conjecture (in case there is a prize in BTC)
I can't give you prize money, but I can give you a merit.
thanks, I've updated the post!
Solution to the Collatz conjecture (in case there is a prize in BTC)
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.
Code:
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))
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+1
3n+1= 3n+i
where "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= Z
where 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=n
In both cases our final loop will be:
( i*4, i*2, i)
Now let's take a look at the new code corresponding to 3n+i and respecting the rule.
Code:
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))
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))
Why does it always reduce to "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.
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}")
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}")
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.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
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