Do you think they would agree to lend you money without knowing your motives? Would you tell them you wanted to hack into a Bitcoin wallet? Can you guarantee they would agree? Of course not. Therefore, the option of borrowing money from the bank is non-existent here, even though I am 19 years old, and this in itself is a reason for a loan application to be rejected.

---

Finding the vulnerability is not enough to find the key because the unavoidable issue is cost and resources, and that in itself is a challenge. As for the person who finds the key, they are legally obligated to prove publicly that they found it. If they are concealing their identity digitally, they are legally considered a thief.

---

Using the word "illusion" in this context is itself scandalous. If you went back 20 years to before Bitcoin was invented and someone told you about the idea of Bitcoin, there's a 99.99% chance you'd call them an illusion.

It is been 6+months running keyhunt bsgs searching for 135 in random mode on 4 pc's but no luck, I wish if some one like RC or anyone searching 135 in sequential mode share his status so that we can reduce some keys.

I'm getting around 7.9b/s pubkey checks on 3070 Ti (no overclock, stock 300w), but that is just - generate coordinate and compare against a single target pubkey. It could be more but i never bothered "optimising" that pubkey kernel since it's just a old copy of my hashing kernel, just without hashing the pubkey. RCKangaroo runs at about 2.7b/s as is on github, with a little bit of changing the EC functions, it would be over 3.5b/s. Idk if that helps you with anything, it's also an old gpu and not that powerfull..

I also don't really understand what you mean by saying 1x.
I am talking about sequential BSGS with jumps but linear in space.
No area between points is skipped, I am interested in what EC speeds you have.
What do you use, CPU or GPU?
And what actual search speed do you have in G/Ks in space?

Have you checked any puzzles? What time do you solve them in?

Of course, the entire puzzle space.

---

What speeds do you get on one machine in EC and in actual search in G/Ks?

My search is based purely on RNG, one puny 3070 Ti as fast as it can. Random search points scattered across entire search space, trully scattered across, not like "scan N keys in a row and move to next random chunk - repeat". But i made it somewhat modular code, it can always be changed how the search space is being searched, but for me and one old gpu, it's RNG. And also i'm focusing specificly on addresses that don't have exposed pubkeys and playing around sha256/ripemd160 to be as efficient as possible since they give a huge penalty on speed and is kinda fun since i didn't find anything online that did it (for consumer gpu-s, for our specific usecase). 7967.67 Mkeys/s (to be specific, average) just ec (103,091,798,016 checked points in 12.939s) vs. 2225.08 Mkeys/s (average) ec+sha+ripemd (25,782,386,688 checked hash160 addresses in 11.587s) currently on 3070 Ti. You can calculate how long it would take for any address range, but it's irelevant when it's ~1700 years

Basicly trying to do what pscamillo said "a single hobbyist's odds of hitting 135 *(any address)* are essentially zero (unless you happen to be the luckiest person alive)"

Totally no point of going sequential with 7 exakeys/sec, you need 3 * 10^21 seconds to cover 135 range, which is 90 thousand billion years (9.8 * 10 ^ 13 years). Hitting the same points multiple times is just laughable, probably once per millennium. Your only chance is change base key to random every few seconds and pray to the luck gods.

Still impressive though, is that with 512 gigs of ram?

Hmm no change for me

I meant I get the speed of obtaining one X coordinate for every point addition. This is what you asked. In lack of any other context, this can get really really fast (> 25 G/s on a stock RTX 4090) but if you add context like "is X in some 100M list?" expect a 100x drop due to memory access latencies.

Still unclear of what's a "sequential BSGS", but rest assured, both a blazingly fast linear search ("does x equal target?") and BSGS are non-applicable for anything above ~80 bits key space.

This question is to all who trust MARA:
Why they accepted in block transaction with fake scripthash? Check last block and you will see a lot of issues.
Instead of listen to admins who trust this illegal activities, trust reality...
Also some users from here are working for some entities like CIA...i do not say the name because are not public...

https://mempool.space/tx/d204d536bf395f23b920fbc3c02b73a10bfdf4405271966bd15922b3257e8d0c

I understand that you don't understand what sequential BSGS is. That doesn't surprise me, because many people – if not everyone – use public algorithms. I have my own. I worked on it for 8 months, writing it, testing it, fixing it, modifying it, optimizing it, and I'm still doing it. Every time I increase the speed. Currently I have 7 EK/s of sequential SECP curve search. Every searched point G=K. But that's not the end. I know perfectly well that for puzzle 135 it's still not enough, but there are certain tricks that shorten things. With this speed, searching the entire space of puzzle 70, I recover the key in 140 seconds. In my opinion that's a good result, but as I mentioned – not the final one! As you all know, the average block time is 10 minutes you understand what I mean, so it's not bad. I'm focused on puzzle 135 – that's my goal. Because I spent 8 months writing my own algorithm, I now wanted to compare my speed to others, as well as check what others have and what algorithms they use. I don't want anyone's codes, I simply want to know your speeds. Of course, they depend not only on the algorithm but also on the hardware. The simplest explanation is giving the time to solve one of the puzzles. I still have a few ideas for modifications and optimizations of the algorithm, but it's getting more difficult and time-consuming. I'm looking for something that doesn't exist – that's the key. Someone also asked earlier about RAM – I use 128 GB.