Is it non-pointless even if writing it in assembler? Some dick size updates: 11 million point additions/s (affine coords). There is a trick that even JLP's VanitySearch is missing which allows for some optimization on batch additions (8.5 Mkeys/s with that one). It's all about the branch processing.

This is very misleading. We only get the result key, not 3.500.000, simply because it does 3500000 Jacobian additions and a single final affine conversion. I don't even need to disassemble the DLL to be 100% sure about this, because the fastest known algorithm to do an modular inversion on 256-bit numbers requires 4000 CPU cycles on my i9 13th gen CPU, which means it can never ever do more than around 1 million inversions per second. But Jacobian point additions? 8 million. But those intermediary points are useless since they do not have any invariant characteristic unless you actually reduce the fractions it holds (so, the expensive mod inverse).

Anyway, all this is completely irrelevant for puzzle 66, even if magically we can do an infinite amount of additions / second, it has zero impact on the speed, because all the hashing required is many times slower than any EC operation.

Did you account for the implicit "1"s I mentioned about?
E.g. in decimal if I give you the number "42" but you also know it's a 64-bit value, there are implicit "0"s in front of 42, if your goal is to make some stats on base10 digits of 64-bit values. Because it would not be fair to only count 0s in numbers such as "402", "420", "81505" and so on.

Same principle for a BTC address. For base58 the implicit symbol is "1" (the first symbol of base58).
This has nothing to do with the "1" which you actually see at the start of an address. And even more, if you have multiple "1"s at the start, all of them are just a convention that says "so many bytes at the start are 0x00", NOT "this so many digits at the front of the base58 representation are 1". So some work is involved here if you truly want to make a histogram on base58 usage (which I don't really understand why you would, it's much more direct and error-free if you just use the binary representation).


Modulus bias. It is not about the random function, it's about the domain size vs. the modulus (base in this case) which is used. base58 is just done like in any other case: divide a big integer, use remainder, repeat with quotient.

The only bias here is about the bias of base58 representation, not on RIPEMD.


I did it in C. PrivKey (sequential) to PubKey to RIPEMD and then memcmp with the static constant target RIPEMD (which ofcourse returns false as soon as the first byte is different, come on...). You CAN't do it faster than this, and it can only scale linearly with thread count. But it's quickly obvious that it's unfeasible, I mean it's the only real way to do it without knowing the public key, but it's both a O(n) complexity AND it involves SHA256 + RIPEMD at every step. That's why I strongly believe #130 will be found next, not #66. Much more room for breakthroughs and exploration there, and while the complexity seems similar it runs WAY, way faster (no hashing nonsense).

btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.

Not really, you started off from a wrong premise.

RIPEMD: 160 bits. 2**160 choices.

2**160 does not divide by 58 so your probability doesn't take into account the bias for the last remainder (only 52 choices out of 58, hence fewer z w x... was this your secret information to keep for yourself lol?), and neither the implicit "1" characters found at the beginning, when the address is shorter than the maximum length (explaining fewer "1"s). Those leading zeros are actually the character "1" in base58. The leading "1" in the address is discardable since it's just a hint that the first byte of the number is 0, which is always true.

Maybe run the stats on the base2 160 bits instead? base58 strings don't map 1:1 with any bitstring, since there is no power of 2 to divide 58, so their space lengths don't fill each other exactly, e.g. I can give you base58 "addresses" with a length identical to a correct one, but that will require more than 160 bits.

[LE] It's actually worse than this. Because there's 4 bytes of checksum added to the RIPEMD, and THEN it goes into the base58 encoder, we have 2**192 % 58 = 38 as a remainder. So this might explain your findings better. Last symbol is heavily biased, it only covers 2/3 of the possible choices.

It is a known theorem that if two numbers do not divide each other, then bias occurs when using one of them to produce ranges in the other one. Take for example the hidden issues when (naively) doing something like this:

A histogram on r will reveal pretty fast that (assuming random() is uniform) you will have a big bias between the range [0, n) and the range [n, 7}, where n = MAX_RAND % 7. Because there's more possibilities to choose from one range than the other one, due to the remainder.

k pls just hurry up so we can call it a day

I hope you are joking. That is NOT what a logarithm is.

Number: 7
Representing 7 in different ways:
Base 10: 7
Base 2: 0111
Base 7: 10
Base 16: 0x07
Base 1: <potato> <potato> <potato> <potato> <potato> <potato> <potato>

Shall I go on?

Logarithm of 7 in the infinite field of real numbers:
Base 2: 2.8073549221... (infinite number of decimals) - it counts how many bits you need to represent value 7
Base e: 1.9459101490553132... (infinite number of decimals) - it counts how many natural numbers you need that, raised to this power, yields 7

Logarithm of 7 in some modular finite field with N = 3:
log(7) = mod 3 (oh no, this doesn't work, hmm... is it 0? 1? 2? damn, something is missing, maybe we didn't even define the neutral element yet? or not even an binary addition operator?)

So, do YOU know what you are talking about?

If I would be the creator I would laugh so hard about some of the things discussed here.

Guys, a logarithm is an abstract concept, not some math function.

You get a thing called a "base change". In this case we're dealing with a change of base of an element from some position in a finite field (private keys) to an element in the same position in a finite group (EC public keys) and the problem is to solve for the position without a way to go back from the latter to the first (which is assumed to be hard, but not yet proven). And this in the best case that we even have such an element, and not some fingerprint of it (an address), which makes the problem levels of more absurdly difficult. WTF is with the real numbers field log2 discussion, it makes no sense, we already know the ranges double in size at each step, of course any polynomial regression or whatever is a straight line. Dividing 1 by (2**64) is four levels of magnitude below a double-precision IEEE floating point, so what errors do you expect, they will always be after the 64-th zero decimal digit in reality. Nevermind the fact that there's an infinity of real numbers between any two real numbers, so an infinity of computations. Take 7 as a private key and try to solve back from [1/4, 1/8) interval, mission impossible.

This is not an analytical problem, it's a group theory problem.

Too bad the points need to be on the curve. We already know about the endomorphisms.

I'd say any attempt to break a private key that involves more than a constant amount of scalar multiplications (no matter how well optimized by precomputed tables), has very few chances of success.
Any multiplication means, by definition, more than one addition, more time.

Random key -> multiply and match -> good luck waiting.

First level of magnitude reduction: don't do scalar multiplications.

Second wall to break is then the point addition (and there's one more after that, and finally one more after).  I already said too much, but I believe there's something that can run around 20x in less time (fewer computations) if we know the public key and simplify the question.  Some known details around secp256k1 help a lot.

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?