Bitcoin puzzle transaction ~32 BTC prize to who solves it

[WanderingPhilospher]

I found that random searches sometimes gave me the same results several times. That means I'm scanning the same keys more than once!

What size search range were you using? It must have been a somewhat small one relative to GPU speed.

Imagine a big bag full of green beans and only one red bean

By not leaving the red beans out after grabbing one, on average, you double your attempts. Meaning, if you place the red bean back in the bag, you will find the green one, on average, every 100 attempts. By leaving the red bean out of the bag, you would find the green one, on average, every 50 attempts.

If people like mcdouglasx, alberto and zielar approve of this topic, I can show you a small presentation example.

Why do you need approval of these people lol?! It is a community forum, post whatever you feel like, as you already have. Why not include ktimesg's name as well? Because he doesn't agree with you 100%? The one's you mentioned would not agree with you 100% either.

[Gerbie]

I found that random searches sometimes gave me the same results several times. That means I'm scanning the same keys more than once!

What size search range were you using? It must have been a somewhat small one relative to GPU speed.

I don't know the exact range, but yes it was relatively small, so I knew I could scan the full range within 30 minutes on a Google Colab T4. That made me wonder, is that specific for a small range, or will it happen with a large range as well, only that I don't notice it (so easily)...?
I tend to test in small steps, so I can see what happens. The numbers are so huge, that my small brain has to split it in smaller bits... and I don't want to run a test for several weeks to find out my idea is not working at all and I just wasted resources.

[kTimesG]

I found that random searches sometimes gave me the same results several times. That means I'm scanning the same keys more than once!

What size search range were you using? It must have been a somewhat small one relative to GPU speed.

I don't know the exact range, but yes it was relatively small, so I knew I could scan the full range within 30 minutes on a Google Colab T4. That made me wonder, is that specific for a small range, or will it happen with a large range as well, only that I don't notice it (so easily)...?
I tend to test in small steps, so I can see what happens. The numbers are so huge, that my small brain has to split it in smaller bits... and I don't want to run a test for several weeks to find out my idea is not working at all and I just wasted resources.

You would have to be really lucky to pick N distinct random keys in a N-sized set, where the events are all independent, and the starting conditions are identical at every draw.

In fact, there is an exact formula for this. and you can even know in advance with a very high degree of confidence how many times you'll get repeats, and after how many draws you'll start to get 3 repeats, and so on.

There is also the possibility that you'll never pick some of the numbers even after very very many draws (much larger than N). This is also something you can calculate at advance.

The only problem is that you can never know in advance what keys you'll miss, what keys will start to repeat, and things like that. But it is actually normal to have some keys picked up more often, and others less often, because these are the 99.(9)%... majority of cases in the combinational possibilities.

Your draws would just be one in such of the gazillions possibilities. So the possibility where you perfectly pick every random number without repeat is just a single one, out of those gazillion ones.

If you don't trust this information, just go ahead and do a full CDF and StdDev analysis on the history of any lottery you want (or just simulate one in Python). You'll see some numbers start to get repeated much more often while others remain behind in the histogram However, this is normal - they just landed in the universe where some specific combination occurred, there is no conspiracy. Oh, and also it might help you pick out the next lucky numbers. I'm kidding, not really, but maybe a couple of them.

you are right, there is no such thing as compound probability, I made that up, there is no such term, there is no such thing as compound probability, it is always the same in all cases, that is why wp has found many very close prefixes, almost one next to the other, and bibilgin found 4 prefixes "1BY8GQbnueY" in a range of 1000000 keys (but it hides it), because it is equally probable, right.
those of you reading this have a hard time finding a long prefix are probably doing it wrong, because finding them nearby is just as probable as far away and that is the absolute truth. Happy?

Are you OK? You are putting words in my mouth. I never said compound probability does not exist, but I asked you twice already, and a final time now:

What reference do you have that states compound probability refers to two independent events occurring one after the other and not anywhere in the number of trials.

I can prove to you that what I said makes sense in practice, unlike you, who seems to read inexistent words in theories. Yes, finding them nearby or at distance D = whatever (pick any number you want for D), has the exact same chances.

[bibilgin]

I don't know the exact range, but yes it was relatively small, so I knew I could scan the full range within 30 minutes on a Google Colab T4. That made me wonder, is that specific for a small range, or will it happen with a large range as well, only that I don't notice it (so easily)...?
I tend to test in small steps, so I can see what happens. The numbers are so huge, that my small brain has to split it in smaller bits... and I don't want to run a test for several weeks to find out my idea is not working at all and I just wasted resources.

Although, I would be happy if you could write your thoughts and opinions after reviewing the explanation (small presentation) I wrote to you privately.

[benjaniah]

Imagine a big bag full of green beans and only one red bean (the private key we're looking for).

Interesting thought experiment.
I did some calculations to help visualize the size of puzzle 67's keyspace. There are 73786976294838206464 possible keys in puzzle 67. Some may look at the number "73786976294838206464" or at the hex range of 40000000000000000:7FFFFFFFFFFFFFFFF and think, well that number doesn't really look that big.

Now let's take a look at the Great Pyramid of Giza, in Egypt. It is the largest pyramid in Egypt, with an original height of around 146.6 meters (480.6 feet) and a base length of about 230.4 meters (756 feet) on each side. Next, imagine you have 73786976294838206463 grains of just average, white, sand, and just 1 grain of black sand (representing all of puzzle 67's possible keys, and the 1 private key). You would fill the volume of the Great Pyramid of Giza with sand ~370 times. Try to picture 370 of these pyramids, all of white sand, and inside one of them somewhere is 1 individual grain of black sand.

If you took a typical US 5 Gallon bucket, and could check 1 bucket per second, looking for that 1 black grain of sand (and hopefully not miss it), that's about 1.5 billion grains of sand per second. It would take you 1560 years to check all of the sand, assuming you were checking nonstop, 24/7/365. Maybe a little bit longer, if you took a few breaks to eat some yogurt.

[mcdouglasx]

What reference do you have that states compound probability refers to two independent events occurring one after the other and not anywhere in the number of trials.

According to your criteria, each prefix independently has the same probability of being in one place or another, and you are right (independently the probabilities are the same). However, you only take that as a single truth, which is where I disagree. If you debated between joint probability and compound probability, you would have a bit more logic.

because, joint probability refers to the probability that two or more events occur simultaneously. So, it could be interpreted as all the hashes being "written in stone", therefore you could argue that all independent prefixes were generated simultaneously for Bitcoin.

In the case of compound probability, on the other hand, which refers to the probability that two or more independent events occur in sequence, you could also apply it to Bitcoin by calculating the probability that a prefix repeats as you move from one prefix to another.

But in any case, it cannot be taken as a single independent event, it is not like you are looking for a different prefix in each event. In the same way, this book explains it with examples.

"A First Course in Probability" by Sheldon Ross

[kTimesG]

What reference do you have that states compound probability refers to two independent events occurring one after the other and not anywhere in the number of trials.

In the case of compound probability, on the other hand, which refers to the probability that two or more independent events occur in sequence, you could also apply it to Bitcoin by calculating the probability that a prefix repeats as you move from one prefix to another.

But in any case, it cannot be taken as a single independent event, it is not like you are looking for a different prefix in each event. In the same way, this book explains it with examples.

Again, you are using the words "occur in sequence" which is not the same as "occur in a sequence". There's nothing in that book about this.

You're still assuming the probability changes just because you move from one key to the next. But there's no external entity that would do that (except faith maybe).

Example: some sequence of 100 events, and you know somehow that 2 of them are successful ones. It doesn't matter what we mean by "successful" (hash prefix match, or whatever you'd like to use).

Total possible sequence combinations: 4950
Total combinations where successes are next to each other: 99

So, the probability to have the successes next to each other is 99 in 4950.

Total combinations where successes are separated by a distance of 2: 98
Total combinations where successes are separated by a distance of 3: 97
Total combinations where successes are separated by a distance of 4: 96
...
Total combinations where successes are separated by a distance of 50: 50

So, the probability to have the successes separated by a distance of 50 is: 50 in 4950.

At this point, you would be something like: OK, this sounds like it's actually more likely to have the successes next to each other, rather than evenly spaced! So WTF is happening here?

Let's continue:

Total combinations where successes are separated by a distance of 51: 49
Total combinations where successes are separated by a distance of 52: 48
...
Total combinations where successes are separated by a distance of 98: 2
Total combinations where successes are separated by a distance of 99: 1

Maybe now something starts to become obvious: wait, so we only have 1 in 4950 as a probability to have the successes spaced by distance of 99? That doesn't sound right.

Well, friends, what we did is we forgot about what happened before our sequence and after our sequence. So, if we put head to head our sequence of events, we'll see that if the successes are at #1 and #100, they are "next to to each other".

So let's fix our probabilities:

Total combinations where successes are next to each other (or at dist 99): 99 + 1 = 100

So, the probability to have the successes separated by a distance of (1 or 99) is: 100 in 4950.

The same goes for the other ones, let's see what happens:

Total combinations where successes are separated by a distance of X (or 100 - X): 100 - X + X= 100

So, same chances whatever delta we pick.

[bibilgin]

--Again, you are...

Let me ask you a question.

There are 2 wallets with 12 prefixes similar to each other.
Among these wallets, there will be no wallet with 9 or 10 prefixes similar.

You say that this is also possible. Is that right?

[kTimesG]

--Again, you are...

Let me ask you a question.

There are 2 wallets with 12 prefixes similar to each other.
Among these wallets, there will be no wallet with 9 or 10 prefixes similar.

You say that this is also possible. Is that right?

I don't understand what you asked, but anyway, I think you didn't even read the post. If you're looking for addresses that match a 12 char prefix, that's one thing. If you're looking for addresses that match 1-bit prefixes, that's a separate thing. If that first bit is also the first bit for all possible hashes that have the 12 char prefix, then obviously there are more hashes that have the bit, then hashes that have the prefix. However, there are the same amount of hashes that start off with the OTHER bit, so, yes, it is possible (e.g., yes, there are existing combinations) where everything else (except your 2 addresses with the same 12-char prefix), start off with a different bit, hence not the same prefix or any sub-prefix of it (1,2... 11 chars). However, that doesn't mean that this possibility is actually found in some sequential subrange, but it is also not excluded (for secp256k1, you'd have to check all the existing 2**256 ranges that comprise of 2**66 sequential keys). And you can obviously simply create one: pick 2**66 keys with hashes starting with a 0, except two of them that have hashes starting with a 1. Oh, wait, ECC math, G is fixed, keys have an order, "it can't happen"... etc... no comment.

[bibilgin]

I don't understand what you asked, but anyway, I think you didn't even read the post. If you're looking for addresses that match a 12 char prefix, that's one thing. If you're looking for addresses that match 1-bit prefixes, that's a separate thing. If that first bit is also the first bit for all possible hashes that have the 12 char prefix, then obviously there are more hashes that have the bit, then hashes that have the prefix. However, there are the same amount of hashes that start off with the OTHER bit, so, yes, it is possible (e.g., yes, there are existing combinations) where everything else (except your 2 addresses with the same 12-char prefix), start off with a different bit, hence not the same prefix or any sub-prefix of it (1,2... 11 chars). However, that doesn't mean that this possibility is actually found in some sequential subrange, but it is also not excluded (for secp256k1, you'd have to check all the existing 2**256 ranges that comprise of 2**66 sequential keys). And you can obviously simply create one: pick 2**66 keys with hashes starting with a 0, except two of them that have hashes starting with a 1. Oh, wait, ECC math, G is fixed, keys have an order, "it can't happen"... etc... no comment.

The question is very clear and concise.
This discussion started with similar prefixes.
Question There are 2 wallets with 12 prefixes.
Their Hex codes can come one after another. It doesn't matter how many bits there are. (According to your opinion.)

Without any 9 or 10 prefix similarity between them. Is that your opinion?

Example:
1BY8GQbnubbH1UeVuGYAdVXSMHiBLd7iBZ
1BY8GQbnubbHgnpysMTFdfbrnPcw9oRU6i

Among the wallets with 12 prefix similarity, 1BY8GQbnu (9 prefix) or 1BY8GQbnub (10 prefix) can come one after another without a similar wallet.

[stenaku]

I found that random searches sometimes gave me the same results several times. That means I'm scanning the same keys more than once!

What size search range were you using? It must have been a somewhat small one relative to GPU speed.

I don't know the exact range, but yes it was relatively small, so I knew I could scan the full range within 30 minutes on a Google Colab T4. That made me wonder, is that specific for a small range, or will it happen with a large range as well, only that I don't notice it (so easily)...?
I tend to test in small steps, so I can see what happens. The numbers are so huge, that my small brain has to split it in smaller bits... and I don't want to run a test for several weeks to find out my idea is not working at all and I just wasted resources.

Which script are you using for Google Colab T4?

[karrask]

hello. Can I ask you a question about kangaroos? using the example of the kangaroo RC.
When the program starts, the total number of kangaroos is displayed - 1507328 kangaroos, Speed: 2271 MKeys/s - do I understand correctly that the speed is indicated for each kangaroo?

[puzzlemandelux]

I am looking for puzzle 67, working with the prefixes.
Obviously I understand there is probably no correlation with the prefixes but I have collected up to 1BY8GQbnu so far.
Currently looking for 1BY8Qbnue.

Working with a 4070 Super and Vanbitcracken.
2000 million keys per second.

Any other software that would be quicker for this work?

[mcdouglasx]

Again, you are using the words "occur in sequence" which is not the same as "occur in a sequence". There's nothing in that book about this.

You're still assuming the probability changes just because you move from one key to the next. But there's no external entity that would do that (except faith maybe).

As I told you previously, you never want to lose your argument and you will always find a explanation that fits with what you preach. And I am the one quoting thinks while you only preach your words as true. It's great you read the book in less than 24 hours. However, when talking about events that 'occur in sequence', I mean that the events appear one after the other in a specific order. It doesn't necessarily mean that one depends on the other, but rather that there is an order. This is a typical fallacy in debates. You dismiss opposing ideas in a disparaging way to validate your point by saying things like 'except faith maybe'.


"A compound event is also the outcome of an experiment, but can be broken down into a combination of simple events occurring simultaneously or in succession."
https://study.com/academy/lesson/compound-event-in-math-definition-example.html

https://thirdspacelearning.com/gcse-maths/probability/combined-events-probability/#:~:text=Combined%20events%20in%20probability%20are,use%20the%20AND%20probability%20rule.

https://www.youtube.com/watch?v=EHU6pVSczb4

If we want to find a RIPEMD-160 hash with 4 initial prefixes, for example:

123a

The probability of each independent character is 1/16 (since a hex has exactly 16 alphanumeric characters 0-9 a-f). So, the probability of the complete prefix 123a would be:

1/16 x 1/16 x 1/16 x 1/16 =  1/65.536.

And that's just the calculation for a 4-digit prefix. With 2 prefixes, it increases much more, and if you look for longer prefixes, it becomes even less probable.

Therefore, due to the uniform distribution of hashes, it is less likely that we will find a prefix close to another one.

A probabilistic software using a previous prefix as a reference point, where you skip millions of keys and where a coincidence or collision is less likely, is not a waste of time as you suggest. Instead, it would be another probabilistic option. In this case, where sequential brute force is exponentially demanding, a probabilistic search suggests a better strategy.

However, it is clear that you can skip the address, but it is less probable if you do the calculations correctly, adding a margin of error.

[kTimesG]

Therefore, due to the uniform distribution of hashes, it is less likely that we will find a prefix close to another one.

A probabilistic software using a previous prefix as a reference point, where you skip millions of keys and where a coincidence or collision is less likely, is not a waste of time as you suggest. Instead, it would be another probabilistic option. In this case, where sequential brute force is exponentially demanding, a probabilistic search suggests a better strategy.

I'm not preaching anything that's not in a 9th grade high school math book where I live.

Did you read the definition of a uniform distribution? It's a random oracle where anything can happen (with an equal chance of course, which is all I'm bragging about for the last 10 posts here), not something that will ever follow any kind of even-spaced value-to-slot allocations, no matter how you look at it, analyze it, or whatever you want to do with it. The "margin of error" when trying to predict anything about it is simply equal to keeping track of skipped key ranges, which is where everyone that attempts to use this "theory" will end up to, once they find that they either have too many or too few prefixes found.

Just because the probabilities are all equal, does not mean that you will end up with an equal amount of same values over some microscopic sample size (like any 2**66 sample out of comb(2**160, 2**66), or rather, out of (2**160) ** (2**66) possibilities, since any hash has an equal probability to occur).

It is exactly the same principle why, if you throw a coin 100 times, the chances to get a 50/50 is extremely unlikely, even if it has the highest chances. Or isn't a coin flip an uniform distribution of 50/50? Why wouldn't RIPEMD-160 be the same, if you scan some range, and only count how many times the first bit is 1, there's basically 0% chances to have anywhere near the same amount of hashes that start with a 0 (the difference will be a really really big number, not close to zero, and there's a 99.9% confidence for this really big difference to occur). Only when the number of flips (number of hashes) goes to infinity, will you ever have an exact ratio of 50% 0s (heads) and 50% 1s (tails). Up to that  point, the difference (in absolute value) will almost certainly increase further and further, perhaps at some times swapping whether the 0s or the 1s start to go ahead. It's all a probability race based on equal chances of possible occurrences.

Thanks for the lesson that 2 bytes can hold 65536 distinct values.

[madogss]

hello. Can I ask you a question about kangaroos? using the example of the kangaroo RC.
When the program starts, the total number of kangaroos is displayed - 1507328 kangaroos, Speed: 2271 MKeys/s - do I understand correctly that the speed is indicated for each kangaroo?

no its all the kangaroo's combined.

[brainless]

Let me explain in detail everything related to transaction replacement, particularly focusing on Replace-by-Fee (RBF) and how it works in the Bitcoin network. I will also cover the process of replacing transactions, the use of RBF, and how to manage transactions in different scenarios.

What is Replace-by-Fee (RBF)?
Replace-by-Fee (RBF) is a feature that allows a user to replace a Bitcoin transaction that has not yet been confirmed by the network with another transaction that pays a higher fee. This can be helpful in case the original transaction was not included in the next block due to low fees, especially in times of network congestion.

When RBF is enabled, the sender can increase the fee and re-broadcast the transaction, increasing the chances of it being included in the next block by miners.

How RBF Works:
Transaction Broadcasting: A user broadcasts a transaction with a specified fee. If the transaction is not confirmed (due to low fees or network congestion), the user can replace the original transaction with one that has a higher fee.
RBF-Compatible Transactions: Transactions that are sent with RBF enabled are considered "RBF transactions". These transactions have a special flag in their structure that allows them to be replaced.
Why Replace a Transaction?: If a user sends a transaction with low fees and it’s stuck in the mempool (not confirmed), they can increase the fee to make the transaction more attractive to miners. Miners prioritize transactions with higher fees.
How to Create and Replace Transactions with RBF:
1. Creating a Transaction with RBF Enabled:
To send a transaction with RBF enabled, the wallet or software you are using must support RBF. Most modern Bitcoin wallets, including Bitcoin Core, allow you to enable or disable RBF when creating transactions.

Steps in Bitcoin Core (GUI):
Open Bitcoin Core and go to the Send tab.
Select the address to send the Bitcoin to and enter the amount.
If RBF is available, you can check a box or select an option to enable Replace-by-Fee. This flag ensures that the transaction can be replaced with a higher fee later.
Sign and broadcast the transaction.
Steps in Bitcoin Core (Command Line):
You can also use Bitcoin Core’s command-line interface to create an RBF-enabled transaction.

bash
Copy
bitcoin-cli createrawtransaction '[{"txid":"previous_txid","vout":0}]' '{"recipient_address":amount}'
To enable RBF, you can use the following command:

bash
Copy
bitcoin-cli sendtoaddress "recipient_address" amount "" "" true
Here, the true value at the end enables RBF for this transaction.

2. Replacing a Transaction:
If the transaction you sent was not confirmed due to low fees, you can replace it with a new transaction that has a higher fee. This is where RBF comes into play.

Steps to Replace a Transaction:
Identify the transaction: You need the Transaction ID (TXID) of the original transaction that is stuck.
Create a new transaction: Use the same inputs (unspent transaction outputs, UTXOs) as the original transaction, but increase the fee.
Rebroadcast the transaction: Once the new transaction is created and signed, rebroadcast it to the network. Since it has a higher fee, it will be more attractive to miners and is likely to be confirmed faster.
3. Using Bitcoin Core Command Line to Replace:
You can use the following command to replace a transaction using RBF:

bash
Copy
bitcoin-cli walletcreatefundedpsbt '[{"txid":"previous_txid","vout":0}]' '{"recipient_address":amount}' 0 false
The false option ensures that RBF is not enabled. You can set true if you want to enable RBF during the creation of this transaction.
After creating the transaction, sign and broadcast it to the Bitcoin network.
4. How to Replace an Unconfirmed Transaction:
If you are using a wallet that supports RBF, you can also replace a transaction using the wallet’s interface or an API. Some wallets will automatically allow you to increase the fee of an unconfirmed transaction directly from their UI (like Electrum).

What Happens if the Transaction Doesn't Support RBF?
If a transaction is not RBF-enabled, it cannot be replaced once broadcast to the network. The transaction is considered final once it's broadcast, and the only option is to wait for it to be confirmed or rejected by the network.

Non-RBF transactions cannot be modified or replaced.
Once a non-RBF transaction is broadcast, it is essentially locked in place, and only the miners can choose whether or not to include it in a block.
How to Check if a Transaction Supports RBF?
You can check if a transaction is replaceable by looking at the raw transaction data or by querying the Bitcoin node or blockchain explorer.

In Bitcoin Core: You can use the command getrawtransaction to check whether the transaction supports RBF. If the transaction contains the "replaceable" flag, it is replaceable.
bash
Copy
bitcoin-cli getrawtransaction "TXID" 1
Blockchain Explorer: Many blockchain explorers show whether a transaction is RBF-enabled. You can check the status of the transaction by entering its TXID into the explorer.
Example Scenario:
Let’s say you send a transaction with a low fee and it doesn't get confirmed after several blocks. In this case:

You check the status of your transaction using a blockchain explorer.
If the transaction is still in the mempool (unconfirmed), you can create a new transaction that replaces the original transaction with a higher fee (thanks to RBF).
You broadcast the new transaction, and since it pays a higher fee, miners are more likely to confirm it.
Why Use Replace-by-Fee?
Speed Up Transaction Confirmation: If your transaction is stuck due to low fees, RBF allows you to increase the fee and get it confirmed faster.
Network Congestion: In times of high network traffic, RBF gives you a way to "boost" your transaction's priority by increasing the fee, ensuring it doesn’t stay stuck.
Avoid Stuck Transactions: For users who want more control over their transaction's confirmation, RBF provides the flexibility to adjust the fees dynamically.
Summary:
RBF (Replace-by-Fee) allows you to replace an unconfirmed transaction with a higher-fee transaction.
Enable RBF during the creation of a transaction in compatible wallets like Bitcoin Core.
Replace transactions with higher fees if they are stuck in the mempool.
Non-RBF transactions cannot be replaced once broadcast to the network.
Check if a transaction supports RBF using raw transaction data or a blockchain explorer.
RBF provides flexibility for users to manage their transactions and avoid delays caused by network congestion.

Your choice for enable or not RBf in tx ended
Each n every tx you send to mempool, by default set RBf enabled at minners (mempool)
Read Bitcoin core current rules

[karrask]

hello. Can I ask you a question about kangaroos? using the example of the kangaroo RC.
When the program starts, the total number of kangaroos is displayed - 1507328 kangaroos, Speed: 2271 MKeys/s - do I understand correctly that the speed is indicated for each kangaroo?

no its all the kangaroo's combined.

why is the speed so low for just math? keyhant (bsgs) is much faster with enough RAM and processor threads.
do you know where to find the fastest algorithm for obtaining a public key and address? maybe someone has, can you share?

[kTimesG]

hello. Can I ask you a question about kangaroos? using the example of the kangaroo RC.
When the program starts, the total number of kangaroos is displayed - 1507328 kangaroos, Speed: 2271 MKeys/s - do I understand correctly that the speed is indicated for each kangaroo?

no its all the kangaroo's combined.

why is the speed so low for just math? keyhant (bsgs) is much faster with enough RAM and processor threads.
do you know where to find the fastest algorithm for obtaining a public key and address? maybe someone has, can you share?

BSGS shows speed of how many keys are not a solution, it doesn't compute any of them except one in every sqrt(interval_size) keys. Think of it like you have a really big table of divisors (RAM) for some number, and then checking whether you can find some number (the solution) which is the inverse of the divisor. Because of the math, you can dismiss an entire sqrt(N) subinterval by just doing a single check after some simple multiplication or whatever.

Kangaroo shows speed of keys that are actually being computed. It doesn't require any RAM, just a small constant storage. It can solve the types os problems for which there isn't enough RAM on planet Earth to run a BSGS algorithm (like any puzzle above 100 bits more or less).

It doesn't matter that you see BSGS speeds of petakeys/s because the interval size is so huge that this "speed" is totally useless. You should probably divide that "speed" by sqrt(N) to have a fair comparison with a Kangaroo speed.

We don't have a fastest algorithm to do what you want, otherwise this thread would be dead since many years ago. And probably all cryptos would have a value of zero since they'd be broken.

The speed is low because you don't have a fast enough computing device. No one has a magic unicorn chip that does ECC math for free, without wasting power and dissipating heat.

Which one is better? They both have the same actual real speed, but BSGS requires RAM which you might not have enough of (the type of amounts that would require an entire solar system, if you go for higher puzzles)

[mcdouglasx]

I'm not preaching anything that's not in a 9th grade high school math book where I live.

Do you think this is the best way to win the debate? You're going off on a tangent and I don't think you're the one making shadow-posting (when a user overlays previous chats with long text to hide old chats, usually using alternate accounts).
I'd like you to give real mathematical proofs, like I did, this is a post to share ideas about the puzzle, not to impose our own, just because.