Irrelevant. EC field (x, y) is always 256-bit, so this is the size of the operands always even for private key 0x1. Scalar (private key) size does not matter, beyond the initial multiplication. Jump points are precomputed, so we only have additions. The larger keyspace is only problematic due to its size, it doesn't affect the speed itself. Finding a 30-bit or 256-bit solution runs at the same speed. Actually, you don't even need to have any knowledge of the group size itself, just of the interval size.

What we need is algorithms breakthrough, or lots of coordinated "potatoes" and patience.

No idea, but I can tell you how fast it would go in C using the GMP routines, as I benchmarked a lot of tweaks and misc. formulas.

Close to 690k jumps /s, in-place point addition, no reallocs - this with using lowest level mpn_* routines (assembler optimized).
Around 638k jumps/s with the mpz_* routines.

Compare this to using the routines in libsecp256k1 field_impl.h and same formula steps:
affine + affine: 852k jumps/s (1 inversion, 2 multiplications, 1 squaring)

libsecp256k1 jacobian + affine addition -> jacobian result:
7.5M jumps/s (8M 3S) - removed safety checks since no point is the infinity and neither can be the result)
But... non-deterministic, I struggled for weeks to find a way to use a J point represented in multiple different ways to produce a stable hash, even a single one bit 50% probability hash as a base for deterministic jump). Seems we can only compare two J points for equality or non-equality, comparison result can vary its sign due to Z scaling.

It doesn't matter what Rust compiles down to, it can never ever generate machine code that runs faster than what the lowest level assembler routines can handle.

So we either need lots of threads (GPU) or some special hardware to speed things up.

Breaking the address (pubkey hash) automatically implies searching through the entire field range (~ 2^96 pub keys per address, in the 2^256 field)
Breaking the key searches through the key range.

TL;DR it makes no sense to try to first break the pub key in hope of using that later to find the private key. And it also doesn't make sense to break the pub key if you constrain the search to the private keys range, because this is equivalent to basically finding the solution, not breaking anything, but solving the puzzle.

Here's the ultimate private key cracking tool.

Generated number:        1a96ca8d8
Ops: 4294967296 speed: 3099732241 ops/s

Apple M1, single thread.


We're bounded by secp256k1 field operations, it can't work faster than what a CPU is capable of. I made a kangaroo in plain C, and the bottleneck is the EC point addition, I can't squeeze out more than 852.000 affine point additions per second (the only speed up would be some assembler code). If someone finds a magical way to find an scale-invariant hash of a Jacobian point it would run 10x faster though. Otherwise we're stuck with having to compute a modular inverse at every kangaroo jump, and no programming language can save you from this limitation.

Do you honestly want someone to waste their time explaining to you again how (hexa)decimal numbers work, and why they start with either a 1 2 3 6 7 .. E F (hint: the Nth left-most bit in any solution in range N is always 1, so the first digit in any base you'd use is biased)) and so on and why they magically get aligned in your horoscope circle (another hint: every solution is 1 bit longer than the previous one)

Send me 0.1 BTC and I will happily waste 6h explaining to you in detail (a 2nd time) why those arms get aligned in your circle and why you see those patterns. But you refuse to want to understand that there's nothing magical or unexpected in what you are doing there. You're the kid playing in the sand while the teenagers are trying to break down the building using resonance pulse generators. The adults are laughing their ass off watching us and don't even bother while waiting for the quantum bulldozer to arrive.


You only do around 128 loops on average, 2 milliseconds is very slow in this case. A regular single threaded C code can do around 20000 EC point additions in the same amount of time, and find any 30-bit private key.

We need to know
- what OS the creator was using in 2015 (break down kernel's code, emulate it)
- the code he used, search for vulnerabilities in it
- exact entropy state at the moment the presumed RNG was initialized and at every step of getting a next value

For example /dev/urandom reseeds itself from new entropy every now and then, that's yet another issue after potentially cracking its previous state somehow. I doubt the creator blindly used some simple deterministic 32-bit RNG such as the textbook merseinne twister one in the lowest level libc of the OS. Or that the higher level framework (deterministic wallet?) did such a nooby mistake as well.

1. Sounds normal, as you increase bit length each existing constraint gets factorized, and new ones also appear. Do you want to exclude 99.97% of the search space because they have 2 consecutive hex digits out of, let's say, 32 hex digits? Because that is where this series will end up.

2. It's computed wrong anyways. Something like 0x7f80 has 2 consecutive hex characters. And I didn't make a typo, maybe think about it in bits. Or should we only exclude byte-aligned bit patterns? See, any seemingly random string can be made into a pattern depending on how you look at it.

It is very funny that you fell into the same trap as everyone else. Here's the reality: /dev/urandom is not a secure random number generator. It falls back to a PRNG when too much data gets read from it.

Sorry to ruin your intuition, but we were talking about the exact same thing

The effort to discard unlikely patterns is massively submined by the fact that such unlikely patterns are close to 0% of the total possible different patterns (e.g. the ones your mind sees as without a pattern).

42 is a totally random number, isn't it? Until you find a gazillion corelations, starting with the fact that it's now no longer random, because I mentioned it in this thread. What's the chance a key will contain c5ec5e? Lower now, because you mentioned it? This a classic fallacy.

A random number generator does NOT care about any patterns, repetitions, weirdnesses of the human perception.

Just because a found key doesn't contain a sequence of 30 consecutive same digits is not because it was impossible, it is because there's billions over billions of other possible combinations that had exactly the same equal chance of being selected by this thing called nature / reality. Repeat the experiment many billions times and it WILL appear. It can appear the first time or the Nth time, the chances are the same at any time...

There are algorithms that are actually getting the uniform real randomness (not some deterministic PRNG bullshit like someone mentioned earlier, I mean really lol? Haven't they heard about os.urandom and how it works?) as a benefit to speed up results, not as something that cripples the search. So if you're working against randomness, it's a lost battle on all possible fronts. You need to embrace it instead.

I'd say the proportion of "unlikely patterns" in a private key of size n is more like very close to 0.00% (zero percent) the higher n gets. And it goes towards 0 really fast as n grows exponentially.

The amount of the sum of valid distinct combinations when selecting k elements, from a set of n, is massively larger towards the middle (n/2) and the close ranges around the middle, compared to the edges.

And this gap gets tighter and tighter as n increases, resembling a straight up point in the middle, which contains when looking at it with a "microscope" 99.9999% of all the possibilities. Everything else (the 0.00001%) is in the ranges before and after the central point.

This is called the central limit theorem (long-term, all results will be around the average). If this law would be invalid in observation, then it would mean randomness is not part of the structure of the game, and bias of the phenomenon (a fake coin, a compromised dice, non-random generated bits) can be proven with 99.99% certainty, But guess what, we have solutions already found with sequences of eleven consecutive 1 bits, and all the other sorts of sequences of 1 and 0 as well, which if you compute probabilistically, are not at all far away from the statistical model of a randomly generated phenomenon, so...? Excluding patterns just complicates the efficiency of the search, not sure I would play such a gamble (higher bid, lower reward).

You'll need to wait until the end of the galaxy we live in (times many billions) until you stumble upon a key with wallet balance.

There are countless programs built over the years, from Python scripts to C, local, distributed, running on CPU and GPU, to attack the puzzles, and lots of theoretical thoughts and debates on solving this problem, posted in these forums. The only consensus is that it might be (or remain) a very difficult problem to solve, unless you either level up the computing resources to stuff like hundreds of last-gen GPUs (done already), and a few prays since it's all a probability game; or discover / implement some method that is proven to work better than the best currently known, by some smaller or greater margin. But don't expect that kind of knowledge to ever go public before it gets exploited, if ever. I still have a strong feeling that #120 (or at least #125) were not solved by public software, or not without modifications to both the theoretical parameters and the implementation approach. But to understand why, you'll probably get lost in the academic papers published in the last 30 years, maybe you will find some idea of improvements, for which nobody released a public implementation yet

Please stop spreading around this super confidential knowledge about the arabic numerals and all the secret patterns in Adobe's vector design software. I am not kidding when I also say you should consult a psychiatrist and explain to them exactly what you've discovered, they can help you further. Clearly all the experts in information theory missed the magical apotheotic hidden relationship between random font sizes and numerical angles on circles. Also, the entire group theory science community (joined by their fellow game theory enthusiasts, which usually hate each other) are now amazed by the unbelievable discovery of some repeated sequence of base 10 digits in a random output feed of fully entropic data source, that you just provided. They will now need to rethink all the combinatorial formulas and revisit the basic principles of statistics. Look what you did now. Eagerly waiting on more critical information about how you plan to find the bugs in the creator's algorithm / software, since you don't really have time to write some stupid code (who does, right? we have illlustrator these days) please the next picture you post should be the envelope from Stockholm calling you to the big ceremony for your breakthroughs with drawing lines.

If you have a binary tree with 4 billion values, and you search if a specific one is in the tree, it takes at most 32 steps to do so. That means you searched 4 billion keys, but only did 32 CPU "goto next node" operations. So, in a sense, a speed of "4 billion keys / 32 cpu operations". You don't need to go through all of the nodes to know if something is in the tree or not.

Ofcourse, this is really misleading. Such exakeys/s numbers mean nothing in context of how big the parent keyspace really is, it's more like a click bait. You might as well apply the same logic to a pollard kangaroo evolving program and end up with ridiculous speeds as well the more data points you store, but it would not be a speed of group operations anymore, just like it's not for keyhunt.

Don't worry, no one will mess around with your transaction.

On another note, anyone else figured out that if you superimpose the bits of the found private keys in a quantum state chromodynamic entanglement matrix, it resembles a shiba?

Any series of strings in continuous increasing length starting from some center point and spiraled around in ascending length order will produce arms.
Why? Because they increase in same length, so for any element X(i) its length is length of X(i-1) * someConstant, so eventually their starting points on the circle's perimeter will get aligned, depending on how far from the center you position it.

This happens for any rational and non-rational number that exists, except for phi (1+sqrt(5))/2 and its family. That one is the single possible ratio that always wraps in full uniform distribution and is seen all over in nature.

I guess he's implying that he found some <80 bits solution and he posted here some proof hash so the Collective assists him morally once the pubkey gets leaked and hundreds of TX will fight over the fee in the next 10 seconds.

You are confusing a lot of things.
Private Key is a scalar value.
Public Key is an EC point (X, Y) and Y has a parity (e.g. least significant bit odd or even, 1 or 0).
Y is a function of X.
So a public key can be uncompressed (04) in full (X, Y) form or compressed with just X and the Y parity (02 or 03 byte hint prefix)

If you are doing blind searches in hope of a collision, and you have a private key interval, you need to use the correct Y parity to produce the hashed address, otherwise you are hashing the address for private key N - k which is always outside your private key search interval (for all intervals lower than N/2 in size, which is ~ 2^255), and the Y value is negated, hence the key for (X, -Y) = (X, P - Y). -Y = P- Y is always odd if Y is even, and viceversa, because P is odd.

If you are doing blind searches in hope of a collision and you don't have a private key interval in mind (so full-blown 256-bit keyspace), then your goal is to produce as fast as possible public keys, in which case you can use symmetry (02 / 03) and the 3-cycle endomorphism ±k*lambda^i -> (X*beta^i, ±Y) to quickly compute 6 (2 * 3) private keys and their points (public keys) for every generated (private key, public key) pair. So it ends up as an optimization problem to do as fast as possible key generation with lowest amount of multiplications involved, since it was explained earlier that multiplication is the highest overhead of any possible group operation (since it's basically just rounds of additions).

The only number I am aware of that is larger than the number of all possible Bitcoin private keys is the number of electrons in the Universe (around 2-3 electrons for every possible BTC private key).

It's not like the 02 or 03 were chosen arbitrarily. It's stupid to check for a collision by doing both 02 and 03. Just stick to the correct parity of the actual Y of the point.

Why? Because if k is the private key of some point, then the key of its Y-symmetric point is -k == N - k. So the keys of all those other points is in the range [2^256 - 2^66 .... 2^256 - 2^65] which is always outside the interval of interest.

Is there some trick to compute the X value of P + G if you don't know P.y? I'm curious to know.

Endomorphism will not work for any puzzle, not just small ones. Same reason as above. Multiplying the key by lambda or lambda^2 instantly lands your key into 256-bit space, no matter what interval you were working on. Even for 160-bit puzzle, the chance that k*lambda or k*lambda^2 ends up back into a 160-bit space is 1 / 2^96.

There are numerous places where it's stated by its authors and mentors that the Bitcoin libsecp256k1 library is designed to provide a secure framework for Bitcoin software, not to be the fastest way to do EC math. One of the main features is protection against side-channel attacks, which means that all computations take constant time, with not a lot of shortcuts, if any at all, in order to protect against branch predictions, time-based attacks, etc.

If you want a fast(er)/(est) way to do EC math on a CPU you'll most likely have to roll your own. Slow but easy? Python. Fastish? libsecp256k1. Faster? C and custom arbitrary precision modular arithmetic code. Fasterish? assembler / SIMD CPU instructions. Faster than anything so far? GPU parallel executor threads. Fastest? Your own programmed ASIC.

My point is that you're simply treating all of these merging and dumping like it's a no-op.

It's one thing to merge into some final 300 GB file and another to merge into a 600 GB / X TBs file.

Each merge (and I'm talking simply algorithmically) equals O(m + n) operations, where m and n is number of entries in each file.

So for some whatever desired DP throughput:
Higher DP = less storage but a lot of merges, more often writes (you want to use new data faster)
Lower DP = more storage but fewer number of merges (since you have more data in same amount of time)

At what point do you balance the throughput of all GPUs with the throughput of the time it takes to do the merging?

Because one of these two needs to be a bottleneck. You either end-up with the merging taking over most of the time, or with the GPU DP generator taking most of the time.

So total merge time = sum of the time of each merge. You can end up with big files taking a smaller amount of time to merge, than many small files merging a zillion times.

Maybe to illustrate my point better: are you willing to spend a lot of time searching for DPs and very so rarely write to a file and do the merging with some many other X many small files, or would you just write more data and do less merges? There is no good answer here, this is why you would want to look for a balance between the two, and not go to extremes just to prove a point. We already agreed that we can also just solve any puzzle with 2 kangaroos alone, hell, maybe with a DP of 64.

I experimented with direct indexing DP tables and even using DB files that simply store the DPs as a key, to speed up what you are calling a "merge", and it's still slow as hell. By comparison, file operations such as "fread" and "fwrite" are just a sure way to die of old age before a line by line comparison performed hundreds of times on multi-hundred GB files would finish. I will end this debate, anyone should form their own opinions by experimenting.

WTF? You are showing a pattern in the ASCII values of the characters 0 to 9.

Sure there is a pattern in there, since they are consecutive values starting from '0' to '9'.

So your pattern is just the ASCII offset for character '0', which is 0x30, e.g. '0011 0000' in binary up to '0011 1001'.

Hence your "pattern".